HashiCorp Vault Associate (003) Question 1
Single answer1 Authentication methodsA company is rolling out HashiCorp Vault to multiple Kubernetes clusters. Security policy requires application pods to authenticate to Vault without storing long-lived static credentials in container images or Kubernetes Secrets. The platform team also wants Vault to verify the identity of the calling pod using the cluster's service account token. Which authentication method best meets these requirements?
- A
Enable the Kubernetes auth method and configure roles bound to service accounts and namespaces
- B
Enable the AppRole auth method and distribute RoleID and SecretID to pods through environment variables
- C
Enable the userpass auth method and create a Vault username and password for each application
- D
Enable the token auth method and inject a long-lived Vault token into each pod at deployment time
Show answer and explanation
Correct answer: A
Explanation
The best choice is the Kubernetes auth method because it is purpose-built for authenticating workloads running inside Kubernetes. In this model, the pod presents its Kubernetes service account JWT to Vault, and Vault validates that token against Kubernetes before issuing a Vault token with policies associated to a Vault role. This approach supports short-lived credentials and avoids storing long-lived secrets in images or Kubernetes Secrets. By contrast, AppRole is useful for machine authentication in many environments, but it typically requires securely delivering a RoleID and SecretID to the workload. Userpass is generally for human authentication, and token auth only accepts a Vault token that must already exist. HashiCorp documentation and best practices for Vault recommend using the auth method that matches the platform identity source; for Kubernetes workloads, that is the Kubernetes auth method.
- A. Correct.
Correct. The Kubernetes auth method is designed for workloads running in Kubernetes. Vault can validate the pod's service account token with the Kubernetes API and map authenticated identities to Vault roles based on bound service account names and namespaces. This avoids embedding long-lived static credentials in images or Secrets and aligns with the requirement to verify pod identity using the cluster's service account token.
- B. Incorrect.
Incorrect. AppRole is commonly used for machines and applications, but in this scenario it would require distributing RoleID and SecretID to the pod. That introduces credential management overhead and often results in static or semi-static credentials being stored or injected somewhere. It also does not natively use the Kubernetes service account token to verify pod identity.
- C. Incorrect.
Incorrect. The userpass auth method is intended for human users authenticating with a username and password, not for Kubernetes workloads. Using userpass for applications would create unnecessary operational burden and would require storing passwords for pods, which conflicts with the requirement to avoid long-lived static credentials.
- D. Incorrect.
Incorrect. Token auth allows a client to present an existing Vault token, but it does not solve the problem of how the pod securely obtains that token in the first place. Injecting a long-lived token into pods is specifically what the company wants to avoid because it creates static credential exposure and weakens identity assurance.