In this video, learn about authenticating to Vault.
- [Instructor] Every request to a Vault server to retrieve a secret must be authenticated. Authentication validates a claim of identity. Vault validates the identity of the caller, then returns a token. Tokens are used to access secrets involved. All successful authentication requests return a token. Vault provides a number of authentication methods. Here are a few of the available methods. Human user credential systems include Userpass. Userpass is a built-in authentication system to Vault that supports username and password combinations.
LDAP Active Directory, Cloud providers including AWS, Azure, and Google Cloud, and GitHub which allows the use of a GitHub personal access token to authenticate to Vault. Some examples of non-human system authentication include AppRole. AppRole is used by applications and automation tools to authenticate to Vault. And Kubernetes, which authenticates to Vault using a Kubernetes service account token. Each of these methods has a path involved and must be enabled individually.
The tokens returned by these methods are limited use keys that are associated with the user, possibly a group, and with a policy which determines the secrets that are readable and/or writable by the token. I'll demonstrate the set up of userpass using the CLI so we can see authentication in action. We'll use the account we create to demonstrate getting an access token. The userpass authentication method uses clear text username and password. Userpass is useful for testing and compatibility purposes. It's not the best option for a production vault server.
The passwords you set on users are secrets themselves. If you use the userpass authentication method you'll need a method to protect those secrets outside of Vault. The other methods such as Active Directory or GitHub are better suited to production Vault servers. If you don't already have a Vault server running you can start one by executing vault server -dev. Once you have that scroll up to the great out text here and find the root token. Highlight it, copy it to the clipboard, and copy it to a text editor, we'll need it later.
The next thing you'll need to do is open up a second terminal window and we can execute our commands. First thing we'll check to make sure that the Vault server is running. Vault status. And our server is running. The next thing we'll do is list the authentication methods that are currently enabled. Vault auth list. And we see that the token method is currently enabled. The next thing we'll do is enable the userpass authentication method. Vault auth enable userpass.
And it's enabled. Now we'll create a user. Vault write auth/userpass/users/vaultuser that'll be the namer of our user and the password will be vault. And we've created a user. Now we can log in. Vault login -method, that's -method=userpass username=vaultuser password=vault.
And we've logged in and generated a new token. We can also log in with the token itself directly. Highlight the token here listed in the output and then type vault login and then paste the token in. This has the same effect as logging in with the username and password we just used. We can see in the output here we have a token itself, the token accessor, we'll talk about that in a moment, whether or not it's renewable, the policies that have been associated with it, and the meta username.
Now let's log in with the root token and try something new. Vault login, now go back to your text editor and find the root token, and paste it in. We can see that we've now logged in with this token, the token duration is infinite because this is a root token, it's not renewable because it doesn't need to be 'cause it will never be expired, and the token policy is root. We can now create a new token from this token while we're logged in with the root token. Vault token create.
This generates a new token with the same privileges as the previous one. The new token is now a child of the root token that we used to log in. We can create as many new tokens from this current token as we like. By default, if a parent token is revoked all of its children are also revoked. This makes it easy to revoke a chain of tokens created from a single parent. It's also possible to create orphan tokens that are not revoked when their parent is revoked for use cases where that is necessary. Now let's take a look at token accessors.
Execute vault list auth/token/accessors. These are all the accessors of the tokens that we've created. Accessors can be used to manage a token without actually having that token. Vault administrators and automation systems can use token accessors to renew and revoke token leases. We can also use them to look up a token. Vault token lookup -accessor and then we can find one of these accessors, copy it in and paste it.
Hit enter, and we get information about the token this accessor describes. Here's the accessor, the creation time of the token, the name of the token's user, in this case this is the Vault user that we just created, and the policies assigned. This is default because we didn't associate any policies with the user when we created it. We can also use the CLI to revoke this token. Vault token revoke -accessor.
And then once again, paste in the accessor. And it says that the token was revoked if it existed. We can also create a token with a time to live. Vault token create --ttl= five minutes. This creates a new token with a time to live of five minutes. If we were to wait six minutes and attempt to use this token it will have been revoked by Vault. You'll notice in the information here output that the token renewable is set to true.
This means that if we renew the token using the token itself or its accessor within that five minute window we can extend the life of the token.
- What is Vault?
- Using the dev server
- Working with Vault secrets engines
- Adding policies to Vault
- Running and using Vault
- Configuring the database secrets engine
- Implementing Vault
- Integrating Jenkins with Vault
- Using the Vault API