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.