Render Gateway spec.infrastructure (labels/annotations) so Gateway API
controllers propagate the metadata onto the provisioned Service/Deployment,
e.g. AWS internal NLB annotations. Purely additive: guarded by `with`, so
the default {} renders no change.
- spire-lib: toYaml passthrough in the shared Gateway helper
- spire, spire-nested: add the values param; regenerate READMEs
- tests/unit: cover the positive passthrough case
Signed-off-by: sabsari <[email protected]>
Co-authored-by: Claude Opus 4.8 <[email protected]>
The PodMonitor targeted the port name prom-cm, but controller-manager
containers expose pm-cm (and auto-suffixed/overridable names for external
managers), so their metrics were never scraped. Resolve port names through
a shared helper and enumerate every controller-manager in the PodMonitor.
Signed-off-by: sabsari <[email protected]>
Co-authored-by: Claude Opus 4.8 <[email protected]>
Add jwtSVIDExec as a fourth exactly-one kubeConfigs source: the chart
generates an exec-credential kubeconfig that authenticates to an external
cluster with short-lived SPIFFE JWT-SVIDs instead of a static credential.
Signed-off-by: sabsari <[email protected]>
Co-authored-by: Claude Opus 4.8 <[email protected]>
Replace the hardcoded `User: spire-root` subject with an `externalServerSubject`
block (`kind`/`name`/`namespace`) so the downstream RBAC can bind to a User,
Group, or ServiceAccount. Defaults preserve the previous behavior.
Signed-off-by: sabsari <[email protected]>
Co-authored-by: Claude Opus 4.8 <[email protected]>
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]>
