Support per-issuer ambient credentials

[Clockwork-Muse]

The current instructions around ambient credentials assume that they will be set solely at chart installation time.

While this works well in many scenarios, in shared clusters teams may be expected to bring their own credentials for certificate issuance; this helps with auditing and permissions for around these resources (ie, enforcing certificates are only issued for specific subdomains or for specific certificate templates). This is obviously doable with the normal explicit credentials, but this capability is currently lacking for ambient credentials.

• Ability to use separate ambient credentials per configured Issuer/ClusterIssuer, including separate credential types per (eg, use both Azure and GCP on two separate issuers)
• Ability to use ambient credentials without configuring such credentials at install time/alongside the CRDs/operator pods (in a shared scenario there probably shouldn't be a shared default credential available).

Contrast with the external secrets operator which allows for per-store identity.

[irby]

Hey @Clockwork-Muse thank you for bringing up this issue. Let me do some research on my end with respect to this request, and I will follow up with you shortly on my findings.

[irby]

Hey @Clockwork-Muse thank you again for bringing up this issue. You've identified a genuine gap, and your comparison to the external-secrets-operator per-store identity model was a helpful reference point.

I've identified that ambient auth currently resolves identity from the operator pod's own ServiceAccount and caches that single resolved identity for the lifetime of the pod. This means that every Issuer / ClusterIssuer resource that doesn't reference an explicit credential silently shares the same ambient identity with no way to scope which Issuers can use it. This also means that only a single identity is ever active per install, and an issuer that wants a different identity cannot do so without a pod restart with different bindings.

What is planned

An optional per-Issuer/ClusterIssuer field referencing a Kubernetes ServiceAccount whose bound Workload Identity should be used for that Issuer specifically instead of the operator pod's own identity. This will allow for your first bullet point: Each issuer resolves their own identity independently of each other.

One thing to flag

Closing your second bullet point (guaranteeing no implicit shared identity is ever available) would require removing the current pod-identity fallback for any Issuer that doesn't opt into the new field. That would be a breaking change for existing installs on upgrade from an existing install that relies on ambient credentials. We plan on shipping this new field additively: existing Issuers can keep working exactly as they do today, and the new per-Issuer ServiceAccount reference is an opt-in. A shared-cluster admin who wants to fully eliminate implicit fallback would still need to avoid binding the cloud identity to the operator's own ServiceAccount at install time.

If you have any concerns about this fallback behavior, please let me know and I'll be happy to revisit. Feedback and pushback is certainly welcome.

[Clockwork-Muse]

The fallback behavior is likely fine, if it can be mitigated by simply not configuring an identity at install time.

[irby]

@Clockwork-Muse to confirm, you mean not granting the operator's ServiceAccount a FIC / IAM binding on the cloud side, correct? There's no separate chart-level toggle for this today.

[Clockwork-Muse]

@irby - Either not binding the cloud account, or not even needing to configure an ambient credential at install time, would be acceptable.