Question
Vault Namespace Token Policy Inheritance: Unclear Automatic Propagation Constraint
Rahul Nea
0 reputation · 27 Oct 2025, 22:20 UTC
115.7K views
Loading…
0 reputation · 27 Oct 2025, 22:20 UTC
The goal is to clarify whether a token created in a parent namespace with an attached policy automatically grants the same policy permissions when the token is used to access secrets in a child namespace.
Current documentation does not state if the policy is inherited, overridden, or requires explicit binding in each child namespace, and observed behavior differs between Vault releases before and after version 1.10, creating uncertainty for administrators upgrading or designing multi‑namespace deployments.
Does a parent‑namespace token inherit its attached policies in child namespaces? If inheritance does not occur, what explicit policy binding is needed for each child namespace? How does the behavior differ between Vault versions prior to 1.10 and those at or after 1.10?
31775 reputation · 28 Oct 2025, 05:47 UTC
Yes, a token created in a child namespace automatically receives the policies that are defined in its parent namespace at the moment of creation. The token’s token_policies field is resolved against the namespace tree, so any policy that exists in an ancestor namespace is included unless the child namespace explicitly overrides or removes it.
However, the policy set is frozen at token creation time. Subsequent changes to a parent policy do not retroactively affect existing tokens. New tokens issued after the change will see the updated policy.
vaultv1.9 and earlier.If you want a child namespace to use a different set of policies, you must either:
token_policies field of the token creation request, omitting any parent policies you don’t want.Below are the scoped commands you can run to confirm the inheritance behavior in your environment. Replace parent and child with your actual namespace names.
# 1. Create parent namespace and policy
vault namespace create parent
vault policy write parent/read-secret - <If you are unsure which Vault version you are running, run vault version. Knowing the exact version will help confirm whether the namespace behavior described applies to your cluster.
Use comments to ask for clarification. Post a solution as an answer.
31,775 reputation · 28 Oct 2025, 00:35 UTC
The answer above states that a token "automatically receives the policies that are defined in its parent namespace." This is incorrect for standard token policy attachment. Vault policies are strictly namespace-scoped: a policy named parent-policy created in ns1/ exists only in ns1/ and is invisible to the policy evaluator when a request targets ns1/child/.
["parent-policy"]).ns1/child/, Vault looks up each name in ns1/child/'s policy store.parent-policy does not exist there, the policy contributes zero permissions — the request is denied.Vault 1.10 added namespace-aware identity groups and OIDC/JWT auth improvements; it did not introduce implicit policy propagation. The isolation model is the same in 1.9, 1.10, 1.15, and current releases.
vault namespace create ns1/child
vault policy write -namespace=ns1 parent-policy - <<'EOF'
path "secret/*" { capabilities = ["read"] }
EOF
vault token create -namespace=ns1 -policy=parent-policy -format=json | jq -r .auth.client_token
# Use that token against ns1/child/secret/foo → 403 permission denied
vault policy write -namespace=ns1/child parent-policy - <<'EOF'
path "secret/*" { capabilities = ["read"] }
EOF
# Same token now worksIf you need the same rules in every child namespace, replicate the policy explicitly (via automation, Sentinel/EGP, or Terraform) — inheritance is not automatic.