Basic ACL Policies

00:02

in this overall module, we're going to be discussing access management involved in a variety of capacities. We're going to talk about defining who could do what in controlling that and organizing it using policies were going to deal with situations where use their authenticates from different sources. But we want to consolidate that into a single identity.

00:22

We're gonna take advantage of organizing various policies, entities and users by using groups and groups of groups. And finally, we're going to take advantage of some powerful capabilities in regards to controlling who can do what. By using policy templates

00:41

in this specific video, I'm going to introduce you to the concept of policies. Policy files will do a little independent lab. You'll get to do some activities yourself, and then we'll review my particular solution for that lab activity.

00:56

So what is evolved policy? You've heard of role based access control where you define who could do what and you logically group ah, selection of capabilities

01:04

and put them into a role. While a policy is the same thing, there's certain capabilities. You define those capabilities and individuals get assigned to multiple different policies, and as a result, they can interact with vault in different ways. In different capacities. Every single authentication token

01:23

has at least one policy right, a single roll. And that is the default policy.

01:29

Un Coincidentally, it is the default policy, and everybody gets that by default.

01:34

There's another policy that comes out of the box when we were exploring the depth server. This is the route policy. This policy could do everything you really don't want a lot of accounts, entities or individuals operating and authenticating with vault, having that route policy assigned to them. Be very

01:53

tight with that,

01:55

especially in a production environment. As you're deciding your policies. Keep in mind the principle of lease privileges.

02:01

You want every account, every authentication, token process user to be able to do what they need to do. But you don't want to over quick them and let them do more than they need to dio

02:13

this way. You're not creating too many accounts in case one gets compromised or multiple get compromised. That have the ability to do things that they really shouldn't be doing. And therefore the bad actor can cause undue damage because they're using these compromised accounts,

02:29

and those accounts have been equipped with capabilities way more than they need.

02:34

So the default policy being associated with every token provides certain select, narrow set of capabilities. But beyond that, by default,

02:43

every user is denied from doing everything right. Route could do everything. Default can do a few things. And unless you belong to additional policies, you can't do a lot more than default

02:55

before diving into the syntax that policies air to find in what are the big main parts and themes that that syntax is gonna leverage It all starts with paths.

03:06

Early on, we were interacting with vault, using curl to get a feel for that rest. Ap I We also looked at the A P I explorer and oftentimes, when were even using the seal I interface, it's all about paths. They could be secret slash data slash some key.

03:23

It could be off slash particular off method slash

03:28

users. Right? We've interactive these kind of things. So policy starts by saying, at this particular path,

03:35

I'm going to define these particular capabilities. I'm gonna allow a user perform, read operations and retrieve data and information. Maybe will be able to create things, and often it's gonna go hand in hand with giving them the ability to create and update. Of course, you can delete giving the ability to remove. And then there's another capability, which is deny.

03:55

And so on the slide, you can see we have the example path secret slash data slash name. If we define a policy secret slash,

04:04

that's going to take precedence. And the capabilities we define there are going to take precedence over if we defined a different policy on secret slash data slash name because it's deeper in the structure.

04:18

But however we may say, Okay, we want to allow everybody to read secrets and data, But then we want to create a different policy and deny the ability to perform a read operation on secret data name. So we're overriding policies that were set at a lower level, a little more liberally and

04:39

really locking down

04:40

the particulars in this case of a secret called name. So let's jump over to the terminal and see this all in action.

04:48

First things first.

04:49

We want to start up the Dev Server. If you have it running from prior lessons, police kill it and let's just give it a fresh start

05:00

Okay, We're up and running there

05:02

with the death server running. Don't forget to go ahead and export the vault address and then let's move ahead and log in using the route token associated with our server. And this is printed in the output of the server when we started it up.

05:20

Okay, you can see immediately. We have a policy called route. This policy allows us to do a lot of stuff, Go of all policy list. I want to be able to see what are all the policies. And we have the default policy which pretty much every token is going to be associated with.

05:38

And we have the route policy, which really can do everything. Have you ever want to get additional information about the policy? Now that we know the names, you can run the vault policy sub command,

05:47

run, read And let's say default here, it's gonna print out a bunch of information which is defining the default policy. Right. I'm gonna walk through this. It is perhaps a helpful sort of source of reference as you're starting to get to understand the vault hash corpse in tax language and how policies work

06:08

capabilities here defined.

06:09

It's a pretty intuitive set up, but it's a great place to reference. And of course, you can always run the vault policy Dash H Command to get more help on the policy Subcommander vault and understand how to interact with vault and manage policies through the command line. So let's hop over to the get hub page for a second.

06:30

And you could see here I've dove into the 05 access management subdirectory, and we have the vault policy documentation straight from Hash Corp This is a great reference for you to review and read. If you need additional information on the syntax. Harry talks about the path, the capabilities. This is a good overview. You just a very simple ones.

06:49

But take a look at some of this more advanced capabilities with policies

06:53

using the star, which is a wild card, right. Using the glob character, you can play around with a loud parameters so restricting in addition to saying, here's what you can do as far as performing operations creating reading, here are the particular parameters that you can interact with to really lock it down.

07:12

Really wanted to make sure, however, toe highlight the glob as well as the plus. The plus is a generic way of instead of using the glove for a wild card because the glob can only be your last character on the policy path, and it's a wildcard for everything in any character. Beyond that, the plus

07:30

is basically saying, If you've organized your secrets in a particular manner,

07:34

the pluses could be any particular subdirectory in that particular path. So in this case, Secret plus Team B means any path, so it could be secret. Dash

07:48

data team be. It could be secret dash metadata, Dash, Team B or, if we wanted to go and use two layers of secrets, they could be secrets Food Bar, Team B. But Secret

08:01

Food Team B would not work in this particular path. But if you had them both together in the same policy than somebody could access Secret Food Team B or secret food slash bar slash team B.

08:16

So I hope that makes sense and you have a link to this, and you can definitely reference it because we're going to do a little independent lab activity. We're going back to the get home page. Let's talk about this lab activity a bit more continuing with the theme of James Bond. We want to create a special policy called Intel Upload. And what this does is

08:35

it will allow our secret agents to

08:37

create keys and secrets in particular areas of vault. If

08:43

Agent Intel is the name of the key, and it is in the second segment of the path.

08:48

So, for example, you're gonna go ahead and you're gonna create that policy. You're gonna create some secrets on the following paths. Secret data, Doctor. No doctor, no being one of James Bond's famous missions that we're gonna have secret data, Doctor. No dash Agent Intel. This would be an area that we want to make sure

09:07

James Bond can write key value pairs to,

09:09

and we want to make sure that the Intel upload policy enables him to do that. Continue with the example. We've got gold and I secret data. GoldenEye, Agent Intel. That's an area that we want to make sure James Bond can also upload information to. But secret Agent secret data agent Intel directly

09:28

is not an area that we want to allow James Bond to upload his secrets to. It has to be within a sub segment. That is for the particular missions. And once you've created the policy and you've created some secrets that those different paths, you're gonna go ahead and you're gonna enable the user pass

09:46

authentication method

09:48

and create a user called James dot Bond

09:50

and making sure to have that user associated with the Intel upload policy. And you can do this through the Web. You I or you could do this from the command line. Or you could do this from the Web. AP I itself that the curled a p I Finally we're going to authenticate with vault

10:07

as this user account with the user pass right, James Bond,

10:11

and we're gonna execute a variety of commands. And you're going to do this yourself. And this is how we're making sure. Did we correctly create the policy in a way that I'm going to be denied

10:24

all these activities? They're gonna fail? And then secondly, there's a suite of commands here that should all pass because you can do the different stores and update the keys for the different missions. As you jump into the lab, don't hesitate to take advantage of the policies, documentation by all means. This is an open book test.

10:41

This is going to be the end of this video, but is really one lesson.