Allow each kubeConfigs entry to reference an externally-managed Secret
(externalSecret{name,key}) instead of embedding the kubeconfig in values.
Entries may reference different Secrets and mix inline with external ones.
The kubeconfigs volume becomes a projected volume; consumer mount paths are
unchanged. Each entry must set exactly one of kubeConfig, kubeConfigBase64,
or externalSecret.
Signed-off-by: sabsari <[email protected]>
Co-authored-by: Claude Opus 4.8 <[email protected]>
Add support for the EJBCA UpstreamAuthority plugin, allowing the SPIRE
server to use an EJBCA instance as its upstream CA over mTLS.
- Add upstreamAuthority.ejbca values (hostname, caName, endEntityProfileName,
certificateProfileName, optional endEntityName and accountBindingId).
- Render the ejbca UpstreamAuthority block in the server config and count it
toward the single-upstream-authority guard.
- Mount the mTLS client credentials (and optional CA cert) from a secret,
either chart-created (secret.create) or externally provided.
- Gate ca_cert_path on secret.data.caCert, mirroring the disk plugin's bundle
handling for deterministic rendering.
- Regenerate the chart README and add a unit render test.
Signed-off-by: sabsari <[email protected]>
Co-authored-by: Claude Opus 4.8 <[email protected]>
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]>
* Exit code from diff indicating changes should not block commit.
Signed-off-by: Kevin Fox <[email protected]>
* Push the changes that update-tags creates
Signed-off-by: Kevin Fox <[email protected]>
* Add plugin support to the spire agent
This adapts the existing spire server plugin support to be usable by
the agent as well.
Signed-off-by: Kevin Fox <[email protected]>
* Fix notes
Signed-off-by: Kevin Fox <[email protected]>
* Add plugin support to the spire agent
This adapts the existing spire server plugin support to be usable by
the agent as well.
Signed-off-by: Kevin Fox <[email protected]>
* Fix notes
Signed-off-by: Kevin Fox <[email protected]>
* Update documentation
Signed-off-by: Kevin Fox <[email protected]>
* Update example
Signed-off-by: Kevin Fox <[email protected]>
---------
Signed-off-by: Kevin Fox <[email protected]>
Signed-off-by: kfox1111 <[email protected]>
Current configmap template renders to a wrong KeyManager and
UpstreamAuthority configurarion when aws_kms and aws_pca are enabled and
container is crashing. The proposed changes will fix the issue.
---------
Signed-off-by: unufree <[email protected]>
Signed-off-by: unufr33 <[email protected]>
Co-authored-by: Faisal Memon <[email protected]>
This patch enables end users to configure external plugins in the
spire-server config. Unsupported internal plugins are not able to be
set.
---------
Signed-off-by: Kevin Fox <[email protected]>
Signed-off-by: kfox1111 <[email protected]>
Co-authored-by: Edwin Buck <[email protected]>
Co-authored-by: Faisal Memon <[email protected]>
