Vault Core Concepts at a Glance: Secret / Auth / Policy / Token

When introducing Vault to a team, the first thing people stumble over is the boundary between Secret, Auth, Policy, and Token. Separating the terms cleanly makes both design choices and exam prep much easier.

This article focuses on the stable concepts most likely to appear at the Vault Associate level, with CLI examples and caveats, in a form you can apply directly to production operations.

Big Picture and Term Map: Grasp the Four Pillars First

Vault becomes much clearer when you organize it around four elements: which door you come in through (Auth Method), what the person who came in is allowed to do (Policy), where the actual secret lives (Secrets Engine), and the entry ticket itself (Token). Auth is the authentication doorway, Policy authorizes the actions of whoever passed through, Secret is the data or capability being protected, and Token is the credential that carries the session and permissions.

The design rules are simple. An Auth Method only issues Tokens; it never touches Secrets. A Secret is issued and torn down together with its Lease. A Policy always defines allow/deny on a path basis. A Token accesses a Secret backed by its Policy, with TTL, renewal, and revocation managed throughout.

• Auth proves who you are and issues a Token. Secret protects and issues a what.
• Policy is always a path-based ACL. deny wins, allow is additive, root grants everything.
• A Token is the result of authentication; its permissions depend entirely on the Policies attached to it.
• Lease is the framework that manages the temporal lifecycle of both Tokens and dynamic secrets.

Relationship diagram for Secret / Auth / Policy / Token

First commands to glance at (state and enabled endpoints)

export VAULT_ADDR=http://127.0.0.1:8200
# Sealed/Unsealed and HA state, etc.
vault status
# List Secrets Engines (which mounts exist under /)
vault secrets list
# List Auth Methods (under /auth)
vault auth list

Secret and Lease: Static vs. Dynamic, plus Practical TTL / Renew / Revoke

Secrets divide broadly into static and dynamic. Static secrets such as kv v2 have fixed contents until updated and carry no Lease. Dynamic secrets like database or aws issue a fresh temporary credential each time and manage its lifetime via Lease (TTL, renewability, max TTL).

The key point is that a Lease attaches not only to a Token but to the dynamic secret itself. If it is renewable, renew before expiry; revoke when no longer needed; during incidents, revoke by prefix to quickly contain the damage.

• Static secrets: use versioning (kv v2) and minimize the read surface via Policy.
• Dynamic secrets: least privilege and short-lived. Auto-expire to shrink the blast radius.
• lease revoke -prefix is a fast-acting emergency switch. Combine with a DB rotation strategy.

Basic operations for static and dynamic (concept-level)

# Static: write an app config to kv v2
vault secrets enable -path=secret kv-v2
vault kv put secret/app/config username=svc-user password=s3cr3t
vault kv get secret/app/config

# Dynamic: get a temporary credential from a database role (configure the target in real envs)
# Example role creation (concept only)
# vault write database/roles/app-role db_name=mydb [email protected] default_ttl=1h max_ttl=24h
# Issue a temporary credential (with a Lease)
vault read database/creds/app-role
# Inspect / renew / revoke the Lease
vault lease lookup <lease_id>
vault lease renew <lease_id>
vault lease revoke <lease_id>
# Cut off a whole scope at once (by plugin or path)
vault lease revoke -prefix database/creds/

Auth and Token Issuance Flow: Key Points for AppRole / Kubernetes / OIDC

The Auth Method is the doorway. When authentication succeeds, Vault issues a Token. Auth never touches Secrets directly. Representative methods are userpass (PoC / learning), AppRole (for servers and jobs), Kubernetes (integrates with ServiceAccount JWTs), and JWT/OIDC (IdP integration).

Each Auth Method defines, via roles or mappings, the policies, TTLs, and constraints attached to issued Tokens. In design, decide first which workload enters under which role and what policies it gets — the boundaries fall into place from there.

• Auth Methods mount under /auth/*. Disable a mount and subsequent logins are rejected.
• An issued Token's permissions depend entirely on the Policies attached via its role.
• The Kubernetes integration verifies SA JWTs; OIDC maps claims from the IdP onto Vault roles.

AppRole: minimal flow from login to Token acquisition

# Enable AppRole
vault auth enable approle
# Create a role (attach the app-read policy to issued Tokens; TTL = 1h)
vault write auth/approle/role/myapp token_policies="app-read" token_ttl=1h token_max_ttl=24h
# Fetch RoleID and SecretID
ROLE_ID=$(vault read -field=role_id auth/approle/role/myapp/role-id)
SECRET_ID=$(vault write -field=secret_id -f auth/approle/role/myapp/secret-id)
# Authenticate and obtain a Token
vault write auth/approle/login role_id="$ROLE_ID" secret_id="$SECRET_ID"
# The auth.client_token in the JSON output is the Token to use for subsequent API / CLI calls

Policy (ACL) Basics: Path-Based, Capabilities, and Precedence

A Policy is a set of operational permissions on paths. The main capabilities are create, read, update, delete, list, and sudo. deny takes precedence and overrides allow. root grants everything and should be avoided in production.

The design knack is to map the logical boundaries of Secrets onto the path structure, then separate per-app roles and read-only vs. write boundaries. Enterprise Namespaces are a distinct feature (and can be treated as out of scope for Associate), so do not conflate them.

• The default Policy is attached to every Token (it covers a minimum slice of sys/capabilities).
• Be explicit about intent with path wildcards. list is a separate capability from read.
• Use sudo sparingly (e.g., for managing auth/* or specific sys/* operations).

Minimal Policy example (HCL) and application

# app-read.hcl
path "secret/data/app/*" {
  capabilities = ["read", "list"]
}
# Minimum admin scope to attach to a role / user
path "sys/leases/*" {
  capabilities = ["read", "list"]
}

# Register the Policy
vault policy write app-read app-read.hcl
# Verify the Token's permissions
vault token capabilities -policy=app-read secret/data/app/config

Token Types and Lifecycle: service / batch / periodic, Orphan, and Wrapping

A Token is a credential that carries permissions and a TTL. service is the standard persistent type, with renewal, revocation, and parent-child relationships. batch is lightweight, non-persistent, and non-renewable (for high throughput). periodic has no max TTL and requires periodic renewal. Create orphan Tokens (no parent) when you want to avoid the cascade from a parent revocation.

Response wrapping wraps an API response in a single-use wrapping token. Until you unwrap, the payload lives in the cubbyhole (a Token-specific scratch area), which helps reduce the risk of interception in transit.

• token renew only succeeds when the Token is renewable and within its limit. Operate periodic Tokens on the assumption that they will be renewed.
• Revoking a parent Token cascades to its children. orphan Tokens do not cascade.
• A wrapping token is single-use with a short TTL and is invalidated after unwrap.

Token create / renew / revoke and response wrapping

# Standard service Token
vault token create -policy=app-read -ttl=1h
# batch (non-persistent, non-renewable)
vault token create -type=batch -policy=app-read -ttl=15m
# periodic (no upper limit, requires renewal)
vault token create -policy=app-read -period=24h
# orphan (no parent, avoids cascading revocation)
vault token create -policy=app-read -orphan -ttl=1h

# Renew / inspect / revoke
vault token renew <token>
vault token lookup <token>
vault token revoke -accessor <accessor>

# Response wrapping (e.g., wrap a dynamic credential in 60s)
vault write -wrap-ttl=60s database/creds/app-role
# Unwrap on a separate hop (single-use)
vault unwrap <wrapping_token>

Associate Exam Key Points and Operational Checklist

The exam frequently asks about the separation of Auth and Secret responsibilities, Policy precedence, Token / Lease renew and revoke, the benefits of dynamic secrets, and the use cases for wrapping and cubbyhole. In practice, the keys are documenting your emergency revoke procedure and who enters under which role.

As a field check, build a mapping table of Auth role → Policy → path, verify with capabilities that least privilege still allows what you need, and rehearse cutting off access via Lease prefix revoke.

• Distinguish: Auth = doorway / Token issuance, Secret = what is protected, Policy = permissions, Token = the thing you carry.
• Precedence: deny wins, root is forbidden in production, and remember that default is always attached.
• TTL: Token and Secret Leases are managed independently. renew only succeeds within the cap.
• Dynamic secrets: auto-expiry and short lifetimes reduce risk.
• Wrapping: single-use safe handoff. Understand the cubbyhole.

Handy one-liners for verification

# What is this Token allowed to do? (Policy debugging)
vault token capabilities -token=$VAULT_TOKEN secret/data/app/*
# Path help (check available operations)
vault path-help database/creds
# Safety valve for revocation (by prefix)
vault lease revoke -prefix database/creds/
# Revoke by accessor (using an accessor recorded in logs)
vault token revoke -accessor <accessor>

Check Your Understanding

Frequently Asked Questions