4 hours 53 minutes
Welcome back. This is our final video on access management involved
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.
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.
And we also used the plus character
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.
And you could imagine as you get more and more secrets,
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
have a little more flexibility in how we define these paths
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
to reset their password. And if you were constrained to just having static policies, you have to create a separate policy almost for
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.
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,
right? So one thing note is that
I ds are always preferred
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.
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.
We're gonna play with that. Actually, here in this particular video session,
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.
Start up the server. Of course, if you haven't already done that
and we are going to
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
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,
we're gonna need that in a second.
So first up, you'll see we have the password reset policy. And the point of this policy is to provide
those with a user pass account the ability to update and change their passwords.
The deal is, we're using identity, entity and aliases,
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
from your side,
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
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,
um, not to create it. And we are also Onley allowing for the past word parameter itself to be stored in there.
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
the immediate prior video, we were talking about how the
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,
that's going to become pretty ian maintainable. You always have to create a policy, and
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
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
continue to create those and add those and managed specific policies and memberships.
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.
So let's hop back over to the terminal and create those vault policies using the policy template files that we just reviewed.
So let's create the primary mission
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
She isn't defined in this file.
And let's create the
James Bond account.
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
the identity of James Bond to the primary mission of policy.
And last but not least,
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.
Now let's jump over to the Web interface for simplicity, of creating the identity in the group,
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,
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
go ahead and create that identity. Now we need toe build an alias that's going to create that association between James Bond
in the User Pass and this James Bond identity.
Let's go ahead and create that Secret Agents group as well,
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
and log in
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
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
mission good. So they're read. And that's because the primary,
the the entity here, the primary mission value for James Bond
is has expected
and a data GoldenEye.
But if we were to take it and say What about Dr No
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
except gold and I we have denied.
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
in the path for which you are going to define these policies and capabilities and denials and so forth,
this is the way you're going to go about solving that problem.
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
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
authenticates with vault to obtain its tokens.
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
make a mess in the way you organize your policies the way you organize secrets.
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,
especially as an operator administrator, a vault
so you can put your focus on the more interesting things and problems to be solved on the day to day