Difficulty: beginner
Estimated Time: 5 minutes

Logo

A modern system requires access to a multitude of secrets: database credentials, API keys for external services, credentials for service-oriented architecture communication, etc. Vault steps in to provide a centralized secret management system. The next step is to decide how your applications acquire the secrets from Vault.

This guide introduces Consul Template and Envconsul to help you determine if these tools speed up the integration of your applications once secrets are securely managed by Vault.

Consul Template

A stand-alone application that renders data from Consul and Vault onto the target file system. Despite its name, Consul Template does not require a Consul cluster to operate.

Consul Template retrieves secrets from Vault:

  • Manages the acquisition and renewal lifecycle
  • Requires a valid Vault token to operate

Envconsul

Envconsul launches a subprocess with environment variables populated from Consul and Vault. Environment variables are dynamically populated, and applications read those environment variables.

Characteristics:

  • Envconsul does not require a Consul cluster to operate
  • Envconsul enables flexibility and portability for applications across systems


NOTE: Both Consul Template and Envconsul are open source tools.

This scenario gave you a quick introduction to leverage Consul Template and Envconsul.

Resources:

Vault - Direct App Integration

Step 1 of 3

Setup Secrets Engines

First, login with root token.

Click on the command () will automatically copy it into the terminal and execute it.

vault login root

To see the difference between Key/Value secrets engine version 1 and version 2, first enable additional KV secrets engines.

vault secrets enable -path="kv-v1" -version=1 kv
vault secrets enable -path="kv-v2" -version=2 kv

Let's list enabled secrets engines to verify:

vault secrets list -detailed

In the output, locate secret/ and check its version.

Path          Type         ...    Options           Description
----          ----         ...    -------           -----------
cubbyhole/    cubbyhole    ...    map[]             per-token private secret storage
identity/     identity     ...    map[]             identity store
kv-v1/        kv           ...    map[version:1]    n/a
kv-v2/        kv           ...    map[version:2]    n/a
secret/       kv           ...    map[version:2]    key/value secret storage
sys/          system       ...    map[]             system endpoints used for control, policy and debugging

Write some secrets

Now, store some secrets at kv-v1 and kv-v2 paths. Some test data are provided in the data.json file.

{
  "organization": "ACME Inc.",
  "customer_id": "ABXX2398YZPIE7391",
  "region": "US-West",
  "zip_code": "94105",
  "type": "premium",
  "contact_email": "[email protected]",
  "status": "active"
}

Execute the following commands:

vault kv put kv-v1/customers/acme @data.json
vault kv put kv-v2/customers/acme @data.json

Let's view the secrets written in kv-v1:

clear
vault kv get kv-v1/customers/acme

Similarly, view the secrets written in kv-v2:

vault kv get kv-v2/customers/acme

Notice that KV v2 keeps track of changes that were made to the secrets; therefore, the data has its metadata associate with it.

customer-v1.tpl
customer-v2.tpl