Difficulty: beginner
Estimated Time: 5 minutes

Vault logo

This scenario supplements the Cubbyhole Response Wrapping guide.

HashiCorp Vault's secrets engines are components responsible for managing secrets:

  • Secrets are pieces of sensitive information that can be used to access infrastructure, resources, data, etc.
  • Some secrets engines simply store and read data
    • Like encrypted Redis/Memcached
  • Some connect to other services and generate dynamic credentials on-demand
  • Others provide encryption as a service (EaaS), TOTP generation, certificates, etc.

This scenario demonstrates the cubbyhole secrets engine.

Cubbyhole Secrets Engine:

  • Used to store arbitrary secrets
    • Enabled by default at the cubbyhole/ path
  • Its lifetime is linked to the token used to write the data
    • No concept of a time-to-live (TTL) or refresh interval for values in cubbyhole
    • Even the root token cannot read the data if it wasn't written by the root
  • Cubbyhole secrets engine cannot be disabled, moved or enabled multiple times

This lab demonstrates the following:

  • Write secrets in Cubbyhole
  • Create a new token for apps which was wrapped
  • Unwrap the wrapped token and tested its permissions

You learned the vault CLI commands to interact with the cubbyhole secrets engines.

  • Wrote secrets in Cubbyhole
  • Created a new token for apps which was wrapped
  • Unwrapped the wrapped token and tested its permissions


Vault Secrets Engines - Cubbyhole

Step 1 of 4

Write Token-based Secrets

Login with root token.

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

vault login root

To better demonstrate the cubbyhole secrets engine, first create a non-privileged token.

vault token create -policy=default \
    -format=json | jq -r ".auth.client_token" > token.txt

Now, log into Vault using the newly generated token:

vault login $(cat token.txt)

Your token has default policy attached which does not give you access to any of the secrets engines except cubbyhole. You can test that by running the following command:

vault kv put secret/test password="my-password"

This should throw permission denied error.

Write Secrets in Cubbyhole

Execute the following command to write secret in the cubbyhole/private path:

vault write cubbyhole/private mobile="123-456-7890"

Read back the secret you just wrote. It should return the secret.

vault read cubbyhole/private

Try as a root

Log back in with root token:

vault login root

Now, try to read the cubbyhole/private path.

What response did you receive?

Cubbyhole secret backend provide an isolated secrete storage area for an individual token where no other token can violate.

vault read cubbyhole/private