Policies, paths, and capabilities | Vault Associate 003: secrets and operations

Concept and mechanism

Vault policies describe allowed or denied operations on paths. Absence of a grant does not mean unrestricted access. Use the actual endpoint to choose capabilities rather than only the business verb: fetching dynamic credentials by GET can create an external account but requires read on the appropriate Vault endpoint. In KV v2, data paths include data while metadata has separate operations. A CLI command can hide part of this structure; policy must match the API. The + wildcard represents one segment, and the * glob is not a complete regular expression. Pattern priority should be analyzed before indiscriminately combining permissions.

Guided application

In a fictional example, the application migrated to KV v2 and requests apps/data/funds while its rule remains apps/funds. Correct the path and test allowed and denied access with the actual application token. Granting root would start the service without demonstrating correct policy. When the same pattern appears in multiple policies, capabilities combine, but deny wins, including over sudo. Sudo permits protected operations that also require the relevant capability; it is not a universal way to bypass rules. List deserves separate attention: it can reveal key names even when their values are unreadable. Avoid sensitive information in names and distinguish listing from authorization to read secret values.

IN PRACTICE

GET database/creds/reporting can issue credentials, but read is the capability to evaluate.

Common pitfalls

CRUD by external effect; KV v1 policy on a v2 mount; glob as regex; list as name filtering by read.

Related topics: Authentication and identity · Tokens, leases, and renewal · KV, database, and wrapping secrets

Take this idea with you

Validate path, pattern, and capability using the requesting identity.

Create account

Reference: Vault policies and path matching · Vault Associate (003); product version tested: Vault 1.19