Managing XenServer Administrators

Separating Administrative Responsibilities

Recommendation:

We recommend providing administrative access to XenServer through its Role Based Access Control (RBAC) feature. The RBAC feature lets you use the Active Directory accounts for administrators and assign levels of access to these accounts (through roles). Assigning role-based access lets you troubleshoot and monitor administrative activity through audit logging.

Ensuring each administrative tier is available only to appropriately authorized people helps avoid unintentional and intentional unauthorized changes, which can potentially affect the stability of physical hosts and VMs and the associated cost of resulting system outages.

If not in place already, consider separating administrative responsibilities for your virtualized environment, possibly based on the ones suggested by the predefined XenServer RBAC roles, and then defining which RBAC roles or people will be associated with which responsibilities.

The product documentation provides detailed information about configuring RBAC.

Recommendation:

• We recommend, before deploying RBAC, familiarizing yourself with the RBAC feature and understanding the division of responsibilities between the roles. Make sure you understand what tasks each role can perform and the data of which each role has visibility.

  Do not assign roles solely based on their titles.

• We recommend matching the assignment of roles to your organizational security policy.

• We recommend carefully reviewing access policies and roles because access to the hypervisor can enable access to key infrastructure components, such as network switches and firewalls, as well as sensitive hosted applications and workloads.

• We recommend, when making RBAC assignments, carefully reviewing the RBAC roles assigned to administrators in relation to the VM snapshots.

  Any administrator assigned an RBAC role of Pool Admin, Pool Operator, or VM Power Admin can start a snapshot taken from any VM in the pool (for which they have that role).

• When using RBAC, it is important to remember that a root account (that is, the local super-user account) still exists.

  We recommend, in accordance with your organizational security policy, that you keep the root account password secure. You may want to store the root account password in a physically secure location with restricted access. (For example, you could store the root account password in safe or safety deposit box, where nobody has routine access, but a suitably authorized person could retrieve the password in the event of an emergency).

There are two approaches to implementing XenServer administrative accounts with RBAC:

• You could use the same account for XenServer administration as you use for other company activities (for example, email, network access, and so on). This is usually undesirable as it increases the opportunities for the account to become compromised and also increases the scope of potential impact if the account is compromised.

• You could create separate Active Directory accounts with a different user name solely for XenServer administration.

Recommendation:

• We recommend that when you implement RBAC you consult your organizational security policy to determine if you should create separate Active Directory accounts that are only used for XenServer administration. If you have don’t have such a policy, We recommend that you create separate accounts for XenServer administration.

• We recommend considering business continuity when using the RBAC feature.

  Take steps to ensure that you can still access XenServer if the person assigned the Pool Admin role is no longer available. This might involve ensuring:

  • More than one person is assigned an individual Pool Admin accounts

  • The root account password is stored in a secure restricted location with protocols to access it in the event of an emergency in accordance with your organizational security policy

• We recommend that when you implement RBAC in your environment you be aware that you are ultimately trusting the Active Directory administrator to control access to your environment.

  • Whoever has the ability to control Active Directory accounts also has the ability to access those accounts and by extension access the XenServer environment

  • The Active Directory administrator can inadvertently create a denial of service situation by unwittingly disabling accounts (for example, if the organizational security policy changes and the administrator changes the properties of the Active Directory accounts)

  Consider how you will gain access to the XenServer environment if the Active Directory administrator inadvertently disables the XenServer Pool Admin account, and there is only one such account.

• We recommend that you do not share RBAC accounts. If you do, your ability to trace the owner of changes in the audit log will be compromised.

Role Based Access Control (RBAC) Overview

XenServer’s Role Based Access Control (RBAC) lets you assign predefined roles, or sets of XenServer permissions, to Active Directory users and groups. These permissions control the level of access XenServer users (that is, people administering XenServer) have to servers and pools: RBAC is configured and deployed at the pool level. Because users acquire permissions through their assigned role, you simply need to assign a role to a user or their group.

Using Active Directory accounts for XenServer user accounts, RBAC lets you restrict which operations different groups of users can perform which reduces the likelihood of inexperienced users making disastrous, accidental changes. Assigning RBAC roles also helps meet compliance requirements by preventing unauthorized changes to your resource pools. To facilitate compliance and auditing, RBAC also provides an Audit Log feature and its corresponding Workload Balancing Pool Audit Trail report.

RBAC depends on Active Directory for authentication services. Specifically, XenServer keeps a list of authorized users based on Active Directory user and group accounts. As a result, you must join the pool to the domain and add Active Directory accounts before you can assign roles.

Local Super-User

The local super-user, or root, is a special user account used for system administration and has all rights or permissions. In XenServer, the local super-user is the default account at installation. The local super-user is authenticated by XenServer and not an external authentication service. This means that if the external authentication service fails, the local super-user can still log in and manage the system. The local super-user can also access the XenServer physical server through SSH if SSH is enabled.

RBAC Roles

XenServer comes with six pre-established roles that are designed to align with different functions in an IT organization.

• Pool Administrator (Pool Admin). This role is the most powerful role available. Pool Admins have full access to all XenServer features and settings. They can perform all operations, including role and user management. They can grant access to the XenServer console. As a best practice, We recommend assigning this role to an extremely limited number of users.

  Note: The local super user (root) always has the Pool Admin role. The Pool Admin role has the same permissions as the local root.

• Pool Operator (Pool Operator). This role is designed to let the assignee manage pool-wide resources, including creating storage, managing servers, managing patches, and creating pools. Pool Operators can configure pool resources. They also have full access to the following features: High Availability (HA), Workload Balancing, and patch management. Pool Operators cannot add users or modify roles.

• Virtual Machine Power Administrator (VM Power Admin). This role has full access to VM and Template management. They can choose where to start VMs. They have full access to the dynamic memory control features and the VM snapshot feature. In addition, they can set the Home Server and choose where to run workloads. Assigning this role grants the assignee sufficient permissions to provision virtual machines for VM Operator use.

• Virtual Machine Administrator (VM Admin). This role can manage VMs and Templates and access the storage necessary to complete these tasks. However, this role relies on XenServer to choose where to run workloads and must use the settings in templates for dynamic memory control and the Home Server. (This role cannot access the dynamic memory control features, make snapshots, set the Home Server or choose where to run workloads.)

• Virtual Machine Operator (VM Operator). This role can use the VMs in a pool and manage their basic lifecycle. VM Operators can interact with the VM consoles and start or stop VMs, provided sufficient hardware resources are available. Likewise, VM Operators can perform start and stop lifecycle operations. The VM Operator role cannot create or destroy VMs, alter VM properties, or server resources.

• Read-only (Read Only). This role can only view resource pool and performance data.

For information about the permissions associated with each role, see the product documentation.