Vault Part 3 - Deeper Look Into Secrets Engines

Goal: This post aims to provide a deeper look into Vault Secrets Engines as part of a series of posts starting from here.

What we need

• Running Vault, preferably in dev mode. See Part 1 for installation if it doesn’t exist.

Deeper and deeper we go. image source here

Secrets Engines

Secrets engines are components that generate, and encrypt secret data for an app or a user to use. They are enabled at a specific path in your storage and every secret related with that engine is created as a child path within the engine root path.

Below, we created another kv engine, added a random secret called 11 with unimportant field=values and then tried accessing a secret (super-secret-path) from the kv secret engine called secret. Creating another engine of the same type makes all engines of that type lose their default secret listing for some reason like below.

don’t name secrets 11

If we disable a secrets engine, all secrets within it will be deleted permanently so careful on that one.

the red button

Dynamic Secrets (Again)

Vault can create secrets on the go which have a set time to live. We would normally ask for credentials from a db admin to access a db with read-only permissions for example. Using Vault, the developer can query Vault directly to get their creds which would be revoked at the end of the day. Let’s see it in action. We will be enabling aws and a postgres db secrets engine and do their configurations.

AWS Engine

Dynamically Generating AWS IAM Users with Vault

DB Engine

Dynamically Generating DB creds via Vault

What happens within these cases is Vault creates a lease which is the required credentials plus extra information like time duration. if the lease is renewable or not and depending on secrets engine, some other useful info. After the lease expires Vault will automatically revoke the credential and it will no longer be valid at the source.

Lease times are configured within the engine. In a case like below, if we don’t give specific lease TTLs, defaults will be used.

default config

We can also revoke either a single lease or all leases under a secret with the below commands. To start processing of revoke for a single lease we can use;

vault lease revoke postgres14/creds/read-only/q2hiKZVSQgp24mBS7nImsCMw

or for all leases under an engine;

vault lease revoke postgres14/creds/read-only

Transit Engine

What transit engine does is, it provides encryption as a service so you don’t have to deal with or know encryption features and requirements.

Encryption as a Service with Vault

Time Based One-Time Passwords

Time Based One-Time Passwords, with Vault

PKI Secrets Engine

Vault can also act as an intermediate certificate authority as well. Normally, you would get your certificate by sending a CSR (Certificate signing request) you created signed by your private key to a CA(Certificate Authority) for them to sign as well. This process naturally takes time.

Vault suggests doing the previous process once, and then using the PKI Engine to generate or sign other certificates for use, acting as another intermediate CA. If your certificates were managed via Vault, you wouldn’t have to bother with certificate revocation processes for every app and just drop the certificate like a lease.

Now I’m not going to get into this more because while the logic seems great, there seems to be a whole lot of options to go through. Doesn’t look quickly accessible so let’s leave that for later but just wanted to let you guys know if you want to go ahead yourselves.

Cubbyhole Secrets Engine

You may have noticed (I feel like I’m using this a lot :D) that whatever user we login with, cubbyhole is always available.

the ever existing cubbyhole secrets engine

While the naming is something I’ve never heard, it means a small space for someone/something (among many other things apparently).

well

The picture below is representative of Vault’s meaning as well. Cubbyhole secrets engine creates a private secrets engine belonging to the token using it. Not the user, the token. Not even root can access it. Similar to token secrets engine, it cannot moved or disabled. If the token owning the cubbyhole is gone, so is the secrets engine for it.

source: https://wordpandit.com/cubbyhole/

So, how does a user have access to their own cubbyhole you might ask? Why, it’s right there in the default policy.

# Allow a token to manage its own cubbyhole
path "cubbyhole/*" {
    capabilities = ["create", "read", "update", "delete", "list"]
}

That’s all for this story. Thanks for reading and see you next time.