Security Analysis of Vault Role Mapping
It is significantly more secure to enforce the vault.hashicorp.com/role annotation via an admission controller than to implement a default fallback role. Relying on a default role introduces a systemic security risk by granting baseline permissions to any authenticated service account, regardless of its intended purpose.
The Risk of Default Fallback Roles
Implementing a default role for any service account that successfully authenticates via the Kubernetes method creates several security implications:
- Violation of Least Privilege: A default role typically grants a "minimum viable" set of secrets. However, in a large cluster, providing any level of access to an unmapped service account increases the attack surface if a pod is compromised.
- Implicit Trust: You shift from an explicit trust model (where a developer must define the required role) to an implicit trust model (where any valid Kubernetes identity is trusted by Vault).
- Audit Obscurity: When multiple disparate services share a default role, auditing secret access becomes difficult. You can see that the "default-role" accessed a secret, but you lose the granular mapping of which specific application logic triggered the request.
The Advantage of Admission Control
Using an admission controller (such as OPA Gatekeeper or Kyverno) to mandate the vault.hashicorp.com/role annotation ensures that the identity-to-role mapping is a conscious deployment decision. This eliminates the discrepancy between local and production environments by failing the deployment early (at the kubectl apply stage) rather than failing the application at runtime during pod startup.
Implementation Steps for Enforcement
- Define the Policy: Create a policy in your admission controller that requires the
vault.hashicorp.com/role annotation on all ServiceAccounts or Pods within specific namespaces.
- Audit Existing Pods: Run a check to identify pods currently lacking the annotation to avoid breaking existing workloads during the rollout.
- Configure Vault Roles: Ensure every allowed annotation value corresponds to a strictly defined role in Vault using
bound_service_account_names and bound_service_account_namespaces.
- Verify Mapping: Use the following command to verify the role configuration in Vault:
vault read auth/kubernetes/role/your-role-name
Diagnostic Requirement
To provide a more tailored enforcement strategy, please clarify: Are you using the Vault Agent Sidecar Injector for secret delivery, or is the application calling the Vault API directly using the SDK? (The injector relies on pod annotations for configuration, whereas direct SDK calls rely on the Vault role's internal mapping of the Service Account token).
vault