Vault: Getting In (Auth Methods)

Before Vault will hand you any secret, you must prove your identity. Vault calls these proof mechanisms Auth Methods. Different types of clients — humans, servers, containers — need different ways to authenticate.

Human Authentication

Humans should not have separate Vault usernames and passwords to remember. Vault integrates with existing identity providers:

• OIDC (OpenID Connect): Vault redirects the user to your company's identity provider (Okta, Google Workspace, Azure AD). The user logs in with their standard SSO credentials and MFA. The identity provider issues a token that Vault validates. The human never creates a Vault-specific password.
• LDAP: For organizations using Active Directory or OpenLDAP, Vault can validate credentials directly against the directory.
• GitHub: Vault can authenticate users based on their GitHub organization membership and team — useful for smaller engineering teams.

Machine Authentication

Applications and servers cannot use SSO or MFA. They need programmatic authentication methods:

• AppRole: The machine equivalent of a username and password. An application is given a RoleID (like a username, not secret) and a SecretID (like a password, kept secret). It presents both to Vault to receive a token. SecretIDs can be single-use and short-lived, making them much safer than static passwords.

• Kubernetes Auth: This is the standard method for workloads running in Kubernetes. Every Kubernetes Pod automatically receives a Service Account Token — a JWT signed by the Kubernetes API server. Vault is configured to trust your Kubernetes cluster. When a Pod wants to authenticate, it sends its Service Account Token to Vault (a login call naming the target role and passing the token read from the Pod's mounted ServiceAccount file). Vault calls the Kubernetes API to verify the token is valid and identifies which Pod, namespace, and service account is making the request. Vault then maps that identity to a policy and issues a Vault token. No secrets need to be pre-provisioned into the Pod.

The Token: What You Get After Login

Regardless of which auth method you use, a successful login always produces a Vault Token. This token is what you present for all subsequent requests. Tokens have:

• A TTL (Time-To-Live): They expire automatically.
• Policies attached: Defining exactly what paths and operations are permitted.
• An accessor: A non-sensitive identifier that lets administrators audit and revoke tokens without knowing the token value itself.