vault login: Authenticate to HashiCorp Vault
vault login authenticates to a Vault server using a chosen auth method and caches the resulting token for later commands.
Every Vault CLI call needs a token. In CI you typically use a short-lived auth method (JWT/OIDC from the runner identity or AppRole) rather than a static token, so nothing long-lived is stored.
What it does
vault login authenticates using -method (token, jwt, approle, aws, etc.) and stores the token at ~/.vault-token so subsequent commands are authorized. VAULT_ADDR points the CLI at the server; VAULT_TOKEN can supply a token directly without vault login.
Common usage
export VAULT_ADDR=https://vault.internal:8200
# JWT/OIDC using the CI runner identity
vault login -method=jwt role=ci jwt="$CI_JOB_JWT"
# AppRole
vault write auth/approle/login role_id="$ROLE_ID" secret_id="$SECRET_ID"Options
| Flag / env | What it does |
|---|---|
| -method <name> | Auth method: token, jwt, approle, aws, ... |
| -no-store | Do not persist the token to ~/.vault-token |
| -format=json | Machine-readable output for scripting |
| VAULT_ADDR | Vault server address |
| VAULT_TOKEN | Token used directly, skipping vault login |
In CI
Prefer JWT/OIDC so the runner's own identity authenticates and Vault issues a short-lived token; avoid baking a static VAULT_TOKEN into the pipeline. Set VAULT_ADDR once as an environment variable for the whole job.
Common errors in CI
"Error making API request ... connection refused" or "no such host" means VAULT_ADDR is wrong or unreachable. "permission denied" on login means the role or credentials are not authorized. "* role \"ci\" could not be found" means the JWT auth role is misnamed. A missing VAULT_ADDR yields "Get \"https://127.0.0.1:8200/...\": connection refused" because it defaults to localhost.