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.
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.
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.
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.
Also notice that when you do this and retrieve the keys at the path you created there is no mypass field within that path.
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.
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?
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
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
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.
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-pathCLI 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-pathCLI 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-pathThat’s all for this story. Thanks for reading and see you next time.
