85ab0fa5abaf9db759d4a54f427e4f8da8c37176
1
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Guillermo Gastonandkfox1111
|
4f8ac5af06 |
Configure jwt_issuer in SPIRE OIDC Provider (#829)
The SPIRE OIDC Discovery Provider binary supports a top-level
`jwt_issuer` configuration key. When set, the provider returns that
exact string as the `issuer` field in the OIDC discovery document
(`.well-known/openid-configuration`) regardless of how the request was
routed. When unset, it derives `issuer` from the inbound HTTP Host
header. This chart did not render that key into the OIDC provider
config, leaving the discovery document Host-derived even when the
operator had a fixed issuer in mind.
Why this matters
OpenID Connect Discovery requires the discovery doc's `issuer` to be
byte-equal to the JWT `iss` claim. Conformant verifiers reject the chain
when the two differ. Production OIDC consumers routinely reach the
discovery endpoint at a URL different from the canonical issuer:
- a load balancer, ingress, or NodePort exposes the provider on an
IP or host different from the canonical issuer name;
- TLS terminates at a hostname different from the one advertised to
clients;
- the discovery URL is fetched by an internal service (e.g. the API
server in a private cluster) over a different DNS view than
external clients use;
- a pinned issuer URL is contractually required and must survive
infrastructure changes that move the actual service endpoint.
In all of these the JWT's `iss` claim is a logical, stable URL; the
discovery doc must report that same value, or downstream verifiers
reject the tokens.
Current chart behavior
The chart already has `global.spire.jwtIssuer` (and a subchart-local
`jwtIssuer`), resolved by the `spire-lib.jwt-issuer` helper to
`global.spire.jwtIssuer` -> subchart-local `jwtIssuer` ->
`https://oidc-discovery.<trustDomain>`. The spire-server subchart writes
that helper's result unconditionally as `jwt_issuer:` into the server's
config -- this controls the `iss` claim of every JWT-SVID the server
mints. In the OIDC subchart, however, the same helper was only used for
two things:
1. as the strict-mode assertion gate (fails the render when the
resolved value is the `example.org` default);
2. as the default source for `config.jwtDomain` (the Host
allow-list).
It was never written into the rendered OIDC provider configuration file.
The asymmetry means the chart shipped a structurally invalid OIDC setup
by default: the spire-server signs JWTs with `iss = <resolved issuer>`,
while the OIDC discovery endpoint advertises whatever Host header was
used to reach it. The only way to correct that today is to patch the
rendered ConfigMap out of band (`kubectl patch`, a CMP, a kustomize
post-renderer), which defeats the purpose of the chart.
Backward compatibility and behavior changes
Operators who set `global.spire.jwtIssuer` will see one additional
`jwt_issuer:` line in the rendered OIDC ConfigMap. The discovery doc's
`issuer` will start returning that pinned value instead of being
Host-derived, bringing the chain into spec compliance; this is a fix for
any spec-compliant verifier that previously rejected tokens. Operators
who only set the OIDC subchart-local `jwtIssuer` see the same fix
applied via the helper's fallback chain. Operators with nothing set will
see the new line default to `https://oidc-discovery.<trustDomain>`,
matching what the spire-server config already emits today.
Signed-off-by: Guillermo Gaston <[email protected]>
Co-authored-by: kfox1111 <[email protected]>
|