Without AppRole, your automated scripts and applications would need to store a long-lived password or an access key in a configuration file, putting every secret in your organisation at risk if that file is ever leaked. AppRole solves this by giving each machine a temporary, renewable identity that can be revoked instantly. For the VA-003 exam, you must understand how this machine-to-machine authentication works because it is one of the most tested ways to secure non-human access to Vault.
Jump to a section
A simple way to picture AppRole Authentication
3 distinct items must arrive at a secure warehouse before a delivery driver can pick up a package: a specific Role ID card and two parts of a secret key (a Secret ID). The warehouse manager issues the Role ID card—a fixed, publicly known label pinned to the driver's clipboard. The manager also hands over a sealed envelope containing the first half of the key. The driver must then, in a separate meeting, collect the second half of the key from a different supervisor, who scribbles it on a sticky note. Only when the driver presents both the Role ID card AND the complete secret—both halves taped together—does the warehouse guard unlock the package locker. If the driver loses the sticky note or forgets the card, the locker stays shut. The warehouse manager can cancel the whole operation by invalidating the Role ID without ever touching the driver's clipboard. This system was invented because earlier, drivers used a single master key that, if copied by a thief, gave access to every package forever. By splitting the credential into two parts with one part constantly rotating, AppRole makes it hard for an attacker to reuse stolen credentials.
The mapping: the Role ID is like the clipboard label—unique but not secret. The Secret ID is the two-part key. The warehouse is the Vault server, and the package is the temporary authentication token. The driver is a machine (like a server or application).
AppRole is a method for machines—servers, applications, scripts, or microservices—to prove their identity to HashiCorp Vault and obtain a temporary token. Think of it as a visitor badge for a robot. The robot cannot walk in using a username and password like a human would; instead, it needs a special two-part credential.
The first part is called the Role ID. This is like a barcode on the robot's chassis. It is not secret. In fact, the Role ID can be stored in a configuration file or an environment variable without causing a security panic. The Role ID simply tells Vault, "I am claiming to be the payment-processing application." It identifies which role the machine is trying to assume.
The second part is the Secret ID. This is a one-time-use or renewable shared secret. It is the actual sensitive piece. The Secret ID can be delivered to the machine through a trusted mechanism—perhaps manually by an administrator, or generated automatically by another piece of infrastructure. It is the electronic equivalent of a keycode that expires after one use.
When the machine wants to authenticate, it sends both the Role ID and the Secret ID to Vault's AppRole authentication endpoint. Vault checks that the Role ID exists, that the Secret ID is valid and not expired, and that any other constraints (like IP address restrictions) are satisfied. If everything matches, Vault issues a temporary token. This token has a time-to-live (TTL) set by the role's configuration—often minutes or hours, not years. The machine then uses this token to read secrets, dynamic credentials, or encryption keys from Vault.
Why does this exist? Historically, administrators hardcoded passwords or API keys inside application code or configuration files. If an attacker breached the server, they found a permanent credential that gave them unlimited access. AppRole replaces that dangerous pattern with a system where:
The credential is split into a non-secret identifier (Role ID) and a rotating secret (Secret ID).
The machine never stores a password that lives forever.
The administrator can revoke or rotate the Secret ID centrally without touching every machine.
The token issued is short-lived, so even if stolen, it is only useful for a limited time.
Inside Vault, a role configuration defines the parameters. You might set:
token_ttl: how long the issued token is valid (e.g., 1 hour).
token_max_ttl: the absolute maximum lifetime of the token.
secret_id_num_uses: how many times a particular Secret ID can be used to authenticate.
secret_id_ttl: how long the Secret ID itself remains valid before it expires and cannot be used at all.
bind_secret_id: a boolean that, if set to false, means the machine only needs the Role ID—this is a privileged, high-risk setting.
token_policies: which policies (access rules) the resulting token should have.
There are two main ways to deliver the Secret ID to a machine:
Pull method: The machine sends its Role ID to a trusted external service (like a configuration management tool or a secure endpoint) and receives the Secret ID in response. The machine then uses both to authenticate to Vault.
Push method: An administrator or an automation tool generates the Secret ID in Vault and then securely places it on the machine before the application starts. The machine already has it at boot time.
AppRole is designed for non-human identities. Humans typically use Username & Password, LDAP, or OIDC. Machines use AppRole, Kubernetes auth, AWS IAM auth, or similar. The VA-003 exam focuses heavily on distinguishing AppRole from other auth methods.
One critical behaviour: if the Secret ID is used once and has secret_id_num_uses=1, the machine must call Vault's API to fetch a new Secret ID before the old one expires. This is called "wrapping" or "response wrapping," and it is a common exam topic.
The architecture is simple: a client (machine) sends Role ID + Secret ID to Vault -> Vault validates -> Vault returns a token with a policy attached -> machine uses token to read secrets.
The key benefit is auditability. Every authentication attempt is logged. An administrator can see exactly which Role ID authenticated, from what IP address, and when. If a role is compromised, they can disable the role, and all associated Secret IDs become invalid immediately.
Enable the AppRole auth method
Run 'vault auth enable approle' on the Vault server. This activates the AppRole backend at the path 'auth/approle/' so that Vault can accept login requests using Role IDs and Secret IDs.
Create an AppRole role with policies and constraints
Define a role using 'vault write auth/approle/role/my-role token_policies=my-policy token_ttl=1h secret_id_ttl=24h secret_id_num_uses=1'. This sets the parameters for the machine's identity, including which policies to attach and how long credentials remain valid.
Read the Role ID for the role
Use 'vault read auth/approle/role/my-role/role-id' to get the non-secret identifier. This UUID is the machine's public identity and can be safely stored in a configuration file or environment variable.
Generate a Secret ID for the role
Run 'vault write -f auth/approle/role/my-role/secret-id' to create a Secret ID. The '-f' flag forces generation of a random value. This Secret ID is sensitive and should be delivered securely to the target machine, not written to logs or shared in plaintext.
Deliver the Role ID and Secret ID to the client machine
Use a secure delivery mechanism—such as response wrapping, a trusted metadata service, or a configuration management tool—to place both IDs on the client. The machine must have both values ready before it attempts to authenticate.
Authenticate from the client machine
The client makes an HTTP POST to the Vault server at '/v1/auth/approle/login' with a JSON payload containing 'role_id' and 'secret_id'. Vault validates the credentials and, if successful, returns a token with the specified TTL and attached policies.
Use the token to access secrets
The client uses the returned token as the 'X-Vault-Token' header in subsequent requests to read secrets, dynamic credentials, or perform other authorised operations. When the token expires, the client repeats the login step to get a fresh token.
A mid-sized e-commerce company, ShopFast, runs a payment processing service on a fleet of 20 virtual machines. Each VM must fetch a database password from Vault every time it starts a new transaction. The old way: a script stored a hardcoded PostgreSQL password in a config file on every VM. Two months ago, a developer accidentally committed that config file to a public GitHub repository. The database was exposed for 72 hours before someone noticed.
The engineering team decides to adopt AppRole. Here is exactly what the IT professional does step by step:
She logs into the Vault UI or CLI and creates an AppRole role called "payment-processor". She sets token_ttl to 15 minutes, secret_id_num_uses to 1, and secret_id_ttl to 24 hours. She attaches a policy that only allows reading the path database/creds/payment-db.
She generates a Role ID for the role. This is a UUID string like a1b2c3d4-e5f6-7890-abcd-ef1234567890. She writes this into a configuration file on a secure internal artifact repository that only the DevOps pipeline can read.
She uses a CI/CD pipeline to generate a Secret ID for the payment-processor role each time a new VM is provisioned. The pipeline pushes that Secret ID to the VM's instance metadata service (a protected endpoint inside the cloud provider). The VM never sees the Secret ID in a log file.
On the VM, a small Go daemon starts at boot. The daemon reads the Role ID from its config and retrieves the Secret ID from the metadata service. It then makes an HTTP POST to the Vault server at the path /v1/auth/approle/login with a JSON body containing both IDs.
Vault returns a token. The daemon uses that token to request a database credential. It gets back a username and password valid for 15 minutes. The application uses these to connect to PostgreSQL, runs the transaction, and disconnects.
After 14 minutes, the daemon repeats the AppRole login process to get a new token, then fetches fresh database credentials. This happens continuously.
One day, a security scan reveals that a VM was misconfigured and exposed an HTTP endpoint publicly. The IT administrator immediately runs: vault write auth/approle/role/payment-processor/secret-id-accessor/destroy. This invalidates all Secret IDs for that role. Even if the attacker has the Role ID and an old Secret ID, they cannot authenticate.
What did the admin accomplish? She eliminated the permanent credential. Now, the database password changes every 15 minutes, and the AppRole Secret ID rotates automatically. The blast radius of a breach is limited to minutes. She can audit every single authentication attempt.
Common tools used in this workflow:
HashiCorp Vault CLI and API.
Terraform to define AppRole roles as code.
Kubernetes with Vault Agent Injector to handle Secret ID delivery.
AWS Secrets Manager or Azure Key Vault as a temporary store for the Secret ID during provisioning.
The VA-003 exam tests AppRole authentication heavily, typically with 4-6 questions that mix definitional recall, command syntax, and scenario-based troubleshooting. Here is exactly what you need to know.
Exam topics that appear most often:
Understanding that AppRole is for machine authentication, not human authentication.
Knowing the two components: Role ID (identifier, not secret) and Secret ID (secret, must be protected).
Recognising that you create an AppRole role with the path auth/approle/role/<role-name>.
Knowing the command to generate a Secret ID: vault write -f auth/approle/role/<role-name>/secret-id.
Understanding that -f flag means "force" — it tells Vault to generate a value without needing to supply one.
Knowing the login path: vault write auth/approle/login role_id=<id> secret_id=<id>.
Recognising that a machine logs in by providing both IDs.
Understanding TTLs and max TTLs on tokens and Secret IDs.
Knowing the concept of "response wrapping" — a Secret ID can be wrapped in a single-use token for secure delivery.
Traps the exam sets:
Trap 1: They ask whether the Role ID is secret. Many beginners say yes. The correct answer is no—the Role ID is an identifier, not a secret. It only becomes useful when paired with a Secret ID.
Trap 2: They describe a human using AppRole and ask if that is appropriate. The answer is no. Humans should use username/password, LDAP, or OIDC. AppRole is for non-human workloads.
Trap 3: They ask what happens when a Secret ID expires. The machine must get a new one. It cannot reuse an expired Secret ID, and Vault will reject the login.
Trap 4: They ask about bind_secret_id=false. This removes the need for a Secret ID entirely. The exam will test whether you understand this is a dangerous configuration because any machine that knows the Role ID can authenticate.
Trap 5: They present a scenario where a Secret ID has been used the maximum number of times and ask what the machine should do. The answer: the machine needs to request a new Secret ID from Vault or from an external authority.
Key definitions to memorise exactly:
Role ID: A UUID that identifies the role. Not secret.
Secret ID: A credential that the client provides to log in. Must be kept secret. Has a TTL and usage count.
Token: The temporary credential issued after successful AppRole login.
policy: A set of rules attached to the token that determines what secrets the token can access.
TTL: Time To Live — how long the token or Secret ID remains valid.
Response wrapping: A feature that wraps a secret (like a Secret ID) inside a single-use token so it can be safely delivered over untrusted networks.
CIDR binding: An optional restriction that limits which IP addresses can use a given Secret ID.
The exam expects you to be comfortable with the CLI commands. Practise these:
vault auth enable approle
vault write auth/approle/role/my-role token_ttl=1h
vault read auth/approle/role/my-role/role-id
vault write -f auth/approle/role/my-role/secret-id
vault write auth/approle/login role_id=... secret_id=...
One recurring question style: "A security team wants to ensure that even if the Secret ID is leaked, an attacker cannot authenticate from outside the corporate network." The answer: configure secret_id_bound_cidrs on the role definition.
Another style: "What is the primary advantage of AppRole over static API keys?" Answer: AppRole credentials are temporary, renewable, and centrally revocable, while static keys are permanent and difficult to rotate.
AppRole authentication is designed exclusively for non-human machine identities, not for human users.
Role ID is a non-secret identifier for the role; Secret ID is the sensitive, rotating credential that must be protected.
The Secret ID can be configured with a TTL and a limited number of uses, making it a temporary credential rather than a permanent key.
Response wrapping allows a Secret ID to be securely delivered inside a single-use token, preventing interception during transit.
You revoke a role's access by deleting or disabling the role, which invalidates all associated Secret IDs instantly.
The CLI command to log in with AppRole is 'vault write auth/approle/login role_id=<value> secret_id=<value>'.
Setting 'bind_secret_id=false' on a role removes the need for a Secret ID, which is dangerous because only the Role ID is required.
AppRole replaces the insecure pattern of hardcoded API keys and passwords in application configuration files.
Each AppRole login attempt is logged in Vault's audit log, providing full traceability of machine authentication.
The secret_id_num_uses parameter controls how many times a single Secret ID can be used to authenticate before it expires.
These come up on the exam all the time. Here's how to tell them apart.
AppRole
Designed for non-human machine identities only
Uses a two-part credential: Role ID (non-secret) and Secret ID (secret)
Supports automatic Secret ID rotation and usage limits
Username & Password Auth
Designed for human users
Uses a single username and password pair (both are secrets)
Requires manual password changes or external password rotation tool
AppRole
Does not depend on any external orchestrator or platform
Requires explicit management of Role IDs and Secret IDs
Works with any compute platform (VM, bare metal, container)
Kubernetes Auth
Only works within a Kubernetes cluster
Uses the pod's service account token automatically
Requires Kubernetes-specific configuration and permissions
AppRole
Provider-agnostic; works with any cloud or on-premises
Uses Vault-generated credentials (Role ID + Secret ID)
Can be used for static and dynamic machine identities
AWS IAM Auth
Only works with AWS workloads
Uses AWS IAM roles and instance metadata service
Tightly coupled to AWS environment and account structure
Secret ID
Temporary by default — configured with TTL and usage count
Centrally revocable by deleting or disabling the role
Can be delivered securely via response wrapping
API Key
Typically permanent until manually rotated
Revocation requires keeping a blocklist or deleting the key
Often stored in plaintext in configuration files or source code
Mistake
AppRole is the same as a username and password for machines.
Correct
AppRole uses a Role ID (a non-secret identifier) and a Secret ID (a rotating, time-limited secret). It is not a static pair like a username and password. The Secret ID can expire after one use or after a set time.
The naming 'Role ID' and 'Secret ID' sounds similar to 'username' and 'password', so beginners map the mental model directly. But the behaviour is fundamentally different: a password never changes unless manually reset, while a Secret ID can be auto-rotated and bound to usage limits.
Mistake
The Role ID must be kept as secret as the Secret ID.
Correct
The Role ID is not a secret. It is an identifier. Knowing only the Role ID is useless without the Secret ID. It can be stored in logs, config maps, or even printed on documentation without immediate risk.
People naturally assume that any 'ID' used for authentication must be sensitive. In most auth systems, both parts are secret. AppRole's design deliberately separates identity from credential, which feels unintuitive.
Mistake
AppRole can be used to authenticate individual human users.
Correct
AppRole is designed exclusively for machine-to-machine authentication. Humans should use methods that support multi-factor authentication, password policies, and session management, such as LDAP, OIDC, or Username & Password.
The name 'AppRole' contains 'App', which some interpret as 'application user' meaning any user including humans. But the 'App' stands for 'application' as in software, not 'application' as in sign-up form.
Mistake
Once a Secret ID is generated, it can be used indefinitely until revoked.
Correct
A Secret ID has a configurable TTL and a maximum number of uses (secret_id_num_uses). It will expire or become invalid after the specified count is reached. It is not a permanent credential.
People are used to API keys and passwords that remain valid until someone manually deletes them. The concept of 'time-bound' or 'usage-bound' credentials is unfamiliar to many newcomers.
Mistake
AppRole requires a human to manually create and distribute Secret IDs each time.
Correct
Secret IDs can be generated programmatically through the Vault API and distributed via automation tools like Terraform, Kubernetes controllers, or custom scripts. The process is fully automated in production.
Many beginners only see the manual 'vault write' command in tutorials and assume that is how it works in real life. They do not realise that in production, Secret ID generation and rotation are handled by infrastructure-as-code pipelines.
Mistake
If a Secret ID is set to have a TTL of 24 hours, you must wait 24 hours before you can generate a new one.
Correct
You can generate a new Secret ID at any time. The TTL only controls how long that specific Secret ID version is valid. You can have multiple valid Secret IDs for the same role simultaneously, each with its own TTL and usage count.
Newcomers confuse TTL with a cooldown period. They think the existence of one Secret ID blocks the creation of another. In reality, TTL is a property of the credential instance, not a lock on the role.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
AppRole is for machine identities (servers, scripts, applications) and uses a Role ID (non-secret) and Secret ID (secret). Username/password is for human users and requires a single username and password pair. AppRole supports features like usage limits and automatic rotation that username/password does not.
Yes, if you set 'secret_id_num_uses' to a value greater than 1, or to 0 for unlimited uses. By default, each Secret ID can be used an unlimited number of times within its TTL. However, many security teams set it to 1 to force rotation after each use.
The client will receive an authentication error when it tries to log in with an expired Secret ID. The client must obtain a new Secret ID—either by generating a new one in Vault or by requesting one from an automated delivery system—before it can authenticate again.
You can delete the role entirely with 'vault delete auth/approle/role/my-role', or you can disable the AppRole auth method with 'vault auth disable approle'. Deleting the role invalidates all existing Secret IDs and tokens derived from that role.
No, the Role ID is not confidential. It is a public identifier that tells Vault which role the client claims to be. Only the Secret ID must be kept secret. Storing the Role ID in a public configuration file is acceptable from a security standpoint.
Yes, AppRole works within Vault namespaces. You must enable the AppRole auth method inside the target namespace and create the role in that namespace. The login path then includes the namespace in the URL or header.
Use 'vault write -f auth/approle/role/my-role/secret-id'. The '-f' flag tells Vault to generate a value and return the Secret ID and its accessor in the response, without requiring any input from the user.
You've finished AppRole Authentication. Continue through the VA-003 study guide to build a complete picture of the exam.
Done with this chapter?