4.0 - Vault Tokens

4.01 - Overview of Vault Tokens

Tokens Overview

• Tokens are the core method for authentication within Vault
• With vault server -dev the root token has been used
• This is the first method of authentication for Vault and the only auth method that cannot be disabled

Mapping of Tokens to Policies

• Within Vault, tokens map to information. The key mapping noted is a set of one or more policies e.g. the default policy maps to all users.

Practical

• Create a sample user under the userpass method e.g. demouser / password
• Under "tokens" you can select "do not attach default policy" - typically don't want it assigned anyways as it offers minimal privileges
• Can see upon login via vault login -method=userpass username= password= that no policy will be assigned
• Creating a sample policy via Policies → Create:
• Under the user the desired policy(ies) can be assigned under "generated token's policies"
• This can then be verified via re-logging in and attempting operations on any secrets specified
• Note: no policy changes can take effect unless the user with the token logs out and back in so a new token can be generated with the updated mapping.

Lookup Token Information

• Users can explore the details of a token with the command vault token lookup
• This will work for the user logged in to Vault
• Note: to use - the read capabilities must be added to a policy for the path auth/token/lookup-self
• Information provided include policies, paths, ttl
• For root-related ops:
• vault login <root token>
• vault token lookup
• For any other tokens - append the token desired to vault token lookup

4.02 - Token Helper

Token Helper

• By default, Vault CLI uses a "token helper" to cache any tokens used in authentication
• The tokens are stored at ~/.vault-token
• This can be deleted at any time to force-logout of Vault

4.03 - Tokens Time-to-Live

Overview

• Time-to-Live (TTL) defines the lifetime of data
• Extensively used in regards to DNS mappings

TTL For Tokens

• Every non-root token has a TTL
• After the TTL expires, the token will no longer function and any associated leases will be revoked

Token Renewal

• Achieved by using the vault token renew command whilst logged in as a particular user
• Example: vault token renew <token>
• Additional options available such as --increment=<time>

Token Defaults

• Where does the default 768hr TTL come from?
• This is defined via the vault secret at sys/auth/token/tune
• Logging into root and reading this via vault read sys/auth/token/tune, the default lease TTL and maximum lease TTL is set to 768h

4.04 - Lifecycle of Service Tokens

Service Lifecycle of Tokens

• When a token holder creates a new token e.g. you create a token, the subsequent token is created as a "child" of the original token.
• If the parent is revoked or expires, as will all its children regardless of their own TTLs.
• E.g. suppose token 1 is the parent of token 2.
• If token 1 is not renewed, it is revoked by Vault, and as a result token 2 will be revoked.

4.05 - Token Accessories

• When a token is created, a token accessor is also created and returned.
• This accessor is a value that acts as a reference to a token, and can only be used to carry out certain actions regarding it e.g.:
• Look up a tokens properties
• Look up a tokens capabilities for a particular path
• Renew the token
• Revoke the token

Example Use Case

• Accessors can be used to save central services from storing and managing multiple tokens used as they can be used to renew and revoke any tokens associated with the processes
• To view the accessors: vault list auth/token/accessors
• For a particular token's accessors: vault token lookup -accessor <token accessor ID>
• Note: Tokens cannot be generated by using the token accessor!

4.06 - Overview of Orphaned Tokens

• Orphan tokens are not children of any parent token - they therefore do not expire when the "parent" does
• They are the root of their own token tree, however orphan tokens still expire when their own max TTL is reached
• One can determine if a token is an orphan by checking the field of the same name when running a vault token lookup command
• To create an orphaned token:
• vault token create -orphan as whichever user you desire that is capable of token creation.

• Note: this would require a user with the following capabilities outlined in a policy:

  ```go path "auth/token/create" { capabilities = ["create", "read", "update", "sudo"] }

  path "auth/token/lookup" { capabilities = ["create", "read", "update"] } ```

4.07 - Cubbyhole Secret Engine

• Cubbyhole secrets engine provides a private secret storage space unreadable by any other users (including root).
• One cannot reach into another token's cubbyhole, even as the root user.
• This secrets engine is enabled by default. It cannot be disabled/moved/enabled.
• In the cubbyhole secrets engine, paths are scoped per token.
• When the token is expired, the associated cubbyhole is destroyed.
• By DEFAULT - Cubbyhole secrets engine will already be in place for any user that has the default policy assigned.
• The default policy allows users to create/read/update/delete/list all secrets in their particular cubbyhole
• All operations in the cubbyhole user is facilitated using the user's particular token at the time of login.
• Suppose a user logs in and has a new token generated - that token will not be able to do anything with the secrets.
• Verify via vault read cubbyhole/<path>

  - One must use the same token used creating the secret e.g. if creating it in the UI, that token must be used via vault login <token>

4.08 - Response Wrapping

• As outlined in AppRole usage i.e.
• Policy and role for app created
• Role ID and Secret ID are generated
• Role ID and Secret ID are passed to and used by the app to authenticate to Vault, which returns a token.
• Response Wrapping aims to secure this process. The steps are outlined as follows:
  1. AppRole Auth Backend is mounted
  2. Policy and Role created for app
  3. Role ID received by Trusted Entity (Terraform, Kubernetes, Ansible, etc.)
  4. Role ID Delivered to app
  5. The Trusted Entity (Terraform, Kubernetes, etc.) receives the wrapped secret ID from Vault
  6. Vault returns the wrapping token to the trusted entity
  7. The trusted entity delivers the wrapping token to the app
  8. The app uses the unwrapping token to unwrap the secret ID stored in the Vault
  9. The app logs in via the Role ID and Secret ID

Working

• When the response wrapping is requested, Vault creates a temporary single-use token (wrapping token)
• The wrapping token is inserted into the token's cubbyhole with a short TTL
• Only the expecting client who has the wrapping token can unwrap this secret.
• If the wrapping token is compromised and the attacker unwraps the secret, the application will not be able to unwrap again
• This can be used in conjunction with monitoring tools to implore admins to revoke the appropriate tokens.

In Practice

• New tokens can be created by vault token create
• This displays the token in plaintext
• Use vault token create -wrap-ttl=<time in seconds>
• This displays the wrapping token that can be used to unwrap the secret associated
• vault unwrap <wrapping token>

4.09 - Overview of Batch Tokens

• Batch tokens are encrypted blobs to carry information to be used in Vault actions - but they do not require any on-disk storage to track them.
• With Vault Replcication enabled, the pressure on storage backend increases as the number of token or lease generation requests come in.
• As batch tokens don't require disk storage, making them very lightweight and scalable, they serve as a strong solution to the problem.
• The caveat is however, they lack a lot of flexibility in comparison to a standard service token.

Analysis

Feature	Service Token	Batch Token
Can be root tokens	Yes	No
Can create child tokens	Yes	No
Renewable	Yes	No
Periodic	Yes	No
Can have particular max TTL	Yes	No (fixed TTL always)
Has Accessors	Yes	No
Has CubbyHole	Yes	No
Revoked with Parent if not orphan	Yes	Stops Working
Dynamic Secrets Lease Assignment	Self	Parent (if not orphan)
Can be used across performance replication clusters	No	Yes (if orphan)
Creation scales with performance standby node count	No	Yes
Cost	Heavy Weight - Multiple Storage Writes per token creation	Lightweight - No storage cost for token creation

Batch Token Example

• To create a batch token, the -type flag is used to specify a batch token. Note that by default, if this is not provided a service token is provided.
• Example: vault token create -type=batch -policy=default

4.10 - Token TTL Configuration

Recap

• Every non-root token has a Time to Live (TTL) - defining how long the token remains valid for.
• After the TTL expires, the token no longer functions and any associated leases are revoked.

TTL Dependency

• TTLs are dependent on a combination of multiple factors, such as:
• The system's max TTL - 32 days
  • This can be configured in Vaults configuration file.
• The max TTL set on a mount using mount tuning
• A value suggested by the auth method issuing the token.
• The default and max lease ttl can be configured via the following: vault write sys/mounts/auth/token/tune and appending either or:
• default_lease_ttl=<time>
• max_lease_ttl=<time>
• To configure a new default and max lease TTL for an auth method, this can be configured during setup of the auth method

4.11 - Periodic Token

• Periodic tokens = tokens that never expire (so long as they are renewed)
• Aside from root tokens, periodic tokens are currently the only way for a token in Vault to have an unlimited lifetime e.g. to work so long as a service is running.
• To create a periodic token - vault token create -period=<time>
• Note - a similar scenario is NOT achievable via repeatedly doing vault token renew as this will conflict with the max ttl of the associated auth method.
• Note - warnings are always provided with periodic tokens - this may be due to the period value exceeding the max TTL.
• Note: Periodic tokens should only exist for as long as required e.g. until a service has done its job!