AWS Secrets Engine Lab

00:02

Welcome back to the vault training. In this video, we will doing a lab activity using the AWS secrets engine,

00:10

so that's gonna bring with it a prerequisite. However, you're gonna need to set up an AWS account before you proceed.

00:16

If you need the free tier, you can find the link to the sign up page on the get hub for this particular lesson in the lab materials once you have your AWS account in hand,

00:29

first things were going to do is to set up an APP account in AWS for vault. Then we're gonna bind your local vault development server to that account so that it connect with AWS and issue certain commands.

00:43

Then we're going to exercise this AWS Secrets engine and see how vault itself generates additional AWS accounts and provides us with the access keys.

00:53

And finally, we're going to examine the impact off getting rid of one of those accounts in vault of revoking the account itself and evaluate the implications that it has on AWS. So we're going to start out on the home screen of the AWS management console. You're going to navigate 2 a.m.

01:11

because we now want to create the account. That vault is gonna act us.

01:17

Let's go to users. You may have users. I do not. We're gonna call this account the vault account.

01:23

It's gonna need programmatic access, but it doesn't need access to the council.

01:29

Instead of going through and setting up groups and creating all sorts of specific custom permissions,

01:34

I'm going to use some of the default permissions that AWS has.

01:38

However, if you're doing this in a production capacity, you're gonna want to review vaults documentation for the AWS Secrets engine. And in there they have a very specific policy set that if you want to go ahead and create a custom policy, this is what the vault account needs the ability to do in AWS.

01:57

And it's pretty much limited to just this

02:00

for a particular example. However, I'm going to give it a few more capabilities by signing at the A w. Excuse me that I am full access policy

02:12

worried about tags.

02:14

Let's go ahead and create the user.

02:15

Now I need to make sure to get a hold of the access keys. So we're gonna copy this off to a note pad somewhere,

02:29

and also we're gonna grab the access key.

02:34

So what? That complete. Let's hop over to our local computer

02:38

and fire up the vault Dev server.

02:46

Okay?

02:47

And I'm just gonna copy off the route token as well.

02:54

Okay. And let's get used involved. Vault secrets list to see the different secrets cubbyhole, identity, secret, and then system.

03:04

We want to use the AWS secrets engine. So the first thing we need to do is enabled that secrets bolt secrets enable

03:13

Dash Just say aws course I could go a dash path if I wanted to give it a different path to this secrets engine. But I'm just gonna mounted at the AWS location.

03:23

And sure enough, there it is.

03:27

Okay. With secrets engine now enabled, we need to set up with secrets engine in such a way that when a talk stay w s, it uses the access keys associated with the vault account we just created through the web Consul in AWS. In order to do this, I'm going to be making call a right operation

03:46

of the eight of us config route

03:50

information path.

03:52

Just as a quick side note, if you are interested in all the nuances in different paths when communicating with the AWS Secrets engine, you can find all that documentation on the hash corpse site. There's an eight AWS engine ap I page that lists out all the different things. We're not gonna cover that in its entirety,

04:12

but we are going to use a few of those commands.

04:14

So getting back to this AWS CONFIG route, we want to pass it one key parameter for the access key. This is the access key of the account we just created. So go ahead and copy and paste that

04:30

and then we're gonna set up another parameter. We'll call it the Secrets key.

04:35

This, of course, being the secret key associated with the account that we saved off to our note pad on the side and then last will specify a parameter to just indicate the default region

04:49

when vault is interacting with eight of us that various resource is should

04:56

be correlated with

04:59

and success so that has now been written. Now we need to set up the AWS secrets engine in such a way that when it creates user accounts, it also assigns a certain permission set with him, or it assigns that account of role And in order to do that, we're going to actually be

05:17

specifying a AWS policy.

05:19

I'm not gonna get into the details, but included in the repository for this training account, you'll find that we have an easy to dash policy file, little Jason file and effectively you can review it. It's providing the account with all sorts of rights and permissions when it comes to easy to resource is.

05:39

So let's go ahead and write that file fault AWS called roles and we're gonna give this role in name. We're gonna call it the easy to admin role credential

05:51

type is going to be I am user

05:58

and the policy document.

06:03

We're just gonna pointed to our file

06:06

now in the same working directory of the repository that coincides with this module of the training

06:16

and success.

06:18

So let's give this a shot and call the AWS secrets engine,

06:23

see if it can return us access keys for an AWS account that itself is going to generate.

06:31

We're gonna call for some credentials

06:35

and we want the role of this account to be associated with EEC to admin policy that we just created.

06:44

And there we are. So we have now been not given. Ah, vault token, right? We already have that. But we have access keys that allow us to interact with AWS and has a least direction of 768 hours. Now. I could change the configuration and reduce the default leaf least duration if I wanted to

07:03

and make thes credentials expire

07:06

more frequently and require rotation by the various consuming services that are relying on vault. To obtain these in the first place,

07:15

it's up back over to the Web browser and see if we can observe what just happened. So this was the account we created. But this was created by vault itself. So very interesting. Just taking a moment digging in,

07:29

we can see Here we go. The permissions EEC to admin was directly attached policy. And if we go over to the security credentials tab, we can see the access key that was just created by vault. So from this point, if we had other processes that wanted to read and interact with AWS,

07:46

they could provide these keys and do so

07:49

In this circumstance. Let's say there was a problem. We saw some anomalous behavior of, however, this account was being used and we want to go ahead and we want to revoke this particular access key. So we're gonna tell vault a go ahead in revoke this PC to admin account that you created,

08:07

but we need to let it know what was the i d off this particular one which is listed up here, right that the least i d

08:16

and I'm gonna bring that down

08:18

and to diet has successfully revoked the access keys and the account. Let's toggle back over to the browser

08:28

It a little refresh and sure enough, the account is gone and that covers it for this lab activity. Just to recap, we created a vault user in AWS. We configured our local death server to talk to AWS as that vault user. We then did some additional configurations of the eight of us secrets engine.

08:48

We generated a user account. We saw the access keys that vault provided to us.