HashiCorp Vault Associate (003) Question 232
Single answer9 Access management architectureA platform team is designing access management for HashiCorp Vault in a shared environment. They want application teams to authenticate with their own method, but they also want a small security group to control which secrets each team can access. To reduce risk, the platform team wants authentication management separated from authorization management so that changing how a team logs in does not require rewriting access rules. Which approach best meets these requirements?
- A
Create identity entities and group aliases that map users or workloads from each auth method into Vault Identity groups, then attach policies to those groups.
- B
Attach all access policies directly to each auth role so the permissions stay close to the login configuration for every team.
- C
Create one token role per team and distribute long-lived orphan tokens so teams can keep the same permissions regardless of auth method.
- D
Use a separate namespace for every auth method, and place the policies in the namespace that owns the auth method.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Vault Identity entities, aliases, and groups, with policies attached to groups. In Vault, auth methods answer the question 'who is logging in?' while policies answer 'what can they do?' The Identity system links multiple auth method representations of the same user or workload to a common entity and supports group-based policy assignment. This architecture is a best practice because it decouples authentication from authorization, simplifies policy administration, and supports changes in auth methods without redesigning access rules. This aligns with Vault documentation on Identity, entities, group aliases, and policy-based access control.
- A. Correct.
Correct. Vault's Identity system is designed to separate authentication from authorization. Different auth methods can map to the same entity or external group through aliases, and policies can then be attached to Identity groups. This lets teams authenticate with different backends while keeping access control centrally managed by policy on groups rather than being tied to a specific login method.
- B. Incorrect.
Incorrect. While auth roles often influence how clients authenticate and may be associated with token policies, using auth roles as the main place to manage authorization tightly couples permissions to a specific auth method. If the organization changes or adds auth methods, access rules must be duplicated or reworked. This does not provide the desired separation of concerns.
- C. Incorrect.
Incorrect. Long-lived orphan tokens are generally not a best-practice solution for access management architecture. They bypass the intended authentication flow, increase operational and security risk, and make identity-based governance harder. Token roles are not a substitute for structuring authorization around entities and groups.
- D. Incorrect.
Incorrect. Namespaces can provide administrative isolation in Vault Enterprise, but they do not solve the core design requirement here. Separating by auth method would still couple access control to where authentication occurs. Also, the best architectural answer for separating authentication from authorization is to use the Identity system with entities, aliases, and groups.