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.
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.
Issuer/ClusterIssuer, including separate credential types per (eg, use both Azure and GCP on two separate issuers)Contrast with the external secrets operator which allows for per-store identity.