Just a quick writeup on Hashicorp Vault, what it is, and how it can be used to secure your infrastructure. Hopefully by writing this I can retain some of the information I’ve learned about Vault instead of ending up on their documentation every time I hear about it.

So let’s start with the basics, but be forewarned I’ll predominantly be focusing on the idiosyncrasies of Vault and why it stands apart from competitors like AWS Secrets Manager and Azure Key Vault - and not the basics of security.

If you want to skip straight to the docker-compose file, it’s here

What is Hashicorp Vault?

Vault is a tool for securely accessing secrets. A secret is anything that you want to tightly control access to, such as API keys, passwords, certificates, and more. Vault provides a unified interface to any secret, while providing tight access control and recording a detailed audit log.

What is a secret?

Literally anything. Github tokens you want to be available in your terminal? Secrets. Database credentials? Secrets. SSH keys? Secrets. Passwords? Secrets. Certificates? Secrets. You get the idea.

What is a secret engine?

Vault provides a number of secret engines for protecting and encrypting secrets. A secret engine is a component of Vault that stores, generates, or encrypts data. For example, the kv secret engine stores arbitrary secrets within Vault. The cubbyhole secret engine provides a per-client secret storage area that is encrypted by a derived key specific to the client. The transit secret engine handles cryptographic functions on data in-transit.

What is a policy?

Policies in Vault are a set of rules that are enforced when accessing or manipulating data. A policy is a JSON document that contains one or more policy rules. Each policy rule specifies a path that the rule applies to, and a list of capabilities that are allowed on that path. A capability is a string that denotes a specific action that can be performed on a path, such as read, write, list, and delete. The policy language is described in detail in the Policies page.

Functionally, policies aren’t anything unique to Vault. They’re just a way of defining what a user can and can’t do. The difference is that Vault policies are applied to paths, not resources. This means that you can define a policy that allows a user to read all secrets under secret/ but not secret/foo/ or secret/bar/. Isn’t that contradictory? No, because secret/foo/ and secret/bar/ are paths, not resources. This is a subtle but important distinction.

What is a token?

Shout out to Github Copilot for suggesting this whole section, I ran out of rhetorical questions two paragraphs ago

A token is a string that applications can use to access Vault. A token is associated with a set of policies that specify the operations that can be performed with that token. Tokens can be created with a TTL, after which they are expired. Tokens can also be revoked before they expire.

Duh, but why do I care?

As a user, you don’t. But as a developer, you do. Vault demands the use of tokens to authenticate to it. You can’t just use a username and password. This is a good thing. It means that you can set up Vault to authenticate to your LDAP server, or Active Directory, or AWS IAM, Authelia/Keycloak or whatever without having to worry about the implementation details of each authentication method. It also means that Vault can be used as an intermediary to authenticate to other services, e.g. a database, without ever having to expose the credentials to the user - and for your local network, you can use it as a Bitwarden replacement for those things you want to have that extra layer of security on.

Running Vault in Docker Compose

psych.

I’m re-organising all my local docker-compose files atm and have no clue where I left the bloody thing - I’ll update this when I’m done. In the meantime, here’s the official documentation on how to run Vault in Kubernetes.