DB Secrets Engine Lab

00:02

in this video, we're gonna build on the set up activities we performed previously, and we're gonna enable the DB Secrets engine on our own vault dev Server.

00:11

We're going to define the mongo db role in that vault death server.

00:16

We're gonna use the vault death server to produce and retrieve mongo DB credentials.

00:21

And finally, we're gonna revoke those credentials using vault.

00:26

If you don't have the vault. If server running, go ahead and kick that off in a separate session window now want to issue some vault commands to enable the database secrets engines, a vault, secrets enabled database

00:43

whips and, as usual, the vault address that think get me every single time. There we go.

00:51

Now we need to configure the vault database engine to talk to the mongo db that we just set up on that server.

00:59

You can look at the data base secrets ap I engine, which is what we're gonna use. And there's the database config file. This is all on the Hash Corp website. I have some commands in the gift shop repository,

01:11

but they don't know the particular I p address of your server or the host name. So you're gonna need to substitute those things in.

01:19

We need to write that configuration to vault. We're going to use the vault right command, and specifically, it's going to be the database config. And let's call it our AWS. It's gonna be mongo db so aws Mongol to be being name of the configuration is a few parameters we need to specify as part of this configuration the plug in name being one

01:42

mongo DB database. Plug in being the name of the plug in. We also need to tell Vault where the allowed roles. And this is what it's going to rely on to determine the roles associated with the various accounts and connection strings when it is communicating the vault.

01:57

So let's stick with our double 07 James Bond theme,

02:01

and that's what we will call the roll. Then we need to specify the connection you are. L

02:09

first is gonna be the mongo DB protocol.

02:15

Then we're going to say used the user name the value of the user name parameter that we're also going to specify in this configuration and vault will at runtime perform the necessary substitution. Similar. We're going to do that for the value of password

02:31

we say at and now we need to specify the way that that vault can communicate with this mongo DB server from our local machine over the public Internet. So if you go to the Amazon Web Services page here, you can see down. There's the public DNS name off that server

02:49

that we created, or at least the the entry point for the V Net that the server resides on. I'm gonna go ahead and paste that in,

02:55

and then finally, we want to articulate the pork, going to 7017 And let's be sure to close that string and go to a new line. Next parameter is going to be the user name, which is admin and final perimeter password,

03:15

which is password that I'm using and have set up.

03:19

We have something different. You're gonna want to put that in here

03:21

whips. Be careful on your pasting because there's a lot of typing and you have room for typos.

03:28

Now we want to create that role we call. We made reference to the world Double 07 Let's say vault right database roles.

03:38

The double of seven road. It's important that this be created. The DB name for this role will call it with the AWS Mongo db

03:51

What other parameters? So we here are going to include a creation statements, and so this is going to use the particular databases syntax to create the role. As vault talks to Mongo, it needs to

04:08

perform the action of creating the role. That's why I was so important that the

04:12

admin account we created in Mongo has these necessary privileges to create roles and create users. This is a little bit of Mongo. It's in tax here. You condone review it at the level of detail you want.

04:26

Let's define for this particular double 07 role. What is the time to live that we want the various credentials toe last? So I'm going to say one hour

04:38

and then let's give it a max timeto live. If that credential gets renewed off 24 hours, you could put other values in here, of course,

04:50

having that all set up. Let's go ahead and attempt to read the credentials. Let's read vault database credentials. Double 07

05:01

So what vault just did was provide us with Here's the Lease I D. And here's the user name. This is a mongo DB user name and then the password. This is the password for that user name. Let's toggle back to the server hosting the Mongo DB. And we're going to run the Mongo

05:20

Shell Command again

05:23

and connect to the database. But we're going to do this as the admin account.

05:29

Okay, this commands probably in your history.

05:31

And, of course, our password.

05:36

Okay, so let's go into the EU's gonna navigate into the admin database and let's list out what are the users exists. And sure enough, we have the admin user, as we did last time. But now we also see we have this new user and this is the user that vault created,

05:54

and we see details about the role assigned to this user. So he has read access to the M I six

06:00

database and read Write access to the admin database. Does that make sense in a real world scenario? Maybe not, But in this case, we're just exercising the secrets engine and observing the behavior.

06:11

Let's shoot back to the consul with the vault server and let's say we want to revoke that least we could wait an hour. But let's go ahead and just not sit here for an hour. Let's revoke the lease and perform that process,

06:28

and we did that just so we could come back and say, Show users again back on the Mongo database and observe. Indeed, that vault account or the account that vault created rather to connect to the Vongo database is now gone,

06:42

and that wraps it up for the database secrets engine section. What did we just do, right? We had the whole preliminary. And then after that, we looked with vault. We enabled the database engine we configured the connection string so that vault knew how to connect and communicate with our Mongo database server.

07:00

Then we defined a database role,

07:02

which is what told Vault, when you're creating an account that's going to be belonged to this mongo database server. What of the roles and privileges associated with that account? We then had vault generator credentials, which dynamically created of Mongo DB account. And then we went through some urgent activities

07:21

off revoking that lease. And indeed, we observed that vault destroys that Mongo DB account as well.

07:29

So that wraps up for this section on the database secrets engine the philosophy for the different kinds of databases. Post grass database sequel server database is very similar, and you can imagine that being able to do this

07:44

for your database and rotating your database connection strings and dynamically generating with a very

07:49

short time to live it's what it's doing. Ultimately right is changing the attack surface by having those credentials always evolving. So if any potential hacker gets ahold of one credential, the value of that is just for a very limited time. Only

08:05

this video also brings a close to this module is a hole just to summarize what we did. We learned about what the AWS secrets engine does, why you would use it.

08:13

We configured and use that AWS Secrets engine. We created a mongo database on AWS, and we configured and used the database secrets engine. Hopefully, this gives you a good feel for the concept of dynamic secrets and how it plays out when we're talking about