Compare authentication methods practice questions

Migrate users to an external identity provider and use LDAP or OIDC auth.

Userpass cannot enforce password complexity or expiration natively, so migrating users to an external identity provider via LDAP or OIDC delegates those controls to a system designed for credential lifecycle management, satisfying the stem's enforcement requirement.

Okta

Okta auth delegates verification to Okta as the identity provider, supporting multi-factor flows including time-based one-time passwords generated by authenticator apps. Vault trusts Okta's assertion, so the OTP requirement is satisfied without Vault storing the factor itself.

Kubernetes

Kubernetes auth has pods present their service account JWT to Vault, which validates it against the cluster's TokenReview API. The token is short-lived and projected automatically, so no static secret is stored, meeting the no-static-secret requirement.

AWS

AWS auth relies on the instance identity document and IAM role credentials delivered via the instance metadata service. These are short-lived and rotated automatically, so no static secret is stored on the machine, satisfying the no-static-secret constraint.

Setting a secret_id_num_uses limit

A secret_id_num_uses limit restricts how many times a SecretID can authenticate, so a leaked or intercepted SecretID cannot be replayed indefinitely. This bounds the window of misuse, directly strengthening AppRole security by limiting credential reuse.

Binding the SecretID to a specific CIDR block

Binding a SecretID to a specific CIDR block means authentication succeeds only from permitted network ranges. A stolen SecretID is therefore useless from an attacker's host, adding a network-origin constraint that complements RoleID and SecretID secrecy.

Setting a secret_id_ttl

Setting a `secret_id_ttl` limits how long a SecretID remains valid, so a leaked credential cannot be replayed indefinitely. This directly satisfies the stem's security requirement by enforcing credential expiry, reducing the attack window if a SecretID is intercepted during delivery to the application.

Use Kubernetes auth, create a role per microservice, bind to specific service account names, and assign appropriate policies.

Kubernetes auth binds a Vault role to a service account name and namespace, so each microservice's distinct service account maps to its own role and policy. This removes SecretID distribution and prevents cross-service access, meeting every stated requirement.

KV: Stores arbitrary secrets as key-value pairs.

The KV secret engine is designed for static storage of secrets like passwords and API keys.

AWS: Generates dynamic AWS IAM credentials.

The AWS secret engine dynamically creates temporary IAM credentials for accessing AWS services.

PKI: Issues X.509 certificates.

The PKI secret engine manages the lifecycle of X.509 certificates for TLS.

Create separate AppRole roles for each application

Sharing one role means every application's login mints tokens against the same role, multiplying token count. Distinct roles per application let each use its own Secret IDs and token TTLs, cutting issuance while preserving least-privilege scoping.

Add the 'email' scope to the OIDC auth method config

Policy mapping relies on claims returned in the token, and the email claim is only released when the email scope is requested. Adding the email scope to the OIDC auth method configuration makes the IdP include that claim, satisfying the stem's mapping requirement.

GitHub

Vault's GitHub auth method delegates authentication to GitHub using OAuth, mapping a GitHub user or team to a Vault token via configured policies. It is a supported auth method alongside token, userpass, LDAP, AppRole, AWS and Kubernetes, making GitHub valid for machine and human login.

Cloud Foundry

Cloud Foundry auth is a valid Vault authentication method, letting CF instances present their instance identity to obtain a Vault token. It is enabled through the auth plugin catalogue rather than the core binary, but remains a supported, legitimate method.

Token auth is always enabled and cannot be disabled

Token auth is built into Vault's core and is always mounted; it cannot be disabled or unmounted like plugin-based methods such as LDAP, AppRole or AWS IAM, which administrators can enable and disable at will.

Token auth is typically used for Vault's own internal token management, not for end-user authentication

Token auth underpins Vault's internal token lifecycle — issuing, renewing and revoking service tokens — rather than verifying external identities. Other methods, such as LDAP, OIDC or Microsoft Entra ID, authenticate end users or machines against an external identity source before Vault mints a token. This satisfies the stem's distinction between internal token management and end-user authentication.

AWS IAM authentication

AWS IAM authentication lets Vault verify EC2 instance identity through signed metadata, issuing short-lived tokens with no stored secrets. IAM role credentials rotate automatically, satisfying both the no-secrets-in-source-code and automatic-rotation constraints. It suits AWS-hosted workloads specifically, unlike static token or AppRole methods.

secret_id_num_uses=1, secret_id_ttl=1h

secret_id_num_uses=1 enforces single-use Secret IDs, while secret_id_ttl=1h expires them after one hour using Vault's duration format. Together they satisfy both constraints in the stem: each Secret ID usable only once and expiring after one hour.

JWT/OIDC authentication

JWT/OIDC validates tokens issued by an external identity provider, so EC2, Kubernetes and datacentre workloads all present a signed JWT rather than a shared secret. That satisfies the stem's requirement for one method spanning all three environments.

OIDC authentication

OIDC authentication validates the JWT signature locally against the provider's JWKS public keys and verifies claims such as audience and expiry, so Vault never calls Microsoft Entra ID per login. This satisfies the requirement for signature and claim validation without contacting the identity provider each time.

Set the 'groups' attribute to 'memberOf'

Setting the 'groups' attribute to 'memberOf' is mandatory because Vault's LDAP auth method reads group membership from that attribute during login. Without it, Vault cannot resolve the user's LDAP groups, so external group mapping to Vault policies fails, breaking the required group-based policy assignment.

Userpass authentication

Userpass authentication supports MFA natively because Vault's login MFA enforcement applies to the userpass auth method's login path, requiring a second factor after the password check. This satisfies the stem's constraint of native MFA support within Vault Enterprise, without relying on external identity provider integration.

LDAP authentication

LDAP authentication supports MFA natively through Vault's login MFA enforcement, which applies a second factor after the LDAP bind succeeds. This satisfies the stem's requirement for native MFA support, unlike methods requiring external orchestration. Vault's identity MFA engine integrates directly with the LDAP auth method's login path.

AppRole requires a role_id and secret_id, while Kubernetes requires a service account token.

AppRole authenticates machines using a role_id plus a secret_id credential pair, whereas Kubernetes authentication validates a pod's service account token against the cluster's TokenReview API. This satisfies the stem's requirement to distinguish the two methods by their actual credential mechanism, confirming AppRole's dual-secret model versus Kubernetes' token-based validation.

Kubernetes authentication uses JWT tokens that are signed by the Kubernetes API server.

Kubernetes authentication relies on service account JWTs signed by the cluster's API server, which Vault validates against the cluster's public keys. This satisfies the stem's requirement to distinguish it from AppRole, where authentication instead uses a Role ID and Secret ID pair issued directly by Vault.

Userpass authentication

Userpass issues Vault tokens on successful username and password login, and those tokens accept TTL and renewable parameters like any other auth method's tokens. It therefore satisfies the stem's requirement for TTL and renewal support.

Token authentication

Token authentication issues client tokens carrying an explicit TTL and renewable flag, so Vault can extend their lifetime via token renew. This satisfies the stem's requirement for token generation with TTL and renewable options, unlike methods that only validate external credentials.

LDAP authentication

LDAP authentication binds against a directory and then issues a Vault token whose TTL and renewable status are governed by the role's token_ttl and token_max_ttl settings. This satisfies the stem's requirement that the method generate tokens with TTL and renewable options.

vault auth disable token/

`vault auth disable token/` targets the token auth method mounted at the default `token/` path, which `vault auth list` shows as enabled. Disabling it removes that mount entirely, satisfying the administrator's goal of turning off the default token authentication method. Other mounts remain unaffected.

The user has a custom `ttl` set in the userpass configuration for user 'john'.

A per-user TTL in the userpass user entry overrides the mount's token_ttl. Vault applies the most specific setting, so john's custom ttl of 768 hours takes precedence over the mount-level 24-hour default, producing the longer token duration.