HashiCorp Vault Associate (003) Question 231
Single answer9 Access management architectureA platform team is designing access management for HashiCorp Vault. They want human administrators to authenticate with their corporate identity provider, applications running in Kubernetes to authenticate without shared static credentials, and all access decisions to follow least-privilege. They also want to avoid giving applications broad access through a single shared admin token. Which approach best meets these requirements?
- A
Enable an OIDC auth method for administrators, enable the Kubernetes auth method for in-cluster applications, and attach narrowly scoped policies to the identities or roles each client uses.
- B
Create one long-lived root token for the platform team and store that token in Kubernetes Secrets so applications can reuse it when they need Vault access.
- C
Enable only the token auth method and manually generate periodic tokens for both administrators and applications, because token auth is the most flexible option for every client type.
- D
Use the userpass auth method for administrators and applications so all clients can authenticate with usernames and passwords managed directly in Vault.
Show answer and explanation
Correct answer: A
Explanation
Vault access management architecture is based on authenticating clients through appropriate auth methods, then authorizing them with policies. Best practice is to choose auth methods that match the client type and environment. For human users, identity-based federation such as OIDC is commonly preferred because it integrates with existing identity providers and supports centralized control. For Kubernetes workloads, the Kubernetes auth method lets pods authenticate using service account tokens rather than shared static credentials. After authentication, Vault maps identities or roles to policies so access can be limited to only the required paths and capabilities. This follows least-privilege principles and avoids risky patterns like distributing root tokens or using one shared administrative credential for many applications. These practices align with Vault documentation on authentication methods, ACL policies, and workload-specific auth design.
- A. Correct.
Correct. This design matches Vault best practices for access management architecture. OIDC is appropriate for human users because it integrates with an external identity provider and supports centralized user lifecycle management. The Kubernetes auth method is appropriate for workloads running in Kubernetes because applications can authenticate using their service account identity instead of sharing static secrets. Attaching narrowly scoped ACL policies to users, groups, entities, or auth roles enforces least privilege and avoids overbroad access.
- B. Incorrect.
Incorrect. A root token is highly privileged and intended only for initial setup or emergency administration. Storing a root token in Kubernetes Secrets and sharing it with applications violates least-privilege principles, increases blast radius, and bypasses Vault's intended auth architecture. This is a common but serious security anti-pattern.
- C. Incorrect.
Incorrect. The token auth method exists, but using manually generated tokens for all humans and applications is not the best architectural choice here. It creates operational overhead, weakens identity integration for administrators, and often leads to shared or poorly managed credentials for applications. Vault generally recommends using the auth method that matches the client environment, such as OIDC for humans and Kubernetes for in-cluster workloads.
- D. Incorrect.
Incorrect. Userpass can authenticate users directly against usernames and passwords stored in Vault, but it is typically less suitable than federated identity methods like OIDC for enterprise administrators. It is also a poor fit for applications, because managing passwords for workloads introduces static credentials and operational burden. This option does not align well with modern least-privilege and workload identity patterns.