Lesson 2 - Configuring Roles and Permissions
Configuring Roles and Permissions This lesson discusses configuring roles and permissions and covers the following: Defining a permission Describe rules for applying permissions Create a custom role Create a permission
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
Already have an account? Sign In »
14 hours 13 minutes
Configuring Roles and Permissions This lesson discusses configuring roles and permissions and covers the following:
Defining a permission
Describe rules for applying permissions
Create a custom role
Create a permission
Hello, I'm Gene Pompilio. Welcome to Cyber Eri were on module nine lesson to now for the virtual ization class, and this lesson will be talking about considering rolls and permissions.
There's a lot of
really interesting ways that you can set up your environment to give
different users or different groups of users the kinds of permissions that you wish and being able to very tightly control what they're allowed to do, what they're not allowed to. D'oh.
So we'll start off by defining what a permission is.
And then we'll look at some of the rules for how provisions get applied will go through several examples there,
and then we'll see what's involved in creating a custom role,
creating a permission itself
finish up with doing Labs 14 and 15.
Okay, so we start off with the Access Control overview.
We have three different or four different things. Think about here. We start off with our privilege
and a privilege is some kind of action that a role or user or a group of users can perform.
And as you'll see when you look at the
the interface for defining the privileges there are, I think it's over 300 different actions that could be
assigned to AH, user or role. We have a lot of different granular control over what someone's allowed to do, what they're not allowed to. D'oh!
The role, therefore, is a collection of privileges.
Uh, you know, you could say someone's allowed to power of'em on someone's allowed to power VM off. Someone can allocate storage. Someone can change a network interface. These air just samples of the kinds of
privileges that can be grouped together to perform to create a role.
The object is the target of the action,
and the object could be anything in your inventory data center,
ah folder data store, a network, a virtual machine
host, a cluster,
a lot of different options for what the object can actually be.
And then the users and the groups are who actually can perform the actions that were defined as permissions or as a collection of permissions as a role.
Yes, excited comes with three different roles that air predefined. We have the administrator,
a read only roll and one that is set up for no access. This is a pretty decent collection of starting roles to work with
the administrator role in particular. If you have active director integration, which we've talked about in a couple of different sections here,
then you're SX. Add Mons Group within active directory contains all of the administrators if you're using,
uh, active directory to do your authentication.
Otherwise, you can still log in directly to your host as route and be an administrator there. So you got several different ways to
used the administrator function within the SX. I host,
uh, so we've got these three built in role. So these air your your system rolls.
And there's also some other sample roles that get created
when you install yes X I,
and you'll see those when you look at the screen, where you're allowed to define the role
and then you have custom rules where you create the role to have any kinds of permissions that you wish.
And as I mentioned, there's several 100 different
individual permission types that you can associate with a role. So you get a lot of control over what a user or group of users is allowed to. D'oh!
All right, So if we go to the administration
uh, area of the center.
That's pretty much should be at the top row of your interface. You'll see a little icon that looks like three little people that your rolls I can.
And so, for instance, I can create a roll call Virtual Machine Power user.
When the interface pops up, you'll see that you can add a roll, and on the right side you'll see your entire list of available categories.
So underneath the privileges area,
I can select a category of data store.
Each category can be expanded or contracted by clicking the little little plus sign button.
When it's expanded, it will be a It'll be a minus
when you when it's not expanded, it will be a plus sign
when you select a check box within a category. If I select this check box, everything within that category will get selected, just like you would expect it to work.
Or you can select individual items within a category if you want to be a little bit more precise about what permissions you're providing for this role.
So in this case, I want to have a virtual machine power user
within the day store category. Want them to be able to browse the data store. They're not allowed to allocate space. There's no check box there, so it's a very simple interface to use. Very intuitive.
As I mentioned on a per object basis, I can assign this particular role if I want.
If I say I've got a user
named Jeff and I want to make Jeff of the Empower User, I put him in that group. And then all these different objects can have that particular role assigned.
So everything from the data center down to individual V EMS and anything in between.
When you select an object in your inventory, you'll notice that there's a permission tab
when you select the permission tab. That's when you can see what permissions already defined for that object based on the rolls or groups that are already created.
And then you can also sign permissions
so I can just select the user that I want to work with.
Select the role that I'd like that user tohave from the available choices in the drop down menu.
And then you get the option to propagate
the permissions that were defined for that role to child objects,
and we'll see why that matters and what that really means. Way. Talk about how the permissions get applied.
So for applying permissions, we have to think about
child objects, for instance, and this example
I've got a user named Bill
Bills in two different groups.
He's in Group one with a user named Jane. He's in Group two with a user named Sally,
in this example Bills. It has the administrator role,
and this is assigned to the lab data center.
So that means everything underneath the lab data center, which includes these two folders and these four v EMS
bill would have the administrator role. It's pretty basic concept if
sorry if the propagate the child objects to check boxes checked, which is by default.
And in most cases that's what you want. I want to be able to say, Build the administrator for the entire data center. However, I can still have control underneath this to to restrict some of Bill's permissions in this case, the production 01 server. I don't want building any access that to that whatsoever. So, Aiken,
give him the no access permission here
now, Bill or no access role. Rather now, Bill can't have any type of access whatsoever here. But he still has administrator access to the folder, the contents of the folder, this folder and that V. M.
So this is, ah, interesting way that you can break the permissions apart
into different possibilities.
Let's look at another example where the permissions get combined.
In this case, I'm going to say a Group one.
We'll give this a, uh, VM power on
We'll put that at the data center level,
and then Group two
can take snapshots
also at that same data center level.
Now, since Bill's a member of both groups, has permissions get combined here?
So that means for the entire data center.
Bill is a member of Group One can power on any of these the EMS, and he's also
allowed to take snapshots as a member of a group number two pretty basic idea
and a great way to control
within your inventory what kinds of permissions users are allowed to have.
So let's look at another example
and this one
we'll say that Group One same membership for the groups.
I will say that Group one has administrator privileges here.
Just write that down his admin
and then for this particular VM,
we'll say that group, too,
is read only. So Bill, as a member of Group One, gets administrative privileges for everything under that data center, with the exception of this VM, because because of his membership in Group two, he has read only access to this. V M
still has admin for everything else.
Read only for this one
so I can combine
permissions and well restrictive permissions lower in the hierarchy. Here, lower in the inventory can override those that are higher up.
So I could make this more restrictive, even though you would think if I've got administrative privileges, it should be for everything. From that point down, you have the control to restrict that somewhat.
Uh, okay, so we'll do another example here. I'm gonna add group too
back to the data center,
and I'll say that one's allowed to do snapshots
at that level.
And then I can say that
as an individual now, not as a member of a group he has read on Lee.
So how's that gonna work?
If Bill's a member of Group one, he's also a member of group, too, so that means bill has administrator privileges for everything in this
inventory underneath the data center, as as a member of Group One
as a member of group to Bill would have
snapshot abilities for all these beyond these four v EMS.
But now I've created eight. Another permission for Bill is an individual which overrides his group membership permissions
In this particular scenario,
thes two permissions will effectively go away because the read only permissions that I signed to build at the data center level would apply to everything below.
So the more restrictive permission takes precedence over the less restrictive ones which were previously there.
Okay, So when you're creating a role,
one of important things to think about is on Lee assigning the permissions pledges rather the privileges that the role requires. We want to follow the principle of Lee's privilege here.
So in the power users a scenario, Or if you were a backup operator
or maybe someone who can create the EMS but cannot power them down, it cannot delete them. You could see all the different possibilities for assigning different members of your organization on Lee. Those permissions that they're required to have to do their job and nothing more.
So that's That's an important consideration to think about when you're designing the way that your your organization's permissions will work
based on the users themselves and what groups there, right?
the next thing to think about is
creating a permission.
So just like we can create a role, we can define a permission as well,
and you get to pick from the same
items that are available in the list. And you can use that permission in any one of the roles, which can then be assigned to users or groups of users.
After your next task is to do Labs 14 and 15
and last 14 you'll get to exercise the different options for creating permissions for different users,
and we'll have 15. You'll be able to create a custom rule,
something similar to what we see here with the virtual Machine power user
and that will allow you to see how that works within the V's fair environment.
So, to recap,
we talked about what permissions are, what a privilege is, where role is,
objects that users and groups and how those all fit together.
We also know that we have are three building rolls.
Yes, X admin is automatically get administrator privilege.
And then we talked about what those objects are
so that I create the role. I sign it to an object,
and then I can assign permissions to those objects within the inventory for V center.
Okay, that concludes lesson to thank you.