CCNA Vault Policies Questions

The templated path interpolates identity.entity.metadata.team, so each user's entity metadata resolves to their own team's secret path. This grants read and list capabilities only within that team's namespace, satisfying the requirement for per-team access scoped by external identity provider membership.

This policy grants read and update capabilities on the exact path secret/data/backup. In Vault, update capability allows modifying an existing secret, which includes creating a new version or changing the secret data. This matches the requirement to read and update the secret at that path.

On a KV v2 mount the metadata endpoint is reached at '<mount>/metadata/<path>'. Granting read and list on kv-prod/metadata/apps/* lets the client list keys and inspect version metadata such as created_time and current_version, while never touching the data endpoint that returns secret values. This is exactly the least-privilege requirement described.

This policy grants read and list on all paths under finance, then explicitly denies access to the salaries path. In Vault, a deny capability takes precedence over any other capability, even if a more specific path rule grants access. The order of path blocks does not matter; the deny rule overrides. This correctly restricts access to salaries while allowing everything else.

Grants read capability on the exact KV v2 data path, satisfying the secret-retrieval half of the requirement. Without this statement the service cannot fetch credentials, so it is necessary; the token-renewal half is covered separately by the renew-self path.

Vault's ACL system does not constrain the contents of a policy an operator may write, so write access to the policy endpoint is inherently a path to privilege escalation unless an external guard inspects the submitted document. Adding a policy-as-code or Sentinel validation layer that rejects protected path stanzas closes that gap while still allowing day-to-day policy authoring.

Separate per-application policies keep each rule set minimal and auditable, while group aliases map identity-provider groups to those policies without duplicating rules per user. This satisfies least privilege and simplifies ongoing management as applications and team memberships change.

Templated policies interpolate identity entity metadata at request time, so {{identity.entity.metadata.team}} resolves to each user's team value. One policy then grants read and list on that team's path, eliminating per-team policies as new teams are added, satisfying the dynamic single-policy requirement.

This snippet grants list and read capabilities on the metadata path for all secrets under finance. In KV v2, metadata operations like listing and reading secret metadata are performed on the metadata/ path, so this precisely meets the requirement without granting access to the actual secret data.

Vault evaluates all matching policies together, and any matching deny rule overrides grants regardless of specificity or order. The deny on that path therefore blocks the read even if another policy grants it, so access is refused.

This snippet grants read on the role configuration and create/update on the issue path. In Vault's PKI secrets engine, reading a role uses the roles/ path, and generating a certificate uses the issue/ path with a write operation, which requires create or update capability. This meets the requirement with least privilege.

Issuing a certificate against a PKI role is performed by writing to the issue endpoint, so create and update on pki_int/issue/web-server permits generating certificates for that role only. It does not allow altering the role definition, touching other roles, or generating root material, which keeps the team within the intended boundary while satisfying the certificate-generation requirement.

The policy read subcommand fetches the named policy from Vault's storage and prints its contents exactly as the server has parsed and stored it. Because it reads the server-side copy rather than the local file, it reveals any drift between the HCL on disk and what is actually enforced, which is precisely what the administrator needs before rotating credentials.

Vault merges all policies attached to a token, and permissions are additive, so any additional policy with a statement covering the finance path grants the access regardless of what the hr policy says. The default policy is commonly attached automatically and may include broad read paths in some configurations, and operators often overlook extra policies during troubleshooting. Inspecting the token's full policy list resolves the discrepancy.

The revoke-self endpoint operates on the caller's own token, identified from the client token supplied with the request. Because it modifies token state rather than reading it, the policy requires the update capability on that exact path, letting users invalidate their own token without broader revoke permissions.

Templating reduces duplication and ties access to identity attributes.

The policy grants only read capability on the production path, so any write operation is denied by Vault's default-deny posture. Creating a secret at "secret/data/production/db" requires create or update capability on that exact path, which the policy omits, causing the write to fail.

KV v2 inserts a mandatory `data/` segment between the mount and the secret path, so a policy written for the v2 layout cannot match a v1 mount. The role's policy grants `secret/data/app/*`, which never matches the actual v1 path `secret/app/prod`, producing the permission denied. Correcting the path to omit `data` resolves it.

Templated policies rely on the token being associated with an entity. If the token is not linked to an entity (e.g., a token created without an entity), the template variable cannot be resolved, and the path becomes invalid, resulting in a permission denied error. The user must have an entity and the token must be tied to it.

Listing enabled auth methods queries the sys/auth endpoint, which enumerates mounted authentication backends. The list capability on that path is the minimum privilege required; read or sudo would not permit enumerating mounts, and other paths expose unrelated secrets.

Because policy write performs a full replacement, the safe procedure is to start from the current complete document, add the new stanza, and submit the whole file. The stored policy then contains the old rules plus the addition, and dependent tokens continue to work with their existing ACLs.

Vault's key-value v2 secrets engine treats creation and modification as distinct operations. The 'create' capability permits the initial write to a new path, but updating an existing secret requires the separate 'update' capability, which the policy omits, causing the permission denied error.

In Vault KV v2, the API path inserts data/ between the mount and the key. The single + wildcard matches exactly one path segment, so secret/data/team-a/app satisfies secret/data/+/app, while deeper or shallower paths do not.

Deny capabilities override any granted capabilities in Vault's policy evaluation, regardless of policy order or token attachment. Because "admin-policy" explicitly denies "secret/data/app/db", the token cannot write there even though "app-policy" grants create and update on the wildcard path. The explicit deny constraint in the stem therefore blocks the write.

Renewing a token maps to the update capability on `auth/token/renew-self`, while listing capabilities requires read on `auth/token/capabilities-self`. Both paths are self-scoped, so the service acts only on its own token, satisfying the constraint that it must not create new tokens.