The HashiCorp Vault plugin supports the following types of credentials:

  • Vault Token (recommended)
  • AppRole (for automation/service accounts)
  • Other Auth Methods (Kubernetes, LDAP, AWS IAM, OIDC, GitHub, etc.)
    • Use the resulting Vault token in the plugin configuration

Token Generation

Login to Vault

vault login

Use your organization's auth method (userpass/LDAP/OIDC/GitHub/etc.).

Create a Token with TTL

vault token create -policy="root" -ttl=24h
  • Replace root with a policy that grants read/list permissions to the engines you intend to scan.
  • Adjust -ttl (e.g., 1h, 24h, 72h). Tokens expire after TTL and must be renewed or recreated.

Non‑Expiring Tokens (Use with caution)

vault token create -policy="root"
  • Omitting -ttl creates a token with default TTL; in many setups this can be long-lived or effectively non-expiring depending on token role constraints.
  • Prefer short-lived, renewable tokens for security. If you must use a non-expiring token, scope it narrowly via policy and rotate periodically.

AppRole (Programmatic)

vault write auth/approle/login role_id="<ROLE_ID>" secret_id="<SECRET_ID>"
  • Extract the client_token from the response and use it as vaultToken in the plugin.

Required Policies / Permissions

Grant list/read on relevant paths. Example for KV v2 mounted at secret/:

# KV v2 data read/list
path "secret/data/*" {
capabilities = ["read", "list"]
}
 
# KV v2 metadata list (needed to enumerate)
path "secret/metadata/*" {
capabilities = ["list"]
}

For other engines (Transit, PKI, etc.), grant the minimal read/list capabilities needed to enumerate and read metadata.

Security Notes

  • Prefer short-lived, renewable tokens. Rotate credentials regularly.
  • Scope policies to the minimal paths required for discovery.
  • Avoid broadly-permissive tokens; use narrow mounts and namespaces.