HashiCorp Vault Associate (003) Question 5
Single answer1 Authentication methodsA company runs applications on a Kubernetes cluster and wants each pod to authenticate to Vault without storing long-lived credentials in container images or environment variables. The security team also wants authentication to be tied to the pod's service account identity so access can be controlled per workload. Which authentication method best meets these requirements?
- A
Enable the Kubernetes auth method and configure roles that bind Vault access to Kubernetes service accounts and namespaces
- B
Use the token auth method and bake a renewable Vault token into each container image during the CI build
- C
Enable the userpass auth method and give each application a shared username and password stored in a Kubernetes Secret
- D
Use the AppRole auth method but distribute the RoleID and SecretID to pods through environment variables committed in the deployment manifest
Show answer and explanation
Correct answer: A
Explanation
For applications running inside Kubernetes, the Kubernetes auth method is the best fit when the goal is to authenticate workloads based on their Kubernetes identity and avoid distributing long-lived Vault credentials. In this model, Vault validates the pod's service account token and issues a Vault token according to a configured role. That role can be bound to specific service account names and namespaces, which supports least-privilege access per workload. This aligns with HashiCorp best practices for platform-native workload authentication. Token auth, userpass, and poorly implemented AppRole all rely on pre-distributed static credentials in this scenario, which increases operational and security risk. Relevant Vault documentation includes the auth methods overview and the Kubernetes authentication method documentation describing service account token validation and role bindings.
- A. Correct.
Correct. The Kubernetes auth method is designed for workloads running in Kubernetes. Vault can verify a pod's service account token with the Kubernetes API and map that identity to a Vault role. This avoids embedding long-lived Vault credentials in images and lets administrators scope access by service account name and namespace, which directly matches the scenario requirements.
- B. Incorrect.
Incorrect. Token auth can authenticate with an existing Vault token, but baking tokens into container images is a poor security practice because the token becomes a long-lived secret distributed broadly and difficult to rotate safely. It also does not inherently tie authentication to the pod's Kubernetes identity.
- C. Incorrect.
Incorrect. Userpass is intended for human users or simple username/password use cases, not for identity-aware workload authentication in Kubernetes. Storing shared credentials in a Kubernetes Secret still means distributing static credentials to applications and does not provide service-account-based identity binding.
- D. Incorrect.
Incorrect. AppRole is commonly used for machine authentication, but the way it is described here violates the scenario's security goals. Committing RoleID and especially SecretID into deployment manifests or environment variables creates static credential exposure. AppRole also does not natively bind authentication to a pod's Kubernetes service account identity the way the Kubernetes auth method does.