vault login: Auth Methods, Tokens & CI Errors
Authenticate to Vault and obtain a usable client token.
vault login authenticates against an auth method and stores the resulting token for subsequent commands. In CI you use a non-interactive method such as AppRole or JWT/OIDC instead of a human token.
What it does
vault login -method=<method> exchanges credentials for a Vault token and caches it (by default in ~/.vault-token). The default token method takes a token directly; AppRole takes a role_id/secret_id; JWT/OIDC takes a signed CI token. After login, other commands use that token automatically.
Common usage
# Token method (set VAULT_ADDR first)
export VAULT_ADDR=https://vault.example.com:8200
vault login token=hvs.xxxxxxxx
# AppRole (machine-to-machine, common in CI)
vault login -method=approle role_id="$ROLE_ID" secret_id="$SECRET_ID"
# CI OIDC/JWT (e.g. a GitHub Actions ID token)
vault login -method=jwt role=ci jwt="$ACTIONS_ID_TOKEN"Common error in CI: VAULT_ADDR unset / method not enabled
login fails with "Error checking seal status ... no address" (VAULT_ADDR not set) or "auth method not enabled" / "invalid role or secret id". Fix: export VAULT_ADDR (and VAULT_NAMESPACE on Vault Enterprise/HCP), confirm the auth method is mounted (vault auth list), and pass the right credentials - for AppRole, a fresh secret_id; for JWT, the CI-issued token and a role bound to your repo. Prefer AppRole/OIDC over static tokens so credentials are short-lived.
Key options
| Option | Purpose |
|---|---|
| -method=NAME | Auth method (token, approle, jwt, oidc, …) |
| -path=PATH | Non-default mount path for the method |
| -no-store | Do not persist the token to disk |
| -format=json | Machine-readable token output |