How does Vault's AppRole auth method work, and what makes it a good fit for machine-to-machine authentication like CI pipelines?
Quick Answer
AppRole authenticates non-human clients using two pieces of information — a RoleID (like a username, relatively non-secret, tied to a specific policy set) and a SecretID (like a one-time or short-lived password, generated separately and often delivered through a different secure channel) — which together exchange for a Vault token. This split delivery model (RoleID baked into config/CI job, SecretID injected separately at runtime, e.g. via a CI secret store) avoids embedding a single long-lived Vault token or credential directly into pipeline configuration.
Detailed Answer
AppRole is Vault's recommended auth method for applications and automated systems (as opposed to human users, who'd typically use LDAP, OIDC, or similar). A RoleID identifies which AppRole (and therefore which Vault policies/permissions) is being used — it's not treated as highly secret and is often just checked into the pipeline configuration. The SecretID is the actual authentication credential and IS treated as sensitive; it can be configured with its own TTL, a limited number of uses, and CIDR restrictions on which IPs can use it.
The common CI pattern: the RoleID lives in the pipeline's config (low sensitivity), while the SecretID is generated per-run (or per some rotation policy) and delivered through the CI platform's own secret injection mechanism (e.g. a CI-native secret variable), so no long-lived Vault token is ever hardcoded anywhere. The pipeline calls vault write auth/approle/login role_id=... secret_id=... to exchange these for a short-lived Vault token scoped to whatever policies the AppRole is bound to, uses that token for the duration of the job, and the token expires on its own afterward.
This is preferred over embedding a static, long-lived Vault token directly in CI config because: the RoleID+SecretID split limits what a config leak alone exposes (RoleID without a valid SecretID grants nothing), SecretIDs can be constrained (limited uses, TTL, CIDR-bound) far more tightly than a general-purpose token, and different pipelines/services can have distinct AppRoles with least-privilege policies rather than sharing one broad credential.
Code Example
vault write auth/approle/login role_id="$ROLE_ID" secret_id="$SECRET_ID"
Interview Tip
Clarify explicitly that RoleID is low-sensitivity and SecretID is the real secret — mixing this up is the most common mistake candidates make when explaining AppRole.