Developed by HashiCorp, Vault is a secret management tool (passwords, certificates, API keys), aimed at securely storing secrets. The advantage of the tool is its flexibility to store all types of secrets statically or dynamically (temporary and variable secrets) and whatever the environment (AWS, Database, Certificate, etc.). Vault relies on one or more authentication methods (again the system is flexible) to allow secret consumers to interact, but the variety of these authentication methods and environment makes it difficult to choose. In this post, we’ll go over all of Vault’s authentication methods (also known as Authe backend), and the use cases for which they are best suited.

Prerequisite

First, for those who have never had the opportunity to see what Vault looks like, I invite you to try the interactive tutorial on the official HashiCorp Vault website in order to get a first idea.

Secondly, be aware that at the time of writing this post, Vault is in version 0.10.4 and the product is not yet complete. Some authentication methods may change or disappear.

Finally, all authentication methods as well as information relating to configuration or use can be found on the official Vault website.

Authentication methods

Among the 13 authentication methods, we will see the context of use and the answers to the problems provided by these methods.

Here is a list of methods and links to the documentation:

Each authentication method allows you to associate one or more ACL Policies, which are rights (capabilities) of actions on the Vault: read, create, update, list and delete.

In addition, it is possible to activate several different authentication methods (AWS, Azure, Google Cloud, etc.) but also of the same type (eg: LDAP for directory A and a second LDAP for directory B).

The subtlety of the choice therefore lies in the balanced use of several methods, each adapted to a specific context. We must therefore first separate the physical consumers and the applications.

We therefore have 3 types of oriented methods:

  • Token (special)
  • Human
  • Application

Token

Vault authentication method that is at the heart of the system and implemented by default. All other authentication methods are based on this one: they all return a token after authentication.

This method does not serve as identity authentication (unlike the others) but allows the rights associated with the token to be authenticated with the Vault.

Use case

The most common use case, aside from the fact that other authentication methods rely on this, is to generate child or time-limited tokens.

Example: A Vault operator wants to run a pipeline to perform CI / CD on Vault. This will therefore generate a child token of limited duration, the time of the execution of the pipeline.

Key takeaways

  • In an authentication context, this method does not provide any identity authentication and should not be used under any circumstances by a physical user or a service.
  • In the context of developing and testing the Vault solution, this is the easiest and fastest authentication method to use.
  • Finally, the direct use of this method may be possible for a case as mentioned above where the identity authentication was performed upstream by another authentication method.

Human oriented method

Username & Password

The Userpass method or also called “Username & Password” is a local Vault authentication method for physical users. The user as well as the password are to be defined via the API that Vault provides.

Use case

Like any local username and password authentication method, this is useful to discover Vault or in Test environment. Setup and use is quick and easy. This method is intended for physical users.

Note that it is possible to restrict Userpass authentication by a CIDR range (parameters: bound_cidrs). In other words, to do an IP filtering.

Key takeaways

  • In the context of a large company, it is unthinkable to manage each user (creation, password modification, deletion) with this method. It will therefore be necessary to focus on methods such as LDAP or RADIUS
  • For smaller companies that do not have a directory system and have a limited number of users of 2 to 3, it is possible to use this method temporarily with IP filtering.
  • Finally, it is possible for an application to use this method, but only as a last resort if no other method is possible. It will first be necessary to focus on methods such as Approle, TLS certificates, etc.

Github

Useful for any organization using Github. This method allows you to use github authentication with a personal access token.

Use case

Ideal if a business uses Github. The method allows within a Github organization to link one or more Github organization teams with ACL policies Vault. This therefore includes both users and developers.

Key takeaways

  • Vault does not support OAuth workflow for generating GitHub tokens. It is therefore strongly recommended not to use this authentication method as an application.
  • Strong dependence on Github. Not all Vault users are on Github, so you have to combine this method with another.

LDAP

The LDAP method allows, as its name suggests, to use directories based on the LDAP protocol. This authentication method identifies either a user or an LDAP group.

Use case

This method avoids the duplication of the username / password configuration in several places as well as its management. It is ideal for physical users but not very suitable for service accounts. Its configuration requires knowledge of the LDAP directory, but once configured, the method is suitable for a production environment.

Key takeaways

  • Ideal for physical users in a large enterprise since it allows authentication by group or user.
  • In an application / server context with service accounts, this method can be considered. However, it does not provide a sufficient level of identity authentication as some other methods might do (eg Missing IP filtering).
  • Configuration requires knowledge of the LDAP directory.

RADIUS

In the same logic as the LDAP method, it allows the use of the RADIUS protocol.

Use case

Same logic as LDAP authentication.

Key takeaways

  • Unlike LDAP, we have no notion of a group. It will therefore be necessary to manually add each RADIUS user in the configuration of the Vault. Which is not an option for a large business directory.
  • In some cases where a strong authentication level is required, RADIUS can respond to this problem. The trick is to enable and configure RADIUS for Vault administrators and LDAP for users consuming Vault services.

Application oriented method

Approle

In my opinion Approle is the most universal and easiest method of application authentication to use in an automated workflow.

On the one hand, this method ignores the environment where the application is located (cloud, on-premises, container, etc.).

On the other hand, if the method is well implemented, it allows the application to be the only one to retrieve its Vault token when it is deployed. In other words, the method allows complete isolation of the application from reading its secrets (even developers cannot read the secret).

This method is based on two pieces of information in order to authenticate the application: The role ID and the secret ID.

Use case

AppRole workflow

(from: https://www.vaultproject.io/guides/identity/authentication.html)

As shown in the diagram above, we have 3 actors: the Vault administrator, a trusted entity and the application.

The objective for these 3 actors is:

  • Vault administrator: Create the AppRole auth backend and retrieve the application role ID.
  • The trusted entity: Retrieve the secret ID.
  • The application: Retrieve the two pieces of information from the other players and authenticate with it.

Here, only the application is able to obtain its Vault token and read its secrets, unlike administrators and the trusted entity.

Finally, the goal is to limit the lifetime of the secret ID. In other words, the duration of the secret ID must be equal to the deployment time of the application so that it retrieves a Vault token (eg 10 minutes).

It is good to know that with this method it is possible to:

  • Limit the login with role ID and secret ID with a range CIDR
  • Limit the use of the Vault token with a CIDR range

Key takeaways

  • You have to have an automated workflow with a trusted entity so that the generation of the Vault token is not tedious for the Vault administrator or to prevent it from being corrupted.
  • Not all applications can be configured with a configuration management tool or via an orchestrator. It is therefore not impossible that in certain cases the administrator must be responsible for generating the role ID and the secret ID, which imposes an additional operational burden as shown in the diagram below:

AppRole authentication

(from: https://www.vaultproject.io/guides/identity/authentication.html)

TLS Certificates

The TLS Certificates method is just as universal and easy to use apart from the management and lifecycle of certificates.

The configuration of Vault must be done upstream by placing a trusted certificate (the public key) so that the client can authenticate. This method therefore also works with self-signed certificates.

Use case

Some applications like websites have their own certificates. It is therefore natural to integrate this method with applications that already have this certificate system.

On the Vault client side, it must provide: the CA certificate (preferably), its certificate and its key.

Key takeaways

  • For applications that do not have a certificate or do not take into account certificate management, it is preferable to use the Approle method.
  • For applications deployed in an automated system that takes into account the generation of the certificate, this method is ideal because it fits perfectly into the workflow. It will therefore be necessary to incorporate the application certificate into the configuration of the method in the workflow.
  • For applications deployed in a system where the management and / or the generation of the certificate is not automated, this will give more work to the Vault administrator to configure the authentication method.

AWS/Azure/Google Cloud

Here I have grouped the three methods AWS, Azure, and Google Cloud into one section as they all target the public cloud and the process remains the same. In addition, to keep things simple, I will base myself on AWS but as said previously, the process remains the same.

We have two types of workflow: EC2 and IAM. Either way, Vault will need privileges on AWS (more information on: https://www.vaultproject.io/docs/auth/aws.html#recommended-vault-iam-policy).

Regarding the EC2 part, Vault will rely on the signature (the PKCS7) of the EC2 instance in order to verify the identity of the latter and certain information specific to the instance (region, VPC ID, etc.). Vault must therefore have the access to read the metadata of the EC2 instances.

Below is a diagram illustrating the workflow:

AWS authentification workflow (from: https://www.vaultproject.io/docs/auth/aws.html#ec2-auth-method)

The information that Vault can rely on in order to authenticate an EC2 instance are: AMI ID, account ID, region, VPC ID, subnet ID, IAM role ARN, IAM instance profile ARN, EC2 instance ID, role tag, and main IAM ARN .

Of course, Vault can be based on one or more of this information. Note that if you have an AutoScaling Group, values such as instance ID are variable and must therefore be updated on the Vault side if you have specified it.

Regarding the IAM part, this consists of identifying a service (whether on EC2 or other) having IAM identifiers to authenticate on Vault. IAM authentication therefore affects more services than that directed only to EC2 instances.

Use case

Useful in the event that methods such as AppRole or TLS certificates do not provide a sufficient level of security in a cloud context (eg: secret in the userdata) or for workflows that are not fully automated. This method is ideal for retrieving provisioning secrets without exposing them to administrators of public cloud platforms.

Key takeaways

  • The Vault must have rights to the account where it must make actions.
  • The Vault must have application information (ex: subnet ID) and set the configuration accordingly. This can require a heavy operational load on the Vault administrator side if it is not automated.
  • The cross-account (Vault hosted in one account and the application in another account) can make the configuration complex.

Kubernetes

This method is based on the fact that the application is contained under Kubernetes. To identify the application, Vault relies on the Kubernetes Service Account Token (the JWT token), the service account name and finally the namespace. This therefore implies that Vault must have the rights on the Kubernetes TokenReview API side to verify its information.

Use case

This method ensures that only the application has the right to access its secrets (in the same logic as in the AppRole method). This is therefore the easiest for all applications contained in Kubernetes.

To simplify integration with Vault, it is recommended to incorporate a script to authenticate and retrieve application secrets when starting the container

Update: now your can use the Vault Agent Sidecar Injector ).

Key takeaways

  • Vault must require RBAC rights to gain access to the Kubernetes TokenReview API.
  • Each application must have a Service Account.
  • Strong dependency on Kubernetes unlike authentications like AppRole or TLS certificates.

Next steps

As you can see, we have given a great overview of all the authentication methods also known as “Auth Backend”. However, we haven’t covered two specific methods: Okta and JWT/OIDC that I invite you to watch for yourself. Knowing that these are new methods that I have not been able to test, I will not be able to provide feedback.

In view of all of its methods, it is important to remember that each of them has its strengths and that it can be interesting to mix them together. A good method is to introduce an authentication policy to the Vault depending on the context: application (automated workflow or not), human (Administrator or customer), environment (cloud or on-premises), etc.

Finally, Vault Agent appeared in the latest version of this post (0.10.4). Vault Agent (with auto auth) Allows you to greatly simplify application authentication without having to look into the Vault API or going through the Vault CLI while protecting the Token storage. I invite you to see this part in more detail in order to better integrate your choices in terms of authentication method.