Feature Brief: Understanding Accounts, Roles, and Privileges

Introduction

Managing the day-to-day operations of the VMware Cloud on AWS SDDC should be relatively easy, especially if you’re already familiar with how permissions work in vCenter. However, there are some account and role differences between on-premises deployments and cloud deployments that vSphere administrators should understand and take into consideration.

Amazon Web Services

One of the credentials you’ll need for operating VMware Cloud on AWS is an AWS account. You will use this account to create a VPC in the region in which you wish to deploy your SDDC, followed by subnets within the Availability Zones (AZ). This also lets you integrate paid AWS services such as Amazon S3, Amazon EC2, etc. Within the SDDC Deployment wizard, you will link this account to your VMware Cloud on AWS service. While Amazon hosts this account, you own and manage this account through the AWS Services Console.

A screenshot of a cell phone

Description automatically generated

VMware Cloud Services

Secondly, you’ll need a VMware Cloud Services account. This account allows you to access the VMware Cloud on AWS SDDC console, as well as other VMware Cloud services such as VMware vRealize Network Insight Cloud, VMware vRealize Log Insight Cloud, and VMware HCX to name a few.

The VMware Cloud Services Console is how you will manage the organization, billing, identity, and access to VMware Cloud on AWS. VMware hosts this account, and you own and manage it through the Cloud Services Console.

A screenshot of a cell phone

Description automatically generated
Within VMware Cloud Services there are two types of roles

  • Organization Roles give users access to the Cloud Services Console
  • Service Roles provide different levels of access to various components within the Cloud Services you’re subscribed to.

VMware Cloud on AWS accounts are based on an Organization Name and ID; the very first user will need a valid MyVMware account. This account is used to create an Organization (Name and ID), and the initial user account used is setup as the Organization Owner.

Within the organization, there are two types of Organization Roles

  • An Organization Owner can add, remove, and modify users as well as access VMware Cloud Services. There can be multiple owners.
  • Organization Members can access Cloud Services, but cannot add, remove, or modify users.

Within the Cloud Services Console, you can assign specific service roles to organization members. For example, the VMware Cloud on AWS service allows you to assign Administrator, Administrator (Delete Restricted), NSX Cloud Auditor, and NSX Cloud Admin roles.

A screenshot of a cell phone

Description automatically generated
Just as it is a best practice to limit access to the vSphere Client, it is also a best practice to limit access to the Cloud Services and SDDC console. Users requiring access to the vSphere Client do not necessarily require access to the Cloud Services and SDDC console. Only users who are responsible for the entire SDDC or NSX components (VPN, Firewall, etc.) should have access.

It is best practice to configure Hybrid Linked Mode and grant access through security groups and vCenter roles.

vCenter Single Sign-On for VMware Cloud on AWS SDDC

This is both hosted and managed by VMware. When you first deploy your SDDC, only one user has access to vCenter by default – cloudadmin@vmc.local. A password for this account is randomly generated and any user with SDDC console access can gain access to this password.

A screenshot of a cell phone

Description automatically generated
This password can be changed through the vSphere Client, but understand that it will not be updated in the default vCenter Credentials window.

vCenter Single Sign-On from an On-Premises SDDC

This is both hosted and managed by the customer. The users in your single sign-on domain can be provided access to VMware Cloud on AWS after Hybrid Linked Mode is configured.

vCenter Roles

From an administration perspective, your on-premises vCenter environment likely has Active Directory security groups assigned to the vCenter Administrator role, and administrators have access to administrator@vsphere.local. This is not the case within VMware Cloud on AWS – there will be no access to the default Administrator role or administrator@vsphere.local.

There are two new admin roles:

  • CloudAdmin Role: The CloudAdmin role has the necessary privileges for you to create and manage workloads in your SDDC (virtual machines, resource pools, datastores, and networks). However, you cannot access or configure certain management components that are supported and managed by VMware, such as hosts, clusters, and management virtual machines.
  • CloudGlobalAdmin Role: The CloudGlobalAdmin role is associated with global privileges and allows you to create and manage Content Library objects, Tagging, Storage Profiles, etc.

A new vCenter group, CloudAdmin, is granted the CloudGlobalAdmin role on all global permissions. The CloudAdmin group is also granted the CloudAdmin role privileges on select objects such as the Workloads Virtual Machines Folder and Resource Pool, vSAN Datastore, etc.

Because cloudadmin@vmc.local is part of the CloudAdmin group, it has all of the necessary privileges you need to manage the environment. This is also the account you will use to add an Identity Source and configure Hybrid Linked Mode. During the configuration of Hybrid Linked Mode you have the option of adding AD groups to the CloudAdmin role.

Additional groups can be added later, however any on-premises users not added to that group or role will have the No Access role by default. There are a few other standard roles that will be familiar to you.  You can also create custom vCenter roles, so you can have greater control over what actions your users can perform on which resources.  Learn more about in the Feature Brief on vCenter Roles.

 

Filter Tags

General VMware Cloud on AWS Document Feature Brief Overview