Difficulty: beginner
Estimated Time: 5 minutes

Logo

Nearly all requests to Vault must be accompanied by an authentication token. This includes all API requests, as well as via the Vault CLI and other libraries.

Although a number of auth methods are available, the client is still responsible for managing the lifecycle of its Vault tokens. Therefore, the challenge becomes how to enable authentication to Vault and manage the lifecycle of tokens in a standard way without having to write custom logic.

Vault Agent provides a number of different helper features, specifically addressing the following challenges:

  • Automatic authentication
  • Secure delivery/storage of tokens
  • Lifecycle management of these tokens (renewal & re-authentication)

Depending on the location of your Vault clients and its secret access frequency, you may face some scaling or latency challenge. Even with Vault Performance Replication enabled, the pressure on the storage backend increases as the number of token or lease generation requests increase. Vault 1.0 introduced batch tokens as a solution to relieve some pressure on the storage backend. By design, batch tokens do not support the same level of flexibility and features as service tokens. Therefore, if you need an orphan token for example, you would need service tokens.

To increase the availability of tokens and secrets to the clients, Vault Agent introduced the Caching function.

Vault Agent Caching can cache the tokens and leased secrets proxied through the agent which includes the auto-auth token. This allows for easier access to Vault secrets for edge applications, reduces the I/O burden for basic secrets access for Vault clusters, and allows for secure local access to leased secrets for the life of a valid token.

This lab demonstrates the Vault Agent workflow.

  1. Run Vault Agent
  2. Test Vault Agent Caching
  3. Evict Cached Leases

Vault Agent

Step 1 of 3

Getting Started

Wait until the initial setup completes.

Enter the following command to start the Vault server in development mode.

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

vault server -dev -dev-root-token-id="root"

Scroll up the Terminal to locate the following output:

==> Vault server configuration:

             Api Address: http://127.0.0.1:8200
                     Cgo: disabled
         Cluster Address: https://127.0.0.1:8201
              Listener 1: tcp (addr: "127.0.0.1:8200", cluster address: "127.0.0.1:8201", max_request_duration: "1m30s", max_request_size: "33554432", tls: "disabled")
               Log Level: info
                   Mlock: supported: true, enabled: false
                 Storage: inmem
                 Version: Vault v1.1.1
             Version Sha: a3dcd63451cf6da1d04928b601bbe9748d53842e

WARNING! dev mode is enabled! In this mode, Vault runs entirely in-memory
and starts unsealed with a single unseal key. The root token is already
authenticated to the CLI, so you can immediately begin using Vault.

When Vault is running in development mode, it runs entirely in-memory that the data does not get persisted. This build-in, pre-configured server is useful for local development, testing and exploration.


Login with root token

Click the + next to the opened Terminal, and select Open New Terminal.

New Terminal

In the Terminal 2, set the VAULT_ADDR environment variable:

export VAULT_ADDR='http://127.0.0.1:8200'

Login with the generated root token.

vault login root

Now, you are logged in as a root and ready to play!