We’ve already dealt with Hashicorp Vault, a tool for centralizing static and dynamic secrets and Encryption as a Service. In this article, we will focus on the Vault Agent, which will allow us to reduce the dependency of HashiCorp Vault at the code level. This first article is an introduction to the subject, before looking in detail at how to integrate Vault Agent in an application.

Prerequisite

Note: at the time of writing this article, Vault is in version 1.6.2.

If you don’t know Vault yet, I invite you to try the interactive tutorial on the official Hashicorp Vault website to get a first idea.

Finally, this article follows the trilogy of articles on how to make application secrets disappear with Vault and Terraform :

• Part 1
• Part 2
• Part 3

What is Vault Agent?

Vault Agent is none other than the Vault binary launched in Agent mode. It allows us to benefit from certain functionalities that facilitate our interaction with Vault, in particular :

• Auto-Auth: Supports authentication with Vault defined by a method. Once authenticated, it deposits the Vault token into a Sinks.
  • Methods: This is the configuration on the Vault Agent side that allows us to authenticate to the Vault. Note that not ALL authentication methods are not yet supported by the Vault Agent. If the Vault token expires, the Vault Agent is able to renew it.
  • Sinks: This is the configuration that tells to the Vault Agent where to write the Vault token or encrypt it if necessary. Currently, only File is supported.
• Caching: Allows caching of Vault responses (token, lease, etc). Caching is most often used for more intensive use of the Vault and will not fall within the scope of this article.
• Templating: Formerly Consul-template, templating is used to transform a source template file into a destination file containing our secrets and takes place once the Vault token has been generated by the Auto-Auth. Templating is based on Consul Template markup. Finally, it allows us to manage the dynamic renewal of our secrets by updating our destination file (always based on the template).

Vault Agent, why ?

In previous articles, we have seen how to integrate Vault into an application. However, in each of the actions taken, we have seen that integration could impact the code and create dependencies with Vault.

There are two dependencies:

• At the authentication and renewal of the Vault token :
  • First, the application must be « aware » of the authentication method (more information here: How to choose your authentication method) in order to get your token.
  • Second, the token provided by the Vault has an expiration date and the application must be able to renew it if needed.
• If the secret is dynamic, the application must be able to renew it.

To resume, based on an AWS application example, we have the following dependencies:

Vault Agent reduces your dependencies and tackles some dependencies like:. 

• Auto-Auth: Authenticate to the Vault and renew the token provided by Vault if it expires (if specified).
• Template: Retrieve secrets and renew dynamic secrets via the token generated by the Auto-Auth method. 

If we go back to the previous example, using the Vault Agent, we have:

The Vault Agent initially allows us to authenticate to the Vault using the AWS authentication method and renew the token if its lifetime expires.

In a second time, it allows us to retrieve secrets, render it into a template file and finally to renew secrets if needed.

If you are on Kubernetes, it is possible to go through the Vault Agent Sidecar Injector, which will not be discussed here.

In the next part of this article, we will see how to integrate Vault Agent into the application.