Vault Dynamic Secrets: Short-Lived Credentials for Production and Exam Prep

Dynamic Secrets are short-lived credentials that are issued on demand and automatically revoked when their TTL expires. The biggest win is that they cut both leak risk and operational overhead at the same time.

This article focuses on the concepts and operational patterns most often tested at the Vault Associate / Operations level, with CLI/API walkthroughs, comparison tables, and diagrams that make the full picture click.

1. Dynamic Secrets Basics and the Value of Short-Lived Credentials

Vault's Dynamic Secrets generate unique credentials in the backend on every request, and Vault automatically disables or deletes them once the TTL is reached. This eliminates the long-lived shared passwords that linger because nobody remembers to clean them up, minimizing the blast radius if a credential ever leaks.

The key point is that issuance and revocation are both managed under Vault's lease system. Each credential comes with a lease_id and a lease_duration, and clients can renew or explicitly revoke as needed. This also pairs well with audit logging — you can trace who used which privileges and when.

• Main targets: Database, Cloud (AWS/Azure/GCP), PKI, SSH
• Automatic revocation: auto-revoke on TTL expiry; explicit revoke is also supported
• Least privilege: scoped per role, issued on demand
• Audit-friendly: issuance, renewal, and revocation are all auditable events

On-demand issuance and automatic revocation flow

Minimum configuration example (Database Secrets Engine / Postgres)

vault secrets enable database

vault write database/config/my-postgres \
  plugin_name=postgresql-database-plugin \
  allowed_roles=readonly \
  connection_url="postgresql://{{username}}:{{password}}@db.example.com:5432/postgres?sslmode=verify-full" \
  username="vault_admin" \
  password="s3cr3t"

vault write database/roles/readonly \
  db_name=my-postgres \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
  default_ttl=1h \
  max_ttl=24h

# 短命クレデンシャルの取得
vault read database/creds/readonly
# 出力例: username, password, lease_id, lease_duration, renewable など

2. TTL/Lease Fundamentals: default_ttl, max_ttl, renew, revoke

Every Dynamic Secret comes with a lease_id and a lease_duration. The lease_duration is the effective TTL at issuance, and you can call lease renew when you need more time. Renewals, however, cannot exceed the role's max_ttl or the system-wide max TTL.

Renewal can fail in three situations: leases with renewable=false, extensions that would breach a ceiling, or backend-specific constraints. When the lease expires, Vault disables or deletes the credential on the target system. Token TTLs and secret TTLs are separate — whichever expires first will block further fetches or renewals.

• Key fields: lease_id, lease_duration (seconds), renewable (true/false)
• Ceilings: cannot exceed the role's max_ttl or the system-wide max_lease_ttl
• Renewal: extend with vault lease renew LEASE_ID (when permitted)
• Revocation: vault lease revoke LEASE_ID, or -prefix for bulk revocation

TTL, renewal, and revocation timeline

Inspecting, renewing, and revoking leases

# JSON 出力で lease を確認
vault read -format=json database/creds/readonly | jq '.lease_id, .lease_duration, .renewable'

# 更新(延長)
vault lease renew <LEASE_ID>

# 即時取り消し
vault lease revoke <LEASE_ID>

# パス配下を一括取り消し
vault lease revoke -prefix database/creds/readonly

3. Cloud Dynamic Credentials (AWS/Azure/GCP): Key Points

Cloud engines issue short-lived temporary credentials, eliminating the distribution and recovery problems that come with long-lived keys. On AWS, STS-based temporary credentials are the recommended path, with IAM user generation reserved for edge cases. Azure and GCP follow the same pattern, centering on short-lived tokens and ephemeral keys.

From an exam perspective, the points most likely to be tested are: choosing the right credential_type, keeping TTL/Max TTL consistent, scoping role permissions, and understanding what revocation actually does (STS expiry, key deletion, and so on).

• AWS: credential_type=sts is the short-lived default; iam_user tends to be long-lived
• Azure: short-lived secrets via service principals; mind the RBAC assignment scope
• GCP: disposable keys and access tokens; minimize privileges through roleset design

Issuing temporary cloud credentials through Vault

Example: using STS with the AWS engine

vault secrets enable aws

vault write aws/config/root \
  access_key=AKIA... \
  secret_key=... \
  region=ap-northeast-1

vault write aws/roles/readonly-sts \
  credential_type=sts \
  role_arn=arn:aws:iam::123456789012:role/ReadOnlyRole \
  default_sts_ttl=900 \
  max_sts_ttl=3600

vault read aws/sts/readonly-sts  # AccessKeyId/SecretAccessKey/SessionToken と TTL を取得

4. Application Integration Patterns: Agent/Sidecar, Templates, Wrapping

You can either embed the Vault client directly in your application or deploy Vault Agent as a sidecar/daemon that writes credentials to a file. Because Dynamic Secrets are short-lived, the design around file updates plus signal-based reloads — or reconnection — is critical.

From a zero-trust angle, Response Wrapping reduces exposure of credentials and tokens along the handoff path. The exam often probes the one-time, short-lived nature of wrapping tokens and where the responsibility for unwrap lies.

• Render environment variables / config files via Vault Agent Template
• Renew/reload loop: refresh and reload between 1/2 and 2/3 of the TTL
• Secure handoffs across intermediaries with Response Wrapping

Credential delivery via an Agent sidecar

Minimum Vault Agent config example (AppRole + Template)

auto_auth {
  method "approle" {
    mount_path = "auth/approle"
    config = {
      role_id_file_path = "/etc/vault/role_id"
      secret_id_file_path = "/etc/vault/secret_id"
    }
  }
  sink "file" {
    config = { path = "/etc/vault/token" }
  }
}

template {
  source      = "/etc/vault/templates/db.tpl"
  destination = "/etc/secrets/db.env"
  command     = "/usr/local/bin/reload-app"
}

vault {
  address = "https://vault.example.com:8200"
}

# db.tpl の例:
# export DB_USER="{{ with secret \"database/creds/readonly\" }}{{ .Data.username }}{{ end }}"
# export DB_PASS="{{ with secret \"database/creds/readonly\" }}{{ .Data.password }}{{ end }}"

5. Security, Audit, and Operational Control: Policies and Bulk Revocation

To enforce least privilege, grant the application token only the read paths it actually needs (e.g. database/creds/role). Administrators can use revoke -prefix to perform planned bulk revocations scoped to a blast radius. Audit logs trace every issuance, renewal, and revocation, making incident response much easier.

Common exam pitfalls include conflating token TTL with secret TTL (they are independent), misunderstanding the relationship between default_ttl and max_ttl, and the behavior of orphan tokens with respect to revoke propagation. Keep each concept cleanly separated in your head.

• Grant only the minimum capabilities (list/read) in each policy
• Enable audit via file/socket/sink and keep clocks synchronized
• revoke -prefix has wide impact — run it during a maintenance window
• default_ttl ≤ max_ttl; mismatches cause creation/update errors

Lease hierarchy and bulk revocation picture

Least-privilege policy and enabling audit

# アプリが readonly 資格情報だけ取得可能にする例
path "database/creds/readonly" {
  capabilities = ["read"]
}

# 監査ログをファイルで有効化
vault audit enable file file_path=/var/log/vault_audit.log

6. Troubleshooting and an Associate/Ops Checklist

Common failures include role name mismatches, renewals that exceed max_ttl, insufficient backend privileges (e.g. no CREATE ROLE on the DB), and insufficient token capabilities (no read). When you see messages like lease TTL too large, permission denied, or no handler for route, suspect TTL ceilings, policy issues, and mount/path mistakes respectively.

In production, the keys to stable operation are: a connection pool refresh strategy (reconnect on rotation), a retry window for network partitions, and visibility into audit logs and metrics (issuance failure rate, renewal failure rate).

• Check path/role/policy first: surface them via sys/mounts and list
• For TTL mismatches, adjust the role's default_ttl/max_ttl and the system ceiling
• Verify backend privileges (e.g. CREATE ROLE on Postgres)
• Renew between 50–70% of the TTL; fall back to re-fetching on failure

Quick diagnostic flow

Diagnostic command / API snippets

# マウント一覧
vault list sys/mounts

# ロール定義の確認
vault read database/roles/readonly

# API 例: 認証後に creds を取得
curl -s \
  -H "X-Vault-Token: $VAULT_TOKEN" \
  https://vault.example.com/v1/database/creds/readonly | jq

Check Your Understanding

Frequently Asked Questions