in this video, we're gonna apply the concepts that we learned in the prior lecture in New real World, we're going to see entities, aliases, groups, policies, all of that in action. All coming together will actually create a fictitious scenario with a variety of policies. For the great M I six,
we're gonna manage the James Bond entity and some of his associated aliases
will create a secret agent group for him that has certain policies associated with it. And then, as a result of bringing it all together, will explore the capabilities that he has inherited by his membership to the group's his identity and all the policies associated with him.
The first thing we're gonna do is create a variety of policies using certain policy files that exist in the repository and materials for this course. I'd like to take a second and just take a review of those specifically. Look at the doctor. No positive policy here. We can see that, Dr No, it's setting up so that
for the doctor, no mission, which is its own folder, you have the rights to read.
That's taking a look at the gold I policy very similar to doctor? No, but it gives it to the secret data gold. I path those capabilities, the intel upload policy. We worked on this in the lab, so we're gonna be reusing that. And then last but not least, we created a gadget user policy. This is cues, special policy
that he wants to make sure James Bond has the ability to view all the different gadgets for all the different missions,
regardless of where it is. So just like the agent Intel upload policy, this is gonna be the gadget policy. And he can view any secret called gadget that is a sub secret off any of the particular missions that exist in our vault and is the first step in the council. You're gonna want to run the server
fresh again, as we've done unusual form.
make sure that you have the opportunity to export the vault address
and what is too quick Vault status
Look up. But you'll show us information about the current token associate ID from We are the root tokens. So we're gonna be able to do a lot of stuff. Let's go ahead and create the variety of policies that we just reviewed in the code editor, starting with the doctor. No policy
success there. Let's go ahead and go with the gold tonigh policy
and let's create the Intel upload policy.
And last but not least, we want to get that engadget user policy just so James Bond can get all the goodies from Agent Que,
and that sets up all the policies in the system.
Make sure to enable the user path authentication vault
and let's go ahead and create both of James Bond's accounts in that user pass authentication back end. Typically, you're not gonna have the same account. It could happen. But more often than not, in a real world scenario, you're gonna have different ideas and different systems, whether it be AWS
any one of the authentication back ends. But for this example willing to evolve right off user pass users make the James dot bond first.
And when we're doing this, let's also associate this with the doctor. No policy. So James dot bond will be associate with the doctor. No policy. Whereas the J Bond Devil 07
that will be password is gonna be a little different. Let's say not stirred, shaken not stirred other very famous words, and we're gonna associate that with the gold I policy that we had previously created.
We could continue to do the association and creating the entities and associating the aliases from the command line for this. I think it's a little easier to do in the Web interface. We don't need to do it in Mass, so we don't need to worry about scripting it. We're gonna go pull up the vault Web interface,
and I'm gonna go ahead and grab the route token as well. So I can authenticate with that Web interface and not have any permissions problems, because I can do everything now from here. Jump into the access section and you'll find entities. There are no entities, but we're going to create the entity
we're going to create. James Bond is going to be the entity.
Let's give it that policy of the gadget user right. We want to make sure, regardless of James Bond logs in which of those Loggins he uses, we want to make sure he has access to all the good gadgets. So we're going to create that.
Then we're going to go ahead and add an alias and this aliases it's gonna be coming from the user passed back and what we know to J. Bond double 07 to make that one of the aliases.
and then let's add another
alias. So look at the James Bond entity. Here's the alias the J Bond. Let's add another one for the James dot bond,
and that's also from the user pass off back end. And so what it's doing here under the covers is creating an alias saying, Here's the I. D. This is the entity I D. This is the log in i. D. And it's mounted Visa VI this particular back end because in this user passed back end,
every account does have a unique I D.
And that's how it's bringing the three things together. So the next step we want to create a an internal group, we're going to call this the Secret Agents Group,
and we want to give this a policy that allows them to do the intel upload. So anybody who belongs to the Secret Agents group will have the right to upload intelligence that they get, and we're not going to associate this with any additional groups to kind of get that groups of groups.
But I do want out of the gate
associate the James Bond entity with this group.
So here you can see we've created the group. This is the member. If I drill into the member, sure enough, it's the James Bond entity, and then he has to aliases J Bond, Double 07 and James dot bond. So well, hop back over to the command line now
and let's log in as James dot bond.
We're gonna be using user pass method for log in, and your name is going to be James dot bond in the password is going to be shaken from the famous, shaken, not stirred line.
Now I'm authenticated. So let's just take a pause here and examine the policies that this authentication token that we let we see appear is associated with Has the default policy It's with Dr No. Do you remember when we were creating it? That was the default
Paula series. You say that was a policy. We wanted to associate it with Onley, the James dot
bond user name we used J Bond Double 07 We associated that with gold. I that is not appearing as a policy here if you think about that tree from the prior lecture and how policies get inherited.
But it is part of the gadget user, because the James Bond entity was associated with the gadget entity
Excuse me associate with the get a user policy. And similarly, the James Bond entity was a member of the Secret Agents group, and anybody who belonged to the Secret Agents group received the Intel upload policy.
What I would like to do now, instead of issuing actual different vault right and read commands, I'm going to use a particular token sub command called capabilities. And this is really good. When you're exploring as a token, you want to know what are the capabilities associated with a token,
and this will help and evaluate all the different policies associate with that token
to see what we can do. So let's look a secret data doctor. No. Okay, that's read. That makes sense.
Let's look at agent you intel.
We can create an update. We talked about that. It's not a read. It's a right on Lee type of thing. One way street. I consent intelligence to M. I six Visa vee vault.
But what about gold? I,
ah, deny. Why? Because we're not J bond. Double 07 were James dot bond.
we did create a policy that would allow us to
update Agent Intel regardless of the mission. Right? So even if we because we are a member of the Secret Agents group, we do have the right to provide Agent Intel to the GoldenEye mission,
Does this make a heck of a lot of sense in real world? Not really. But I hope you understand the concepts and how they come together in terms of policies and the hierarchy of dependencies that get issued based on the particular logging you get on a roll up to entities and groups.
And I look forward to seeing you in the next lesson where we've dive into some more of the advanced capabilities, evolved policies