Secret Versioning

00:01

welcome back to a new module of involved fundamentals. We're going to continue talking about secrets storage in this module. Specifically, we're gonna talk about version ING capabilities. When you change the secrets,

00:14

we're gonna learn a few ways to store secrets and have it so that those secrets can only be read

00:21

by a specific access token. We're going to talk about different techniques to distribute secrets when you have less than secure channels to to provide the information. And we're going to wrap it up by talking about the APP role authentication method,

00:38

which is really bringing us into some real world scenarios of applying vault.

00:44

In this particular video, we're gonna walk through secret version ing and little more in depth, understand how to roll back secrets to prior versions in the case you make accidental changes, and we're going to review some of the precautions you can take to minimize

01:00

mistakes in making unintentional changes in revisions to particular secrets.

01:08

So far, when we've been using the key value engine, we've been using version two of the key value. So we've been creating secrets, and these are the static values of those secrets are key value pairs, and we've been using version two by default. This is enabled when you start the server in dev mode.

01:26

This also provides us the capability of secret version ing.

01:30

So let's walk through secret version a little bit. You have a secret. You created secrets. Call it secrets slash James bond slash um memoirs, right? His his daily notes as he goes about his missions. He's creating secrets there.

01:49

Any crease version one.

01:51

Then he updates it. Any creates version 234 and so forth.

01:57

New versions are always put at the top of the stack, and the version at the top of the stack is considered the current version. So if I did a request, I wanted James Bond men wires. I'm always going to get version four when that's top of the stack, unless I specify otherwise.

02:15

So the fact that we create a new version of the secrets that with every changes pretty intuitive.

02:21

And when we perform the delete operation, as we've done in the past of a secret

02:25

by default, it's going to delete the current version off that secret and thereby from vaults perspective. The secret has been deleted.

02:36

However, we can also delete specific past versions of a secret if we want.

02:43

We can always undo the delete operation as well for the current version or past versions of the secret.

02:52

But we cannot undo the operation called permanently Destroy when you run the permanent destroy operation. That's not just deleting a particular version off the secret. It's putting it in a special state so that there is no way you can get back or roll back to use that prior version of the secret.

03:13

Now, what about a situation where you've updated a secret and you've created some new versions and you realize after the fact Oh, shoot, I need to actually go back to an older version of the secret deleting in this case, let's say we have version two we want to get back to. If we delete version four and then version three,

03:32

that's really not going to get us

03:34

to where we want to go, because we've deleted the top version, the latest version of the secret. And so Vault is going to say the secret doesn't exist. What we want to do in that circumstance is we wanna essentially take version two or the value of the Secret Version two and created as the latest version

03:53

off the secret. So we retrieve version two,

03:58

take that value of the secret and then set the secret using the same value, which in effect, is creating version five. However, the true value under the covers is really equivalent to version two.

04:12

So let's jump over to the command line and play around with this for a little bit,

04:15

As is usual practice. I'm gonna go ahead and start my vault server in Dev mode to give it a fresh start.

04:25

Rule appear.

04:27

Take our route token,

04:31

and similarly, I want to do an export command of the vault address to make sure it's coming to a local host.

04:43

So initially I mentioned this version in concept for the key value secrets. Engine Onley applies to version two, and if you ever need to confirm that, you indeed are using version to the key values Secrets Engine versus version one. You can run the secrets list command, but include the dash detailed flag.

05:00

It will provide a lot more information about

05:03

all the secret engines that are mounted to your vault system. In particular, I'm looking this map version two, and that's telling me I'm using version to the key value secrets engine.

05:15

Let's create some secrets in the key value secrets engine, but I'm gonna hop over to the Web. You I to do that,

05:29

we will log in with the root token

05:32

and open up the secrets engine. And let's create a secret.

05:38

Let's call this one. Um,

05:42

let's go db

05:44

prod. This use may be a more really world situation. Here. You can see it's giving me the ability to specify the maximum number of versions for this secret that it will retain. The default is to. Then there's this require check and set

06:01

and what will play around with this on the command line as well.

06:05

But the short and skinny is this is a precaution you could put in place if you are concerned that somebody may be updating the value of secrets unintentionally, and what this requires is when you perform the secret update when you're updating the value of this particular secret,

06:24

not only will I specify

06:26

the new value that I want to have written or for the secret, but I also need to specify and reiterate what is the current version of the secret. The assumption there is. If I know the current version and here's the new value, I've done little extra diligence in performing my update operation. I'm not going to check that right now.

06:46

And then let's get some version information. Let's say Ah db

06:54

Server name is Ah,

06:58

the Post GREss que el that my site dot com,

07:05

and we'll just save that off. So now we've created a secret through the Web interface

07:12

you could see up here. It's his version one, and we have the ability to look at the history. Let's go ahead and create a new version of this. Secrets, in this case will keep the DB Server the same. But let's say Devi password equals new pass for some reason

07:29

now we've created version two of this particular secret, and let's go ahead and create one more version. I'm not gonna create a new value pair, but let's say that instead of it being new pass, that's gonna be old pass and we're changing the password. So we've created three different versions

07:48

of this particular,

07:50

uh, secret here through the Web interface.

07:55

If I want a view through the Web interface prior versions. We have the history tab. I'm gonna hop over to the command line and show you how to do that as well through the CLI.

08:05

So let's run vault Cavey get

08:09

put it in the Jason format here and let's get version equals one past that end. We want secret TV production, baby. And for good form I'm gonna pass to Jake. You just so it looks nice and pretty. And here you can see

08:28

indeed DB servers The only key cause inversion one. We created one key for the key Value store.

08:33

This was the value. And here's the other metadata about the secret. Reiterating at its version one,

08:41

I also mentioned that we can use the check and set capability. So let's run. Cavey put and passed casts

08:50

value here. So I need to specify the correct version the current version of this secret and it should be three. So we go db prod. I don't know. Let's go connection

09:07

um

09:09

db Server. Let's change this up. TV server and Kohl's Post GREss

09:16

que Well,

09:18

eight. Got my site

09:22

can. We would change the number of the post cross server for our website for whatever reason and we specified version three, which was correct. Creating version four. So let's run that command again. Maybe it's a dot CO, and sure enough, it's going to fail because we're on version for And I said, the current is version three

09:41

shooting back to the Web interface.

09:46

We have the history. If I go to an older version. We talked about deleting secrets

09:52

so we can just delete this particular version of the secret rather than deleting the secret in its entirety.

10:00

Leaving the version. This is how you can do it. Of course there's a command line equivalent and off. Obviously. Ah, http, ap I equivalent, allowing you to lead delete specific versions off a particular secret. In this case, I've deleted it says version two has been deleted.

10:18

I have the ability to come back

10:20

and now do an undue leet the version to reinstate what I had deleted previously. Maybe I made an air because the thing I didn't do was permanently destroy the version. If I do that, there's no going back. So be very cautious. If you permanently destroy versions of your secret,

10:39

just make sure you don't have to roll back to it for some

10:43

unnecessary reason,

10:45

so that covers it for this video. We're talking about versions and tracking versions of key value pairs and secrets, just in case you ever get painted in a corner and you make a change. It's very helpful to know about this capability and how to leverage it. Just to recap we learned about delete and rollback semantics

11:05

from the command line through the Web interface.

11:07

We talked about the maximum number of versions and being capable of setting that we looked at the check and set behavior and how that could be put in place to really lock down and ensure that there's no unintentional changes being made to the value of secrets. And then we talked about the permanent purge capability