Authentication Methods and Identity

Vault separates two concerns crisply:

1. Authentication: Proving who you are → get a token
2. Authorisation: What that token can do → enforced by policies

This lesson covers authentication. Policies come next.

The Token: Vault's Universal Currency

Every API call to Vault carries a X-Vault-Token header. The token determines:

• Identity (the entity bound to it)
• Attached policies (what it can do)
• TTL (when it expires)
• Renewable / not renewable
• Use limit (how many requests it can make — optional)

Tokens look like hvs.CAESI.... You can also issue batch tokens — stateless tokens that don't consume storage; useful for short-lived, high-volume cases.

Enabling and Listing Auth Methods

vault auth list                                # see enabled methods
vault auth enable approle                      # turn on AppRole
vault auth enable -path=k8s-prod kubernetes    # enable at a custom path

Each method is mounted at a path (default = method name). You can mount the same method at multiple paths for multiple environments.

Auth Method 1: AppRole (Machine-to-Machine)

AppRole is the bread-and-butter machine auth. Each role has a RoleID (like a username — okay to embed in config) and a SecretID (like a password — must be delivered securely).

vault write auth/approle/role/web-api \
  token_policies="web-api" \
  token_ttl=1h \
  token_max_ttl=4h

# Distribute these to the app via your secure provisioning channel
vault read auth/approle/role/web-api/role-id
vault write -f auth/approle/role/web-api/secret-id

The app then logs in:

vault write auth/approle/login \
  role_id="..." \
  secret_id="..."
# returns a token

The art of AppRole is delivering the SecretID without storing it. Common patterns: wrap it in a one-time-use response_wrapping_token via your CI/CD, or push it via Consul-Template/agent.

Auth Method 2: Kubernetes

Kubernetes pods have a projected service-account JWT mounted at /var/run/secrets/kubernetes.io/serviceaccount/token. Vault's Kubernetes auth verifies that JWT against the cluster's TokenReview API, then maps it to a Vault role:

vault write auth/kubernetes/role/web-api \
  bound_service_account_names=web-api \
  bound_service_account_namespaces=production \
  token_policies=web-api \
  token_ttl=1h

From the pod:

vault write auth/kubernetes/login \
  role=web-api \
  jwt=@/var/run/secrets/kubernetes.io/serviceaccount/token

No SecretIDs to manage; the pod's identity is its proof.

Auth Method 3: AWS IAM

For workloads on EC2, ECS, EKS, or Lambda — use AWS IAM auth. Vault verifies a signed STS GetCallerIdentity request, confirming the workload's IAM role:

vault write auth/aws/role/web-api \
  auth_type=iam \
  bound_iam_principal_arn=arn:aws:iam::123:role/web-api-task \
  policies=web-api \
  ttl=1h

Azure (managed identities), GCP (service-account JWTs), and Alibaba have equivalent methods.

Auth Method 4: OIDC / JWT (Humans and Federated Workloads)

OIDC integrates with any IdP — Okta, Auth0, Google Workspace, Azure AD/Entra, Keycloak. Humans run vault login -method=oidc, browser opens, they authenticate, Vault issues a token bound to their groups.

JWT auth accepts any signed JWT — used for federation with CI/CD (GitHub Actions OIDC tokens, GitLab CI, Tekton, etc.).

Other Auth Methods

• userpass: username/password — fine for emergencies, not for daily use
• LDAP: Bind to corporate LDAP/AD
• TLS certificates: Client certs as identity (mTLS workloads)
• OCI: Oracle Cloud instance auth
• Tokens: The fallback — issue a token manually

The Identity System

Vault unifies multiple auth methods under identities. An entity represents a unique actor; aliases link different auth methods to the same entity.

Example: a developer named Alex authenticates via OIDC (Okta) from their laptop and via AppRole from their personal CI runner. Both are tied to a single entity "alex" — audit logs and policies follow the entity, not the auth method.

Entity groups

Entities can be grouped (engineering, security, sre). Policies can be assigned to groups, simplifying admin: "all members of the engineering group get the engineering policy".

Token TTLs and Renewal

Every token has:

• TTL: Current lifetime (e.g., 1h)
• max_ttl: Hard ceiling — token cannot live longer than this
• renewable: Whether vault token renew extends its TTL

Vault Agent (covered in lesson 8) automatically renews tokens before they expire so applications never see authentication errors.

Choosing an Auth Method

The principle: use the strongest identity the platform already provides — and never invent new credentials when the platform's existing ones (service account JWTs, IAM roles, OIDC tokens) will do.