Vault Agent Integration#
HashiCorp Vault Agent is a lightweight, client-side daemon designed to simplify interactions with HashiCorp Vault, automating critical tasks like authentication, token renewal, caching, and dynamic secret rendering using templates that don't require changes to your application logic.
What Is HashiCorp Vault Agent?#
Vault Agent acts as a local helper that abstracts much of the complexity involved in securely fetching and renewing secrets from Vault. Instead of requiring every application to implement complex authentication or secret retrieval logic, Vault Agent takes care of these repetitive tasks for you, allowing your applications to focus on business logic while maintaining a high standard of security.
Key Features of Vault Agent#
Note
Agent can cache tokens and leases, but DOES NOT CACHE STATIC SECRETS. This feature is only available with the Vault Proxy
- Automated Authentication (Auto-Auth)
- Supports multiple authentication methods such as AppRole, Kubernetes, and AWS. This auto-auth feature automatically handles the process of authenticating to Vault, eliminating manual steps.
- Token and Lease Management and Renewal
- Once authenticated, Vault Agent continuously monitors token and lease expiration. It automatically renews tokens and leases as needed, ensuring applications maintain uninterrupted access to secrets.
- Caching
- Allows client-side caching of responses containing newly created tokens and responses containing leased secrets generated off of these newly created tokens.
- Templating
- Allows rendering of user-supplied templates into configuration files by Vault Agent, using the token generated by the Auto-Auth step.
- Windows Service
- Allows running the Vault Agent as a Windows service.
- Process Supervisor Mode
- Runs a child process with Vault secrets injected as environment variables.
Please view the Vault Agent Documentation for more information on features.
Potential Use Cases#
Note
Vault Agent can integrate with AWS applications, kubernetes workloads, and much more. Please view the tutorials for these integrations at the HashiCorp Vendor Website
1. Secrets Injection in Containerized Environments#
In modern deployments like Kubernetes or Docker, managing secrets can be challenging. Running Vault Agent as a sidecar enables seamless injection of secrets into your application containers. The agent automatically fetches and renews secrets, ensuring that containers always have the latest credentials without exposing them directly in code or configuration files.
2. Enhanced Application Resilience#
By providing local caching and automated token renewal, Vault Agent improves overall application resilience. Applications can continue to operate with cached secrets even if connectivity to the central Vault server is temporarily lost.
QuickStart with Vault Agent#
Note
If you are having issues with the Vault Agent, please make sure the $VAULT_NAMESPACE environmental variable has been correctly set
Pre-requisites#
- Ensure you have installed the Vault Enterprise Binary
Setup#
-
Export an environmental variable for the Vault CLI to access the Vault server.
Bashexport VAULT_ADDR=<VAULT_ADDRESS>
-
Export an environmental variable for the Vault CESI Namespace.
Bashexport VAULT_NAMESPACE=admin/<CESI_NAMESPACE>
-
Login to Vault. Make sure to set the
-namespace
flag to adminBashvault login -method=saml -namespace=admin Success! You are now authenticated. The token information displayed below is already stored in the token helper. You do NOT need to run "vault login" again. Future Vault requests will automatically use this token. Key Value --- ----- token hvs.token token_accessor accessor token_duration 1h token_renewable true token_policies ["default"] identity_policies ["default"] policies ["default"] token_meta_role saml_role
Create a Working Directory#
- Create a directory to store configuration and template files.
mkdir $HOME/vault-test && cd $HOME/vault-test
Create data#
-
Create a data file
Bashtee data.json -<<EOF { "organization": "ACME Inc.", "customer_id": "ABXX2398YZPIE7391", "region": "US-West", "zip_code": "94105", "type": "premium", "contact_email": "james@acme.com", "status": "active" } EOF
-
Create the data in a KV v2 Secrets Engine
Bashvault kv put secret/customers/acme @data.json
Create an AppRole#
Auto-auth authenticates with Vault to get a client token, store, and manage the token lifecycle. Vault Agent can heal from an invalid token error caused by unexpected incidence (for example, Vault admin revoked the client token used by the Vault Agent). We will be using an AppRole to configure the token and to enable this self-healing capability.
For easier implementation, AppRoles can also be configured with terraform from our examples repo.
Note
If installing multiple agents, please try to reduce the number of roles needed for the agent to preserve client count. Vault considers an AppRole to be only 1 client as long as the same Role ID is used.
Please contact the DevEx team for additional questions.
-
Create a policy for the approle auth method
Bashvault policy write agent -<<EOL path "secret/*" { capabilities = ["read", "list"] } path "sys/leases/*" { capabilities = ["create", "update"] } path "auth/token/*" { capabilities = ["create", "update"] } EOL
-
Create a new role within your approle with the associated policy above
Bashvault write auth/approle/role/agent policies=agent token_num_uses=5 secret_id_ttl="3600s"
Understanding
token_num_uses
Parameter:The
token_num_uses=5
parameter limits how many times a token can be used or renewed to make API requests before it becomes invalid. This setting is beneficial forr:-
Security: Prevents unlimited token reuse and renewals, and reduces attack surface
-
Compliance: Ensures tokens have controlled usage patterns
-
Development/Testing: Allows predictable token lifecycle management
When to use token_num_uses:
-
Production environments: Set to a reasonable limit (5-10) to balance security and functionality
-
High-security environments: Use lower values (1-3) for stricter control
-
Development/testing: May use higher values or remove entirely for convenience
-
Child token creation: Set to 0 if the token needs to create child tokens
Important: If omitted, tokens have unlimited uses until they expire based on TTL. Setting this to 0 allows unlimited uses and is required when tokens need to create child tokens.
-
-
Retrieve your role ID and secret ID and store it locally
Bashvault read -field=role_id auth/approle/role/agent/role-id > $HOME/vault-test/roleID.txt vault write -f -field=secret_id auth/approle/role/agent/secret-id > $HOME/vault-test/secretID.txt
Start a Vault Agent#
You will be reading the secrets created above with the Vault Agent while using an AppRole for auto authentication
- Create a Vault Agent configuration file
tee agent-config.hcl -<<EOF
pid_file = "./pidfile"
vault {
address = "$VAULT_ADDR"
tls_skip_verify = true
}
#Automatically authenticate using the token in the path
auto_auth {
method {
type = "approle"
config = {
role_id_file_path = "$HOME/vault-test/roleID.txt"
secret_id_file_path = "$HOME/vault-test/secretID.txt"
}
}
sink "file" {
config = {
path = "$HOME/vault-token-via-agent"
}
}
}
# Cache tokens and secret leases
cache { }
EOF
vault agent -config=agent-config.hcl
Example output:
==> Vault Agent started! Log data will stream in below:
==> Vault Agent configuration:
Cgo: disabled
Log Level:
Version: Vault v1.13.0, built 2023-02-14T14:25:23Z
Version Sha: c2d6b060c0eec60393e866b761a5990716cb45de
[INFO] vault-agent.sink.file: creating file sink
[INFO] vault-agent.sink.file: file sink configured: path=$HOME/vault-token-via-agent mode=-rw-r-----
[INFO] vault-agent.template.server: starting template server
[INFO] vault-agent.template.server: no templates found
[INFO] vault-agent.auth.handler: starting auth handler
[INFO] vault-agent.auth.handler: authenticating
[INFO] vault-agent.sink.server: starting sink server
[INFO] vault-agent.auth.handler: authentication successful, sending token to sinks
...snip...
Self-Healing Tokens#
As we configured the AppRole above, it should now automatically refresh its token in an event that the TTL expires or the token is revoked. This can be viewed in the logs
...snip...
[INFO] proxy.apiproxy: proxy received an invalid token error
[INFO] proxy.auth.handler: invalid token found, re-authenticating
[INFO] proxy.auth.handler: authenticating
[INFO] proxy.auth.handler: authentication successful, sending token to sinks
[INFO] proxy.auth.handler: starting renewal process
[INFO] proxy.sink.file: token written: path=/user/vault-token-via-agent
[INFO] proxy.auth.handler: renewed auth token
Token Persistence and Agent Restart#
When Vault Agent restarts, it can utilize existing tokens from the sink file to maintain continuity without immediate re-authentication.
Example: Leveraging Persisted Tokens After Restart
1.Verify token persistence from previous run:
# Check if token file exists from previous agent session
if [ -f "$HOME/vault-token-via-agent" ]; then
echo "Token file found - agent can use existing token on restart"
# Verify token is still valid
VAULT_TOKEN=$(cat $HOME/vault-token-via-agent) vault auth -method=token
else
echo "No existing token - agent will perform fresh authentication"
fi
tee agent-restart-config.hcl -<<EOF
pid_file = "./pidfile"
vault {
address = "$VAULT_ADDR"
tls_skip_verify = true
}
auto_auth {
method {
type = "approle"
config = {
role_id_file_path = "$HOME/vault-test/roleID.txt"
secret_id_file_path = "$HOME/vault-test/secretID.txt"
}
}
sink "file" {
config = {
path = "$HOME/vault-token-via-agent"
}
}
}
cache { }
EOF
vault agent -config=agent-restart-config.hcl
- Faster startup: Agent can use existing valid tokens before expiration
- Reduced authentication load: Fewer authentication requests to Vault
- Seamless transitions: Applications continue working during agent restarts
Note
Agent will automatically re-authenticate when the persisted token expires or becomes invalid, ensuring continuous operation.
Vault Agent Templates#
In this scenario, the Vault Agent can use templates to quicky ingest secrets from Vault.
- Press Ctrl + C to stop running the Vault Agent
- If you are unsure if the Vault Agent process is still running, please run this command:
pgrep -f vault | xargs kill
-
Create a
customer.json.tmpl
file. This will be the template file Vault Agent will run against to ingest secretsBashtee customer.json.tmpl -<<EOF { {{ with secret "secret/data/customers/acme" }} "Organization": "{{ .Data.data.organization }}", "ID": "{{ .Data.data.customer_id }}", "Contact": "{{ .Data.data.contact_email }}" {{ end }} } EOF
-
Create a Vault Agent configuration file, but with a
template
stanza added.Bashtee agent-template.hcl -<<EOF template { source = "$HOME/vault-test/customer.json.tmpl" destination = "$HOME/vault-test/customer.json" } EOF
-
Start Vault Agent again with the additional configuration applied
Bashvault agent -config=agent-config.hcl \ -config=agent-template.hcl
Example output:
==> Vault Agent started! Log data will stream in below:
==> Vault Agent configuration:
Api Address 1: http://bufconn
Cgo: disabled
Log Level:
Version: Vault v1.13.0-rc1+ent, built 2023-02-14T14:25:23Z
Version Sha: c2d6b060c0eec60393e866b761a5990716cb45de
[INFO] vault-agent.sink.file: creating file sink
[INFO] vault-agent.sink.file: file sink configured: path=$HOME/vault-token-via-agent mode=-rw-r-----
[INFO] vault-agent.auth.handler: starting auth handler
[INFO] vault-agent.auth.handler: authenticating
[INFO] vault-agent.template.server: starting template server
...snip...
[INFO] (runner) starting
[INFO] (runner) rendered "$HOME/vault-test/customer.json.tmpl" => "$HOME/vault-test/customer.json"
- Open a new terminal or text editor and verify that the customer.json file has the secrets retrieved from Vault.
Bash
cat customer.json
Example output:
{
"Organization": "ACME Inc.",
"ID": "ABXX2398YZPIE7391",
"Contact": "james@acme.com"
}
This data should match the values stored in secret/customers/acme
vault kv get secret/customers/acme
======= Secret Path =======
secret/data/customers/acme
======= Metadata =======
Key Value
--- -----
created_time 2025-02-23T16:25:46.030960819Z
custom_metadata <nil>
deletion_time n/a
destroyed false
version 1
======== Data ========
Key Value
--- -----
contact_email james@acme.com
customer_id ABXX2398YZPIE7391
organization ACME Inc.
...snip...
Process Supervisor Mode with Environment Variables#
Vault Agent can launch child processes with secrets injected as environment variables using env_template
and exec
blocks.
Note
Process Supervisor Mode is incompatible with regular file template entries. When using env_template
, you cannot use standard template
stanzas in the same configuration.
Example: Launching a Process with Injected Secrets#
1.Create a sample application script:
tee sample-app.sh -<<EOF
#!/bin/bash
echo "Application started with injected secrets:"
echo "Organization: \$ACME_ORG"
echo "Customer ID: \$ACME_CUSTOMER_ID"
echo "Contact Email: \$ACME_CONTACT_EMAIL"
echo "Region: \$ACME_REGION"
# Simulate application work
while true; do
echo "Application running... (secrets available as env vars)"
sleep 30
done
EOF
chmod +x sample-app.sh
tee agent-exec-config.hcl -<<EOF
pid_file = "./pidfile"
vault {
address = "$VAULT_ADDR"
tls_skip_verify = true
}
auto_auth {
method {
type = "approle"
config = {
role_id_file_path = "$HOME/vault-test/roleID.txt"
secret_id_file_path = "$HOME/vault-test/secretID.txt"
}
}
sink "file" {
config = {
path = "$HOME/vault-token-via-agent"
}
}
}
cache { }
env_template "ACME_ORG" {
contents = "{{ with secret \"secret/data/customers/acme\" }}{{ .Data.data.organization }}{{ end }}"
}
env_template "ACME_CUSTOMER_ID" {
contents = "{{ with secret \"secret/data/customers/acme\" }}{{ .Data.data.customer_id }}{{ end }}"
}
env_template "ACME_CONTACT_EMAIL" {
contents = "{{ with secret \"secret/data/customers/acme\" }}{{ .Data.data.contact_email }}{{ end }}"
}
env_template "ACME_REGION" {
contents = "{{ with secret \"secret/data/customers/acme\" }}{{ .Data.data.region }}{{ end }}"
}
exec {
command = ["$HOME/vault-test/sample-app.sh"]
restart_on_secret_changes = "always"
restart_stop_signal = "SIGINT"
}
EOF
vault agent -config=agent-exec-config.hcl
Key Features of Process Supervisor Mode:#
- Automatic Secret Injection: Secrets are automatically injected as environment variables
- Process Management: Vault Agent manages the child process lifecycle
- Auto-restart: Process automatically restarts when secrets change
- Signal Handling: Configurable stop signals for graceful shutdown
- Named Variables: Each
env_template
block name becomes the environment variable name
Example Output:
Application started with injected secrets:
Organization: ACME Inc.
Customer ID: ABXX2398YZPIE7391
Contact Email: james@acme.com
Region: US-West
Application running... (secrets available as env vars)
This approach eliminates the need for applications to directly interact with Vault APIs, as secrets are provided through standard environment variables.
References#
Vault Proxy and Agent Quick Start Guide