Difficulty: beginner
Estimated Time: 10 minutes

Logo

Before a client can interact with HashiCorp Vault, it must authenticate against an auth method to acquire a token. This token has policies attached so that the behavior of the client can be governed.

Since tokens are the core method for authentication within Vault, there is a token auth method (often referred to as token store). This is a special auth method responsible for creating and storing tokens.

Consider the following scenarios often encountered outside of Vault:

  • There is no break glass procedure available for revoking access to credentials in the event of a breach
  • Credentials for external systems (e.g. AWS, MySQL) are shared
  • Need temporal access to a database in a specific scenario

Solution

Vault has built-in support for secret revocation. Vault can revoke not only a single secret, but also a tree of secrets. For example, Vault can revoke all secrets read by a specific user or all secrets of a specific type. Revocation assists in key rolling as well as locking down systems in the case of an intrusion.

If a user or machine needs a temporal access to Vault, you can set a short TTL or a number of uses to a token so the token is automatically revoked at the end of its life.

This also allows for organizations to plan and train for various "break glass" procedures.

Almost all operations in HashiCorp Vault requires a token; therefore, it is important to understand the token lifecycle as well as different token parameters that affects the token's lifecycle. This lab demonstrates various token parameters.

  1. Create a Short-Lived Tokens
  2. Token Renewal
  3. Create Tokens with Use Limit
  4. Create a Token Role and Periodic Token
  5. Create an Orphan Token

This scenario gave you an introduction to Vault token lifecycle.

  1. Created a Short-Lived Tokens
  2. Renewed Token TTL
  3. Created Tokens with Use Limit
  4. Created a Token Role and Periodic Token
  5. Created an Orphan Token

To learn more, please reference the following:

References:

Vault Token Lifecycle

Step 1 of 6

Create Short-Lived Tokens

Login with root token.

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

vault login root

Each token has a time-to-live (TTL) with an exception of the root token. Tokens get revoked automatically by Vault when it reaches its TTL.

When the interaction between Vault and its client takes only a few seconds, there is no need to keep the token alive for longer than necessary. If you don't explicitly specify, token's default TTL is 32 days. Let's create a token which is only valid for 30 seconds.

First, let's see the help message on token creation.

Enter the following command into the terminal, or click on the command to automatically copy it into the terminal and execute it.

vault token create -h

Create a Short-Lived Token

To specify the life of a token, run the vault token create command with -ttl parameter:

vault token create -ttl=<duration>

To clear the screen: clear

Execute the following command to create a token whose TTL is 30 seconds, and save the generated token in a file named, ttl_token.txt.

vault token create -ttl=30s  \
    -format=json | jq -r ".auth.client_token" > ttl_token.txt

Notice that the generated token inherits the parent token's policy. For the training, you are logged in with root token. When you create a new token, it inherits the parent token's policy unless you specify with -policy parameter (e.g. vault token create -policy="base" -ttl=30s).

Test the Token

vault login $(cat ttl_token.txt)

The output displays the token_duration left with this token in seconds.

Wait for a few seconds to let the TTL to be reached, and re-run the login command:

vault login $(cat ttl_token.txt)

You should receive permission denied error. After 30 seconds, the token gets revoked automatically, and you can no longer make any request with this token.

Log back in with root token:

vault login root