Control Policies Technical VMware Cloud on AWS

VMware Cloud on AWS: Providing Customers More Flexibility with Role-Based Access Control in vCenter

With the latest 1.7 release of VMware Cloud on AWS, customers have more control over the level of access of individual vCenter users in their organization. Take a deep dive into the different permissions available and how to delegate granular management functionality.

.terminal {
border: 1px grey dashed;
padding: 10px;
background-color: whiteSmoke;
color: black;
font-family: “Lucida Console”, Monaco, monospace;
font-size: small;
line-height: 1.5;
}

VMware Cloud on AWS: Providing customers more flexibility with role-based access control in vCenter

A very common ask that we get from our customers is to have the ability to have more control over the level of access they can offer their vCenter users in VMware Cloud on AWS. Cloud administrators want to restrict access to the cloud inventory and the actions that can be performed in vCenter for the different users in their organization.

Cloud Administrators

VMware Cloud on AWS currently offers the CloudAdmin role out of the box to allow customers to manage vCenter objects and for vCenter administration. A user with the CloudAdmin role can modify or view vCenter objects as well as delegate access to others in the organization to be cloud administrators. However, while this role offers the highest permissible level of access for our customers, often cloud administrators don’t always want to make every other user in their organization a CloudAdmin, but rather offer users a restricted subset of the privileges.

Flexible Permissions Model for Role-Based Access

With the latest 1.7 release of VMware Cloud on AWS, customers now have the ability to create custom roles from a subset of the privileges from the current CloudAdmin role to offer more granular role-based access to vCenter objects.

One such example of customization is to provide a subset of users with read-only access to VMs rather than full permissions to modify and delete VMs.

Access to the Complete Inventory Tree

Prior to the flexible permissions model, VMware restricted customers to only applying permissions for compute objects. With this new enhancement, customers will now have the ability to apply permissions at any level of the inventory tree, while still protecting the management objects. This will allow customers to run existing on-premises scripts on the cloud inventory without major modifications.

We continue to provide the compute and management resource pools for compute and management VMs respectively. However, due to added flexibility in the RBAC model, you could create VMs outside of the compute RP. While this flexibility exists, there cloud be potential resource contention issues between VMs that are created outside the Compute Resource Pool and within it as explained here. In order to limit contention across the VMs that you create, we strongly recommend that you continue to use the Compute Resource Pool as the location to create your VMs.

Automation

In terms of automation, PowerCLI is still by far the most popular tool that our customers use on a regular basis.

As indicated earlier, in order to help isolate your workloads and ensure that you don’t have contention issues across your VMs, we recommend the following:

  • From the Hosts/Clusters view, you should use the Compute-ResourcePool
  • From the VM view, you should use the Workloads Folder
  • From the Datastore view, you should use the WorkloadDatastore

To help simplify any scripts you may write against VMware Cloud on AWS, you should consider setting the following global variables which map to the specific vSphere Inventory objects that you need to specify when provisioning a new workload:

$VMCVMFolder = “Workloads”
$VMCResourcePool = “Compute-ResourcePool”
$VMCDatastore = “WorkloadDatastore”

You can also look at additional PowerCLI scripts to provision VMs to build some of your automated workflows.

Resources

Related Articles