The credentials backends currently require a long-lived static credential for everything but GCP:
- AWS Secrets Manager takes an access key and secret only.
- Azure Key Vault takes a service principal client secret only.
- Vault takes a static token only (config.proto noted that application role auth was wanted instead).
Operators on EKS, AKS, or with Vault/OpenBao in-cluster usually have a keyless option available: EKS Pod Identity or
IRSA, AKS Workload Identity, and Vault's Kubernetes auth method. Supporting those means no stored secret has to be
rotated for the control plane or CAS. GCP already works this way, since its credentials file can be a workload
identity federation configuration.
Each backend is proposed as a separate PR, so they can be reviewed and merged independently: #3486 (AWS), #3485
(Azure), #3487 (Vault). Every change is backwards compatible: existing static-credential configurations behave exactly
as before.
The credentials backends currently require a long-lived static credential for everything but GCP:
Operators on EKS, AKS, or with Vault/OpenBao in-cluster usually have a keyless option available: EKS Pod Identity or
IRSA, AKS Workload Identity, and Vault's Kubernetes auth method. Supporting those means no stored secret has to be
rotated for the control plane or CAS. GCP already works this way, since its credentials file can be a workload
identity federation configuration.
Each backend is proposed as a separate PR, so they can be reviewed and merged independently: #3486 (AWS), #3485
(Azure), #3487 (Vault). Every change is backwards compatible: existing static-credential configurations behave exactly
as before.