Access policies and dynamic credentials
Vault makes two kinds of authorization decision. First, who may do what to which resource, refined by an access policy on top of IAM. Second, how long an issued credential lives, governed by a lease. The two work together: a policy decides whether you can mint a dynamic credential, and a lease decides when it expires.
Access policies: a second layer on top of IAM
Section titled “Access policies: a second layer on top of IAM”An access policy is a workspace-scoped document evaluated after the IAM gate. IAM grants coarse access; the access policy adds fine-grained, workspace-local rules. Rules are additive, so your effective permissions are the union of every rule that matches.
Each rule grants a set of permissions on a pattern of resources, for example every secret in a workspace, and may cap the lifetime of any credential issued through it. A rule can be narrowed by conditions, and all of a rule’s conditions must hold for it to apply:
- Source IP: allow the rule only when the caller’s address is inside, or outside, a set of network ranges. Use it to confine secret reads to a corporate network or a CI egress range.
- Time window: allow the rule only within, or outside, a daily window in a given timezone. Use it to restrict sensitive operations to business hours.
Every edit keeps the previous version, a qibdo addition, so a policy carries
its own append-only history: you can always see who changed it and when, and
recover any earlier version.
Leases: the lifetime of a dynamic credential
Section titled “Leases: the lifetime of a dynamic credential”Dynamic credentials are not stored. They are issued on demand and handed back once, so you must capture the credential the moment it is returned. What vault keeps is the lease: a durable, server-side handle that records who the credential was issued to, when it expires, and the source it came from:
- Database: short-lived database logins minted from a role template.
- Cloud: temporary credentials for AWS, GCP, or Azure.
- SSH: one-time SSH credentials.
- Kubernetes: short-lived service-account tokens.
A lease has a time-to-live and a maximum lifetime it can be extended to, and may be renewable, revocable, or both. Its status is server-driven: active while valid, renewed after an extension, and terminal once it is revoked early or expires on its own. You can revoke a single lease, or revoke many at once, for example every credential issued to a compromised principal.