Vault Kubernetes Auth: Service Account Annotation Consistency

Vault Kubernetes Auth Configuration

The Kubernetes auth method in Vault (v1.12+) relies on the vault.hashicorp.com/role annotation on a pod's service account to bind the identity to a specific Vault role. In local development environments, this annotation is often present by default or injected via local tooling, ensuring seamless secret retrieval.

In production environments, the absence of this annotation leads to authentication failures during pod startup, as Vault cannot map the service account to a defined role. This creates a discrepancy between environment behaviors where the configuration works locally but fails upon promotion.

Operational Constraint

There is an unresolved design decision regarding whether to strictly enforce the presence of the annotation at the deployment level or to implement a fallback mechanism that assigns a default role to pods lacking the specific annotation.

Questions

• Is it more secure to enforce the vault.hashicorp.com/role annotation via an admission controller than to rely on a default fallback role?
• What are the security implications of using a default role for any service account that authenticates via the Kubernetes method?