Introducing Security Model of VMware vSphere
This article introduces you the basic model and terminologies in vSphere security management, for example, privileges, permissions, roles, and how they are related to each other to secure vSphere. It helps you to better manage the vSphere and program the vSphere API. Much of the content is based on my book VMware VI and vSphere SDK by Prentice Hall.
In vSphere, the security model consists of three types of components: privileges, roles, and permissions.
Time to learn how to "Google" and manage your VMware and clouds in a fast and secureHTML5 App
A privilege is the basic individual right required to perform an operation. It is statically defined and never changes in a single version of a product. Given the many operations in VI, there are many privileges (for example, the privilege to “power on a virtual machine”). These privileges are represented as strings separated by dots, such as VirtualMachine.Interact.PowerOn.
The operations and privileges are not one-to-one mapping. Many operations do share common privileges like System.View. Therefore, there are many fewer privileges defined than methods. In some exceptional cases, a method requires different privileges depending on the target it operates on and the nature of the operation. The CloneVM_Task() method, for example, requires VirtualMachine.Provisioning.Clone for cloning from one virtual machine to another, VirtualMachine.Provisioning.DeployTemplate for cloning from a template to a virtual machine, and so on.
The role groups privileges from a user’s perspective. A role is normally named and defined for a group of people who have common responsibilities in the system (for example, administrators). Each role can include zero to multiple privileges. The extreme cases are the predefined “Admin” roles, which by default, includes all the privileges and the NoAccess role, which includes no privileges.
The permission is the actual access-control rule that associates a user or user group with a specific role on a managed entity. The rule could be propagated and applied on the descendent managed entities as well. You could group managed entities with similar requirements on access control under a container entity, such as a Folder.
vCenter doesn’t create new users or new groups. You must create them in VC server’s Windows Domain. On the ESX server, you can create and manage users in the console OS with Linux commands, or you can use the HostLocalAccountManager managed object. Use the UserDirectory managed object to retrieve them from the system.
Permissions are the associations of roles with privileges on a given managed entity. ManagedEntity may have multiple permissions, but it may have only one permission per user or group. When logging in, if a user has both a user permission and a group permission (as a group member) for the same entity, the user-specific permission takes precedence. If there is no user-specific permission but two or more group permissions are present, and the user is a member of the groups, the privileges are calculated as the union of the specified roles.
Managed entities may be grouped together into a “complex” entity (for example, a Datacenter, ComputeResource, or ClusterComputeResource) for the purpose of applying permissions consistently. A Datacenter’s child objects are the root virtual machine and host folders. A ComputeResource’s child objects are the root ResourcePool and HostSystem. A ClusterComputeResource has only the root ResourcePool as a child object.
Child entities in a complex entity are forced to inherit permissions from the parent object. When you query the permissions on child objects of complex entities, different results may be returned for the owner of the permission. In some cases, the child entity is returned as the object that defines the permission. In other cases, the parent from which the permission is propagated is returned as the object that defines the permission. In both cases, the information about the owner of the permission is correct, because the entities within a complex entity are considered equivalent. Permissions defined on complex entities are always applicable on the child entities, regardless of the propagation flag.
Privilege, role, and permission are represented by AuthorizationPrivilege, AuthorizationRole, and Permission data objects, as shown below.
Figure 1 AuthorizationPrivilege, AuthorizationRole, and Permission
The AuthorizationPrivilege’s privId is a unique string consisting of privGroupName and name with a dot in between (for example, System.View). These unique strings can be included in the array of privileges in the AuthorizationRole. That is how they are associated.
The AuthorizationRole is identified by the roleId, an integer that is referenced in the Permission object. You can think of the roleId in the AuthorizationRole as the primary key, and the roleId in Permission as the foreign key in SQL databases.