Vault Agent - secrets as environment variables
Consul Template and Envconsul tools have been widely used by the Vault practitioners to help integrate Vault in their existing solutions. Vault 1.3.0 introduced the Vault Agent Template feature which provides the workflow that Consul Template provides.
Vault 1.14 introduced the process supervisor mode to retrieve secrets from Vault as environment variables using Consul Template markup.
Prerequisites
To complete this tutorial, you will need:
- Vault binary version 1.14.0 or later
Lab setup
Open a terminal and start a Vault dev server with
root
as the root token.The Vault dev server defaults to running at
127.0.0.1:8200
. The server is also initialized and unsealed.Insecure operation: Do not run a Vault dev server in production. This approach is only used here to simplify the unsealing process for this demonstration.
Export an environment variable for the
vault
CLI to address the Vault server.Log into Vault.
Tip
Vault server is ready and the token value (
root
) is stored in the$HOME/.vault-token
file.
Setup test secrets
In your terminal, clone the learn-vault-agent-envconsul repository which contains the example configuration used in this tutorial.
You can explore this repository by changing directories.
The folder includes the following files:
Run the
setup-secrets.sh
script. This script enables kv-v2 secrets engine atweb-team/
anddev-app/
paths and creates initial test data. Also, it configures PKI secrets engine to generate certificate which you will leverage in later section.Read the secrets created at
web-team/data/api-keys
.Read the secrets created at
dev-app/data/creds
.Read the secrets created at
dev-app/data/creds/database/db-admin
.
Generate a Vault Agent config file
Vault Agent introduced the generate-config subcommand to auto generate the agent configuration file based on the user input.
Usage:
Option | Description |
---|---|
-type | Currently, env-template is the only supported type of agent configuration |
-exec | Pass the command to execute in agent process. The default is env |
-path | Path to a kv-v1 or kv-v2 secret. Multiple paths and tail '*' wildcards are allowed. |
Run the generate-config subcommand
Generates a Vault Agent configuration file named agent-config.hcl
at the
current working directory. If your application needs to pull secrets from
multiple paths, you can provide multiple -path
options as well as the
wildcards (*
).
Generate a Vault Agent configuration file named
agent-config.hcl
. Pass thekv-demo.sh
as the command to execute.Output:
In the absence of the output file name, the command will generate a configuration file named
agent.hcl
.Open the generated configuration file with your preferred text editor to examine.
agent-config.hclThe
auto_auth
stanza is usingtoken_file
as a placeholder. You can change the stanza to use desired auth method. See the following tutorials for other auto auth examples:- Vault Agent with AWS demonstrates AWS auth method
- Vault Agent with Kubernetes demonstrates Kubernetes auth method
Process supervisor mode
Each generated env_template
block maps to a secret key of a KV path that you
passed in the command.
The exec
block sets the kv-demo.sh
script as the commands that Vault Agent
to execute.
Open and examine the kv-demo.sh
file. It reads secrets as environment
variables.
This application does not need to know about Vault.
Start a Vault Agent
Start a Vault Agent instance that connects to the Vault server running at
VAULT_ADDR
.
Start a Vault Agent.
Example output:
Restarts on secrets change
The secret values could change while your application is running. Examine the behavior when the secret values change.
Add
sleep 100
in thekv-demo.sh
to mock a long running application.kv-demo.shEdit the
agent-config.sh
file to set thestatic_secret_render_interval
to 10 seconds for the purpose of demonstration. This makes Vault Agent to pull the secrets every 10 seconds.agent-config.hclStart the Vault Agent again.
Open another terminal, and connect to the target Vault server.
Tip
Refer back to the Lab setup section.
Set the
VAULT_ADDR
environment variable.Authenticate with Vault.
Update the secret values at
web-team/data/api-keys
.Return to the terminal where Vault Agent is running and watch the output.
Press Ctrl + C to stop the running Vault Agent.
Work with dynamic secrets
Currently, the generate-config subcommand only supports kv-v1 and kv-v2 secrets
engines; however, the Vault Agent's process supervisor
mode supports dynamic
secrets that Envconsul supports today. The difference is that you would have to
manually define the env_template
blocks.
The
setup-secrets.sh
script configured the PKI secrets engine and it is ready to serve.Example output:
(Optional) Request a certificate.
Example output:
Open the
pki-agent-config.hcl
to examine theenv_template
block it defines.pki-agent-config.hclOpen the
pki-demo.sh
file to review.This mock application gets certificate stored in the CERT environment variable. Similar to the
kv-demo.sh
, this application does not need to know anything about Vault.Run a Vault Agent with additional
env_template
definition.Example output:
Similar to what you observed in the restarts on secrets change section, if the certificate expires and the application is still running, Vault Agent can fetch a new certificate.
Clean up
Press Ctrl + C to stop the running Vault Agent.
You can stop the Vault dev server by pressing Ctrl+C where the server is running. Or, execute the following command.
Unset the
VAULT_ADDR
environment variable.
Summary
You learned the use of the generate-config subcommand and the process supervisor mode to take advantage of secrets presented as environment variables.
Vault Agent can handle the authentication and secrets retrieval so that your application can remain Vault unaware. This reduces the barrier to adopting Vault and keep your applications secure.
There are several tutorials demonstrates the use of Vault Agent. See the available Vault Agent tutorials.