Skip to content
Latchkey

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

Terminal
# 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

OptionPurpose
-method=NAMEAuth method (token, approle, jwt, oidc, …)
-path=PATHNon-default mount path for the method
-no-storeDo not persist the token to disk
-format=jsonMachine-readable token output

Related guides

Run this faster and cheaper on Latchkey managed runners. Start free →