Information Technology Reference
In-Depth Information
later in the section “Authenticating Users with Single Sign-On,” vCenter can also leverage a
directory such as Active Directory as a centralized security authority. Prior to vSphere 5.1, the
Windows-based vCenter Server itself was a member of Active Directory, and permissions were
leveraged through this connection. From vSphere 5.1 onward, the architecture has signii cantly
changed with the introduction of vCenter Single Sign-On (SSO). We'll explain more about SSO
later in this chapter. This is the i rst key difference in managing permissions for environments
that don't use vCenter Server versus environments that do.
The second key difference is the level of granularity of the roles and privileges available
in each environment. To explain this difference, we must i rst discuss and dei ne roles and
privileges.
For environments that don't have vCenter Server, or where the administrator chooses to have
users authenticate directly to the ESXi hosts to perform management tasks, it is important to
start with a discussion of the security model.
In the vCenter Server/ESXi security model's most basic format, users or groups are assigned
to a role that has privileges. The user-role-privilege combination is then associated with an
object in the inventory as a permission. This means there are four basic components to the
vCenter Server/ESXi security model:
User or Group A user is an authentication mechanism; a group is a way of collecting users.
In earlier sections of this chapter, we showed you how to manage users and groups and how
ESXi can leverage either local users and groups or users and groups from Active Directory.
Users and groups form a basic building block of the security model.
Privilege A privilege is an action that you can perform on an inventory object. This would
include allocating space in a datastore, powering on a VM, coni guring the network, or
attaching a virtual CD/DVD to a VM.
Role A role is a collection of privileges. ESXi comes with some built-in roles, as we'll show
you shortly, and you also have the ability to create your own custom roles.
Permission A permission allows a user or group to perform the activities specii ed by a role
assigned to an inventory object. For example, you might assign a role that has all privileges to
a particular inventory object. Attaching the role to the inventory object creates a permission.
This modular security model provides a great deal of l exibility. vSphere administrators can
either use the built-in roles provided with ESXi or create custom roles with custom sets of privi-
leges and assign those custom roles to inventory objects in order to properly re-create the correct
set of abilities in the virtual infrastructure. By associating roles with users or groups, vSphere
administrators need to dei ne the role only once; then, anytime someone needs those privileges,
all the administrator needs to do is associate the appropriate user or group with the appropriate
role. This can really help simplify the management of permissions.
An ESXi host has the following three default roles:
No Access The No Access role works as the name suggests. This role prevents access to an
object or objects in the inventory. The No Access role can be used if a user was granted access
higher up in the inventory. The No Access role can also be used at lower-level objects to pre-
vent object access. For example, if a user is granted permissions on the ESXi host but should be
prevented from accessing a specii c VM, you could use the No Access role on that specii c VM.
Read-Only Read-Only allows a user to see the objects within the vSphere Client inventory.
It does not allow the user to interact with any of the visible objects in any way. For example,
Search WWH ::




Custom Search