HashiCorp Vault Guide: Auth Methods, Dynamic Secrets and Operations

HashiCorp Vault concentrates an organisation's most valuable machine credentials in one place, so a weak auth method, a surviving root token or an unmonitored audit gap turns the secrets manager into the single best target in the estate. This guide covers identity, policies, tokens and leases, auth methods for workloads, dynamic secrets and PKI, and production operation of seal, audit and upgrades. It is for platform engineers and operators running Vault Community, Enterprise or HCP Vault Dedicated. HashiCorp became part of IBM in February 2025; new Vault releases have shipped under the Business Source License 1.1 since August 2023, and the OpenBao fork (an OpenSSF sandbox project) shares most concepts here.

Key takeaways

• Everything in Vault resolves to a token. Auth methods exchange an external identity (a Kubernetes service account, a cloud role, an OIDC login) for a Vault token carrying policies, a TTL and a parent, so token hygiene is identity hygiene.
• Deny is the default, and deny always wins. An empty policy grants nothing, the most specific path match applies, and a deny capability overrides every other capability including sudo.
• Dynamic secrets beat stored secrets. Database, cloud and PKI engines issue leased, per-client credentials that Vault revokes on expiry or on demand, including by prefix during an incident.
• Root tokens are for setup and emergencies only. Revoke the initial root token after configuration, regenerate one with vault operator generate-root and a key-holder quorum when needed, and revoke it again afterwards.
• Audit devices are a hard dependency. Vault refuses requests it cannot log to at least one enabled audit device, so run two or more devices and ship the logs off the host.

How identity and access work in HashiCorp Vault

Vault separates who you are (auth methods and the identity store) from what you may do (ACL policies attached to tokens, entities and groups). Every request after login carries a token, and the token's policies, plus any entity and group policies, decide the outcome.

Auth methods

Auth methods mount under auth/ (default path auth/<type>) and can be mounted more than once at different paths. Disabling a mount logs out every client that authenticated through it. For external methods such as LDAP, Okta or GitHub, Vault rechecks the external account at login and on token renewal, but tokens already issued stay valid for their grant period unless revoked in Vault, which is why short TTLs matter.

Entities, aliases and groups

• Entity: a consolidated record of a client. An entity can hold aliases from several auth methods, but only one alias per auth mount.
• Alias: the link between an entity and one account on an auth mount (a username, a GitHub login, a Kubernetes service account UID). Mount accessor plus alias name uniquely identify it.
• Groups: internal groups are managed in Vault; external groups map to an LDAP group, GitHub team or IdP group and are refreshed only at login or token renewal, so a removal upstream does not take effect until then.
• Policy evaluation: entity and group policies are evaluated at request time and are additive to the token's own policies. Write access to identity endpoints is an escalation path, because anyone who can edit entities, aliases or group membership can grant themselves policies.

Policies

Policies are HCL or JSON path rules. Capabilities are create, read, update, patch, delete, list, sudo (needed for root-protected paths), deny, subscribe (events) and recover (restore from snapshot). Generating database credentials needs read on database/creds/<role>, because capabilities map to the HTTP verb. The * glob works only as the final character; + matches exactly one path segment. Templated policies insert identity values with {{identity.entity.id}} style placeholders; use IDs, not names, because names can be changed. required_parameters, allowed_parameters and denied_parameters constrain request bodies, but are not supported on KV version 2.

Admin roles and privileged access

Vault has no built-in "administrator" role. Privilege comes from the root policy, from sudo on root-protected paths, and from write access to sys/, auth/ and identity/. Design these as distinct, narrow personas.

• Root token lifecycle: the initial root token from vault operator init should be used for bootstrap and then revoked. Root tokens are the only tokens that can be created without an expiry.
• Namespaces (Enterprise and HCP Vault Dedicated): do daily work in administrative namespaces and reserve the root namespace for tasks that strictly need it.
• Host access: anyone with shell on a node, or write access to the storage backend, can tamper with Vault data without a token.
• Emergency seal: sealing through the API discards the root key from memory (root privilege needed), a containment step during an intrusion. Document who may do it. See the Break-Glass Account Guide.
• Offboarding: removing a person from the IdP may not revoke Vault access. Remove the entity from groups, revoke its active leases and tokens, and delete the entity; disable rather than delete auth mounts you retire.

Integrations, API tokens and service accounts

Tokens, TTLs and leases

• Token types: service tokens (prefix hvs. since Vault 1.10) support renewal, revocation and child tokens; batch tokens (hvb.) are lightweight encrypted blobs with no storage write, no renewal and no revocation of their own; recovery tokens use hvr.. The prefixes help secret scanners.
• TTLs: every non-root token has a TTL. The system max TTL defaults to 32 days and can be lowered per mount. An explicit max TTL is a hard cap even for periodic tokens, which otherwise live for as long as they keep renewing.
• Hierarchy: revoking a parent token revokes its children and their leases. Orphan tokens escape that tree, so restrict auth/token/create-orphan and token roles that create orphans.
• Leases: dynamic secrets and service tokens carry leases with a lease ID that begins with the request path. vault lease revoke -prefix aws/ revokes every AWS credential Vault issued, the fastest containment lever Vault offers. KV secrets do not have leases.

Choosing a workload pattern

Kubernetes and AppRole specifics

• Kubernetes reviewer JWT: when Vault runs in the cluster, omit token_reviewer_jwt so Vault uses and periodically re-reads its own short-lived service account token (Vault 1.9.3 or later). Using each client's JWT as the reviewer avoids storing any JWT but needs system:auth-delegator for every client. Avoid long-lived reviewer token Secrets. See the Kubernetes NHI Security Guide.
• Kubernetes roles: set bound_service_account_names and bound_service_account_namespaces to explicit values, never * for both, and keep the resulting token TTL short.
• AppRole: keep bind_secret_id enabled, set secret_id_ttl and secret_id_num_uses, restrict logins with secret_id_bound_cidrs and token_bound_cidrs, and deliver the secret_id as a response-wrapped token from a trusted orchestrator (for example the CI system) so only the final client unwraps it. HashiCorp recommends batch tokens with AppRole. User lockout is on by default: 5 failed attempts lock the alias for 15 minutes.
• CI/CD: prefer JWT/OIDC auth bound to the pipeline's identity token claims (repository, branch, environment) over a stored AppRole secret_id or a long-lived Vault token in a CI variable. See the CI/CD Pipeline Identity Security Guide.

Dynamic secrets and PKI

• Database engine: dynamic roles create a unique user per request via creation_statements (for example default_ttl="1h", max_ttl="24h"); static roles rotate the password of an existing account on a rotation_period or rotation_schedule. Immediately run vault write -force database/rotate-root/<connection> so only Vault knows the management credential, and never put that root user in a static role.
• PKI: keep the root CA outside Vault where possible, issue from an intermediate on its own mount, use roughly 30 to 90 day leaf lifetimes, keep allow_any_name false and scope allowed_domains, enable auto-tidy and automatic CRL rebuilds, and set no_store=true only for very short-lived, high-volume certificates (serial-number revocation is then unavailable). Public ACME directories should enforce eab_policy=always-required. See the Machine Identity, PKI and Certificate Lifecycle Guide.

Logging and detection

Audit devices (file, syslog, socket) record every request and response. Most string values are written as keyed HMAC-SHA256 hashes, not plaintext; integers and booleans are not hashed. Use sys/audit-hash/<device> to hash a known value (a token or a leaked secret) and search for it. Setting hmac_accessor=false leaves token accessors readable so you can correlate a token's activity across events.

Relevant ATT&CK techniques include T1555 Credentials from Password Stores, T1552.001 Credentials In Files (Agent sink files, unseal keys on disk) and T1528 Steal Application Access Token.

Metrics that show the programme is working:

• Dynamic share: percentage of secrets consumed as dynamic, leased credentials rather than KV values.
• Static age: maximum age of KV secrets and static role passwords against policy.
• Root token hours: time any root token existed per quarter (target: only during approved break-glass).
• Long TTL tokens: count of non-root tokens with TTL above 24 hours or no explicit max TTL.
• Audit coverage: number of healthy audit devices per cluster (target two or more) and log delivery lag to the SIEM.

Hardening baseline

1. Host and process: run Vault as a dedicated unprivileged user that cannot modify its binary or configuration; one Vault process per host (bare metal, then VM, then container); disable SSH and remote desktop where you can; use the packaged systemd unit options such as ProtectSystem=full, PrivateTmp=yes, NoNewPrivileges=yes; add SELinux or AppArmor.
2. Memory: disable swap, or keep mlock enabled, and if mlock is disabled with Integrated Storage, encrypt swap; disable core dumps (LimitCORE=0 in systemd or RLIMIT_CORE 0).
3. Network: TLS end to end including load balancers and storage, TLS 1.3 where possible, HSTS through custom response headers; restrict the API listener (default port 8200) and cluster port (default 8201) to the clients and peers that need them; send outbound traffic through a proxy you can observe.
4. Seal: choose auto-unseal (cloud KMS, HSM or Transit) for availability, and authenticate it with platform identity (instance profile, managed identity, service account) rather than keys in the seal stanza; use VAULT_HSM_PIN as an environment variable if an HSM PIN is unavoidable. Protect the KMS key from deletion: if it is permanently deleted the cluster cannot be recovered, even from backups. Recovery keys authorise generate-root and rekey but cannot unseal.
5. Key custody: with Shamir unseal, distribute shares to separate named custodians, store them offline, pass them to vault operator unseal on standard input rather than as arguments, and rehearse rekeying when a custodian leaves.
6. Storage: put Integrated Storage on its own partition, restrict access to the storage layer, and keep regular, encrypted snapshots with restore tests.
7. Policies as code: manage auth mounts, policies and engines through a reviewed pipeline; keep globs and templates to a minimum and set deny_slash_in_templated_paths=true.
8. Lifetimes: lower mount max TTLs, set explicit max TTLs on periodic tokens, and confirm user lockout thresholds for AppRole, LDAP and userpass.
9. Audit: at least two audit devices, log rotation and central collection, restricted access to log files.
10. Upgrades and plugins: follow the security announcement list, prefer immutable upgrades (new nodes on the new version join, unseal, then old nodes are destroyed), and vet every external plugin before registration.

Rollout and rollback: introduce a new auth method or tighter policy on a separate mount path first, migrate one application per ring, watch permission-denied counts in the audit log, then retire the old path. Rollback is a revert of the policy code; keep the old mount until the last client moves.

Small versus large estates: a single team can run one Integrated Storage cluster with auto-unseal, two audit devices and Vault Agent. Larger organisations add namespaces or separate clusters per trust boundary, performance and disaster recovery replication (Enterprise), seal high availability with two or three seals from different regions or providers. See the Secrets Management Guide and, for product selection, the Secrets Management Buyer's Guide.

Common misconfigurations

• Keeping the initial root token. A stored "just in case" root token is a non-expiring master key.
• Vault as a static KV store only. Long-lived database passwords and cloud keys copied into KV still leak and still need manual rotation; dynamic engines and leases are the reason to run Vault.
• Broad roles and globs. path "secret/*" { capabilities = ["read","list"] } for every app, or Kubernetes roles bound to * service accounts in * namespaces, turn one compromised pod into access to every secret.
• Secret zero in plain sight. AppRole secret_ids, Vault tokens or unseal keys stored in CI variables, images or scripts. Machine secrets that live with people are equally exposed: in the LastPass breach, a DevOps engineer's vault held the AWS and backup decryption keys that unlocked customer data.
• Signing and release keys in general pipelines. In the HashiCorp GPG key exposure, a tampered Codecov script in CI captured HashiCorp's own release signing key from the environment. Keep signing in Vault Transit or an HSM with a dedicated, isolated job.
• Single audit device or no off-host logs. One full disk can stop Vault serving requests, and local-only logs can be altered by anyone with shell access.

Framework mapping

Practitioner checklist

• Revoke the initial root token and document the generate-root quorum procedure and its custodians.
• Enable at least two audit devices, forward to the SIEM, and alert on root policy use and writes to sys/audit, sys/auth and identity/.
• Move workloads to platform-identity auth (Kubernetes, cloud IAM, JWT/OIDC) and bind roles to explicit service accounts, namespaces and claims.
• Replace static database and cloud credentials with dynamic roles, run rotate-root on every connection, and lower mount max TTLs.
• Deliver any remaining AppRole secret_ids response-wrapped, with TTL, use limits and CIDR bindings.
• Configure auto-unseal with platform identity, protect the KMS key from deletion, and test snapshot restore.
• Apply the host baseline: unprivileged user, no swap or mlock on, no core dumps, single tenancy, TLS 1.3.
• Manage policies, mounts and auth methods as reviewed code, and separate identity administration from policy authoring.
• Rehearse prefix revocation (vault lease revoke -prefix) and emergency seal in an incident exercise.

Standards and references

• HashiCorp: Vault production hardening
• HashiCorp: Vault policies
• HashiCorp: Vault tokens
• HashiCorp: Vault seal and unseal
• HashiCorp: Vault audit devices
• HashiCorp: Vault Kubernetes auth method
• HashiCorp: PKI secrets engine considerations
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Secrets Management Guide · Secrets Rotation Runbook Template · Terraform Cloud and HCP Security Guide · NHI Authentication Guide · Top 10 Secrets Management Mistakes