Vault Part 2 - Introduction to Secrets and Secrets Engines

Goal: This post aims to provide an introduction to Vault secrets 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.

If you’ve used Kubernetes (or anything else really) to manage your containers before, you have a secret resource where your “secrets” like app creds, tokens, keys are kept as base64 encoded (or if you want, plain text). In case of apps, your secrets are somewhere in a config, known to a few sys admins and manually entered to said config or at best encrypted on a case by case basis.

image source here

Secrets

The point of Vault is secret management. Vault can create and share secrets securely and with identity control of it’s users. Your secrets are held in secret-engines and each provide a certain set of features.

vault secrets engines

Before moving on to detail working with secret engines, one nifty feature of Vault secret engines is that they can only view folders under their root folder named with a UUID when they are enabled. Vault storage layer does not support relative paths so enabled secret engines can only access whatever secrets they have within under their parent root directory. So if an engine is compromised, you don’t need to nuke Vault itself.

When we started Vault, by default we got two secret engines. We are interested in the key-value engine that is version 2.

kv v2 secret engine

Adding/Reading Secrets

It’s quite easy to add a secret to the kv engine via the UI. Right below is the same operation from the cli.

our super-secret secret
sending a secret

Also notice that when you do this and retrieve the keys at the path you created there is no mypass field within that path.

getting back our secret

This is because the default behavior of Vault is that the secret is actually the path itself and whatever Value is under it. PUT method, which is the primary method of creating data, creates a new version disregarding old values. Additionally, the key column that’s written in the UI is actually the fields which can be blank because you are not really interested in the fields.

get only a certain field

This is a little counter-intuitive since you would expect the new “key=value” to be added, not overwritten. Here is the battle that was fought for this. The expected action at that time was if you want to keep your fields but change one was, get every field=value from the secret path and modify the one you want and then send in the update command.

The UI works in the expected way as well when you really look at it. Also was that a bug?

allrighty then

BUT

That battle in the link gave fruit and patch command was born. Running below command will actually get you the update as it should. This command also creates a new version so…yeah.

vault kv patch secret/super-secret-path this-is-cli-reporting=wowlongkey
data in our super-secret-path kv secrets engine

Not much to say about it now but each secret you push to the path increments the secret version, so if you wanted an older version of a secret you can attach -version=3 to your get command or select the version from the UI

can have many versions of a secret

Now that we created our first secret with an immediate problem, let’s move on to deleting them. When we select delete from the UI we get a bunch of options to delete.

deleting a secret
how nuclear would you like to go

If we deleted a version with the first option we could undelete via cli. the other delete options basically nuke a version or the whole secret.

vault kv undelete -versions=7 secret/super-secret-path

CLI deletion is a bit more merciful and by default does the first delete option. having no version in the command, means it will delete the latest version.

vault kv delete -versions=7 secret/super-secret-path

CLI Metadata command on the other hand is a weapon of mass destruction capable of nuking your secret. Below command will nuke your secret as a whole. I wouldn’t recommend touching this with a ten foot pole.

vault kv metadata delete secret/super-secret-path

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

--

--

--

Let’s talk devops, automation and architectures, everyday, all day long. https://www.linkedin.com/in/yigitirez/

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Midpoint of a Linked List — Coding Question

Refactoring and Flutter’s BLoC Pattern

Common Digit Longest Subsequence

Precision T3600 Q4000 E5–1650 V1 3.2 Ghz 16Gb Ram 240Gb SSD

Understanding Git(Part 2) - Installing and Configuring git.

The Quality Engineering Transition Guide: Expansion (3/4)

CS371p Spring 2022: David Klingler

Finding the Balance: Why FinTech Organizations Need the Hybrid Cloud

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Yiğit İrez

Yiğit İrez

Let’s talk devops, automation and architectures, everyday, all day long. https://www.linkedin.com/in/yigitirez/

More from Medium

Vault Part 5 - AppRole Authentication with Vault

Cyber Security Engineer Fundamentals — Docker and Containers

Cloud Security Risks to focus on in 2022

Setting up your AWS Monitoring — Security tips