HashiCorp Vault Operations Professional exam practice guide — Part 4

Vault agent & auto-auth

4 min readFeb 14, 2024

Vault agent

A Vault agent allows human-less authentication to Vault. Combining the various available auth methods and Vault agent’s auto-auth capabilities, you can allow your systems to authenticate securely, pull required secrets and output that secret as a standalone or templated out into a larger configuration file for consumption. Vault agents provide a more scalable and simpler path to adoption for Vault and you will likely see a question on the exam relating to this topic.

Vault server setup

Using our Vault server we provisioned, in part 2, let’s setup some prerequisites for this part:

Enable KV2 secrets engine and inject a secret:

vault secrets enable -path=mykv2 -version=2 kv

vault kv put mykv2/passwords/admin password='bibbidibobbidiboo'

Create Vault policy, kv2access as defined below:

Enable AppRole auth method and configure an agent role with kv2access as its token policy:

vault auth enable approle

vault write auth/approle/role/agent-role token_policies=kv2access

Get role_id (username) and generate a secret_id (password) for agent-role (you will need this in the Vault agent setup steps):

vault read -field=role_id auth/approle/role/agent-role/role-id

vault write -force -field=secret_id auth/approle/role/agent-role/secret-id

POP QUIZ: what happens when you try to use the Vault CLI to authenticate with AppRole credentials? (answer below)

Vault agent setup

Spin up a new VM (I recommend 2 vCPU/4 GB mem or better as we will be using this server in the later parts of this guide as well).

You will need to create some files to house the role_id and secret_id you generated earlier. You should also secure their ownership and permissions as well. The Vault agent will use these credentials to authenticate to Vault and write the resulting token in a sink. See the agent config below:

NOTE: you will need to update the systemd Vault service file (/etc/systemd/system/vault.service) run in agent mode instead of server mode and don’t forget to run systemctl daemon-reload afterwards!

Secrets template

Vault agent templates are written in Consul Template markup language and is quite easy to pick up especially if you have had some experience with Jinja2 or Go templating languages. Here is the template that was used in the Vault agent config above to access the KV2 secret:

POP QUIZ ANSWER: Vault will give you an error telling you it does not know of an approle method (which is not a really helpful error message IMHO), but does give you a hint that some auth methods are only available via the HTTP API. Because AppRole is meant for machines / apps, you can only login via the HTTP API:

curl --request POST \
  --data '{"role_id":"635f0dd3-60a2-649b-b9b6-629099dbef43","secret_id":"fdd76b10-04ff-6838-22ab-8956bb14215f"}' \
  http://10.128.0.44:8200/v1/auth/approle/login

CHALLENGE #1: enable Vault API-proxy on the agent

CHALLENGE #2: configure auth method to restrict authentication and token usage to only the Vault agent. Use a KV version 1 secrets engine for your secret and template out the secret into a new output file

CHALLENGE #3: configure auto-auth using a cloud provider auth method

>> SPOILER ALERT!!! SOLUTION GUIDE BELOW!!! <<

Challenge solutions guide

SOLUTION #1

This can be achieved by added the following two stanzas to your Vault agent config:

api_proxy {
  use_auto_auth_token = "force"
  enforce_consistency = "always"
}

listener "tcp" {
  address = "127.0.0.1:8100"
  tls_disable = true
}

This allows you to use the local listener as API proxy to the actual Vault server. Further setting use_auto_auth_token to force means accessing Vault through the API proxy will only use the token configured with auto-auth (and override any other Vault tokens, if set). For example, the following command will work:

VAULT_ADDR='http://127.0.0.1:8100' VAULT_TOKEN='notevenreal' vault kv get mykv2/passwords/admin

SOLUTION #2

On Vault server:

Enable KV secrets engine (if you do not specify -version=2, the default will be v1). While you’re at it, create a secret:

vault secrets enable -path mykv kv

vault kv put mykv/secret passcode='shazam!'

Update the existing policy or create a new policy to allow reading of your KV secret (I created a new policy called kvaccess)
Update role config to include new policy and specified IP of Vault agent as bound CIDRs as additional authentication constraints:

vault write auth/approle/role/agent-role \
  token_policies=kv2access,kvaccess \
  secret_id_bound_cidrs="10.128.0.48/32" \
  token_bound_cidrs="10.128.0.48/32"

On Vault agent:

Create new secret template:

ATTENTION!!: because this is a KV v1 secrets store, the path has one less .data in its path

Add additional template stanza to Vault agent config and template a new file with the secret. Below is my updated agent config:

SOLUTION #3

I have written about this in the past, and you can find a solution involving the GCP auth method here.