Policy Templating

00:00

Welcome back. This is our final video on access management involved

00:05

in this video. I would like to talk about policy template ING gave you an understanding of where is valuable on how it's helpful, will then go ahead and create Deploy a template ID policy file, and we'll test it out to see it in action.

00:21

Earlier, we looked at basic policy files, and so we used fully defined paths. We used the GLOB character to act as a wild card at the end of the path and help spread the value of paths that the particular policy and capabilities were applicable to.

00:39

And we also used the plus character

00:42

for a single directory wildcard to enforce a certain directory hierarchy being in place. Before that, a policy was applicable. But there still are pretty much limitations because beyond those two things, the paths were rather static.

00:59

And you could imagine as you get more and more secrets,

01:03

you want more and more policies around the secrets around the different capabilities that you want people to have. By interacting with different paths off the vault system. It gets a little difficult to manage, so it would be very valuable if we can somehow

01:19

have a little more flexibility in how we define these paths

01:23

and even incorporate information about the identity that's interacting with the vault. Great example is giving users the ability to reset their passwords. If you're using the user path off back end, not everybody has the right

01:40

to reset their password. And if you were constrained to just having static policies, you have to create a separate policy almost for

01:48

anybody, because the user name itself is in the policy. However, if we can dynamically include the user name of the identity that is authenticated and provide him with right with that substitution taking place, then we have some real power. And that's what we're talking about with policy template ing.

02:07

And to really bring this full circle, let's jump into the Hash Corp documentation to have a link to this on the get hub site, and this is the template ID policies. Here's all the different variables. Well, let's call it that you can reference in your template files. Take a look at this. Review it. You've got the I. D. You have the name,

02:27

right? So one thing note is that

02:29

I ds are always preferred

02:32

in the sense that the name of a user's account the name of a group that can always be changed. But ideas really are preferred because those are immutable. They're not going to change unless you destroy your entire storage back end and recreate things from scratch.

02:51

That's what we're doing in these courses, right? Because we're starting the Dev Server. But in the real world, you're not going to be using the in memory data, persistent storage. So you do it about the entity. You can do it on metadata these air additional key value fields that get assigned to the different identities.

03:07

We're gonna play with that. Actually, here in this particular video session,

03:12

you can traverse aliases. You can't even do it and incorporate information about the groups that the identify user may belong to. So let's hop over to the command prompt.

03:23

Start up the server. Of course, if you haven't already done that

03:30

and we are going to

03:34

take a look at enabling the user path So for this example, we're gonna go with that user passed off back and so enable user pass

03:46

very good.

03:50

And let's think a minute toe look at the user path. So do we. See, we have to off methods that are set up. This is the excess er. This is a unique Lee identifying Mount Point, so to speak, within the vault system. When it's referring to the user pass,

04:09

we're gonna need that in a second.

04:12

So first up, you'll see we have the password reset policy. And the point of this policy is to provide

04:18

those with a user pass account the ability to update and change their passwords.

04:26

The deal is, we're using identity, entity and aliases,

04:30

and then we need to update the excess er here to be the actual name off the user pass. Right. So we were looking at this access er a path in the terminal previously, this is kind of difficult that it's not easy to just do it. So you're gonna have to copy and paste

04:49

from your side,

04:50

going back and looking at your output when you run the all off list command and copy and paste. Whatever these numbers are in this full path here and then go ahead and paste it into the template policy here

05:05

and save it and we'll be using it in a moment and you can see we've given the ability to update the password,

05:11

um, not to create it. And we are also Onley allowing for the past word parameter itself to be stored in there.

05:23

Now, let's open the second template policy that we've created. Nothing needs to be changed with the policy itself, but I wanna take a look at it. So here we're saying for the past secret data. And then we had some back and forth last time. Right? As we closed out

05:43

the immediate prior video, we were talking about how the

05:46

Intel update,

05:47

um, policy allowed an agent to write intelligence to any mission, regardless that they were part of that. And and we also created individual policies that provided different agents access to the specific missions. But as you can imagine, if you create a lot of missions over time,

06:06

that's going to become pretty ian maintainable. You always have to create a policy, and

06:12

you kind of have to go through all these different things. So rather than managing that, what I'm proposing here is let's create a metadata element for the identity James Bond in the key for that metadata thing is going to be primary mission

06:30

and the value is going to be the name off, whatever that mission is, Doctor No gold. And I Specter so with this policy, we don't need to keep having the doctor No policy. We don't need the gold I policy. We don't have to

06:46

continue to create those and add those and managed specific policies and memberships.

06:53

Rather, we just have ah metadata item that's associated with the James Bond entity. And whenever their primary mission changes, we update the value of that. And so now they can read on Lee. One mission at a time makes a lot more sense, and we don't have to go update and create new policy every time a mission is started.

07:12

So let's hop back over to the terminal and create those vault policies using the policy template files that we just reviewed.

07:23

So let's create the primary mission

07:27

policy that has talked about and that will give us the read access to whichever mission associate with the primary mission metadata elements and that being defined in our lab. And then we're gonna go ahead and create the password Reset. Paul Single. This followed pass

07:46

reset.

07:47

She isn't defined in this file.

07:54

And let's create the

07:56

James Bond account.

07:59

Um, here we go. And this time we're going to say the passport is shaken and we're going to assign this account to the primary. Me to no policy. Excuse me. We're not going to sign this account to any policy. We're gonna keep it simple. What we're going to do is be assigning

08:16

the identity of James Bond to the primary mission of policy.

08:20

And last but not least,

08:24

let's put a secret. And the golden eye location key equals value. Is this for that GoldenEye mission, which is post So top secrets on that was created.

08:39

Now let's jump over to the Web interface for simplicity, of creating the identity in the group,

08:46

signing in using the route token. So I will have full permissions. Here's that secret we just created called Gold and I Keys. Key values value. Coming back to access. Let's make a new entity,

09:03

James Bond. And as we spoke about what we want is this entity to be a primary mission and in here, let's say primary mission was to find a value for this and called GoldenEye

09:18

go ahead and create that identity. Now we need toe build an alias that's going to create that association between James Bond

09:26

in the User Pass and this James Bond identity.

09:31

Let's go ahead and create that Secret Agents group as well,

09:35

and we want to give all our secret agents the ability to reset their passwords. So we're gonna put them with the reset password password reset policy. Excuse me. And of course, we're gonna add a good old James Bond to that group membership. Let's hop back over to the terminal

09:54

and log in

09:56

with James Bond's Using User past James Bond's The user name Password Shaken. We have now logged in. And, as expected, we have two policies above and beyond default associated with US password reset and primary mission

10:13

being James Bond. Let's go ahead and see if, um, the capabilities air, as expected when we are looking at the secrets data Gold and I

10:28

mission good. So they're read. And that's because the primary,

10:33

the the entity here, the primary mission value for James Bond

10:37

is has expected

10:41

and a data GoldenEye.

10:45

But if we were to take it and say What about Dr No

10:52

then the answer would be denied. However, we could adjust this without creating any new policies and just going ahead and editing. And it's saying, Doctor, no here, saving it up and back over. Check it again. Now we have read right

11:11

except gold and I we have denied.

11:13

So hopefully you can see how the template policies works out here. Some of the power behind it, definitely. You're gonna want to make reference to the list of entities here, Play around with it a bit. But when you get these circumstances and it would really love to include some information about the authenticated identity

11:33

in the path for which you are going to define these policies and capabilities and denials and so forth,

11:39

this is the way you're going to go about solving that problem.

11:43

So to bring this particular video to close, what do we talk about? We talk about scenarios for policy tempered Ling, we reviewed some of the template policies. We even created one using the assessor for the user pass, and then we tested out the policy template file

12:01

in this overall module. We really covered a lot. We talked about policies controlling what they are how they tie in, how you can manage and consolidate the identity, even if a particular user or system or whatever has different authentication, user names and i d s that it

12:20

authenticates with vault to obtain its tokens.

12:24

And we reviewed how to leverage groups even further. Organize your policies, your entities in your people. You know, it's gonna take, ah, lot of thinking to keep your policy structure powerful, providing the least privileges, but manageable to because you could quickly

12:41

make a mess in the way you organize your policies the way you organize secrets.

12:46

So it's definitely worth an investment of time. You can always change things up a little bit, but the more you think through the scope of use and get a good standard and structure that the entire team is on the same page with ah and really understands the easier these things are going to be to manage in the long term,

13:03

especially as an operator administrator, a vault