vSphere IaaS Control Plane Identity and Access Management

As a vSphere administrator, you need privileges to activate and configure a Supervisor and to manage vSphere Namespaces. You define permissions on namespaces to determine which DevOps engineers and developers can access them. You can also configure the Supervisor with an external OpenID Connect (OIDC) provider to enable multi-factor authentication. As a DevOps engineer or developer, you authenticate with the Supervisor by using either your vCenter Single Sign-On credentials or credentials from an OIDC provider depending on what your vSphere administrator has configured for you on the Supervisor. You can access only the vSphere Namespaces for which you have permissions.

Supported Identity Providers

vSphere IaaS control plane supports the following identity providers:

vCenter Single Sign-On. The default identity provider that you use to authenticate with the vSphere IaaS control plane environment, including Supervisors and Tanzu Kubernetes Grid clusters. vCenter Single Sign-On provides authentication for the vSphere infrastructure and can integrate with AD/LDAP systems. For more information about vCenter Single Sign-On, see vSphere Authentication with vCenter Single Sign-On.
External Identity Provider. As a vSphere Administrator you can configure a Supervisor with an external identity provider that supports the OpenID Connect protocol. Once configured with an external identity provider, the Supervisor functions as an OAuth 2.0 client and uses the Pinniped authentication service to connect to Tanzu Kubernetes Grid clusters by using the Tanzu CLI. The Tanzu CLI supports provisioning and managing the life cycle of Tanzu Kubernetes Grid clusters. Each Supervisor instance can support one external identity provider.

Authentication with the Supervisor

The different roles that interact with the vSphere IaaS control plane can use the following methods to authenticate with the Supervisor:

vSphere Administrator. As a vSphere Administrator, you use vCenter Single Sign-On to authenticate with vSphere through the vSphere Client. You can also use the vSphere Plugin for kubectl to authenticate with the Supervisor and Tanzu Kubernetes Grid clusters through kubectl. For more information see Connect to the Supervisor as a vCenter Single Sign-On User.
DevOps engineer or developer. As a DevOps engineer or developer you use vCenter Single Sign-On to authenticate with the Supervisor through the vSphere Plugin for kubectl and kubectl. You can also connect to a Supervisor by using credentials from the external identity provider that is configured with that Supervisor. For more information, see Connecting to TKG Clusters on Supervisor Using an External Identity Provider.

Login Sessions with the Supervisor

When you log in to the Supervisor as a vCenter Single Sign-On user, an authentication proxy redirects the request to vCenter Single Sign-On. The vSphere Plugin for kubectl establishes a session with vCenter Server and obtains an authentication token from vCenter Single Sign-On. It also fetches a list of vSphere Namespaces to which you have access, and populates the configuration with these vSphere Namespaces. The list of vSphere Namespaces is updated on the next login, if there are changes to the permissions of your user account.

The account that you use to login to the Supervisor provides you with access only to the vSphere Namespaces that are assigned to you. To login to vCenter Server, your vSphere administrator must set the appropriate permissions to your account on one or more vSphere Namespaces.

Note: The session to kubectl lasts for 10 hours. After the session expires, you must authenticate with the Supervisor again. At logout, the token is deleted from the configuration file of your user account, but remains valid until the session ends.

Authentication with Tanzu Kubernetes Grid Clusters

As a DevOps engineer or developer you connect to provisioned Tanzu Kubernetes Grid clusters to operate and manage them. When your user account is granted the Edit or Owner permission on the vSphere Namespace where the Tanzu Kubernetes Grid cluster is provisioned, your account is assigned to the cluster-admin role. Alternatively, you can use the kubernetes-admin user to connect to Tanzu Kubernetes Grid as well. You can also grant developers access to Tanzu Kubernetes Grid clusters by binding a user or group to default or custom pod security policy. For more information, see Connecting to TKG Clusters on Supervisor Using vCenter SSO Authentication and Connecting to TKG Clusters on Supervisor Using an External Identity Provider.

vSphere Namespaces Role Permissions

As a vSphere administrator, you grant View, Edit, or Owner permissions to DevOps engineers or developers on vSphere Namespaces. Their users or groups must be available in vCenter Single Sign-On or in an external identity provider configured with the Supervisor. One user or group can have access to multiple vSphere Namespaces. Each vSphere Namespace role allows the following actions:

Role	Descirption
Can view	Read-only access for the user or group. The user or group can login to the Supervisor control plane and list the workloads running in the vSphere Namespace, such as vSphere Pods and Tanzu Kubernetes Grid clusters, and VMs.
Can edit	The user or group can create, read, update, and delete vSphere Pods, Tanzu Kubernetes Grid clusters, and VMs. Users who are part of the Administrators group have edit permissions on all namespaces in the Supervisor.
Owner	Users or groups with owner permissions can: Deploy and administer workloads in the vSphere Namespace. Share the vSphere Namespace with other users or groups. Create and delete additional vSphere Namespaces using kubectl. When users with owner permission share the namespace, they can assign view, edit, or owner permissions to other users or groups. Note: The owner role is supported for users available in vCenter Single Sign-On. You cannot use the owner role with a user or group from an external identity provider.

For information about creating an configuring vSphere Namespaces, see Create and Configure a vSphere Namespace.

As a vSphere Administrator, after you configure a vSphere Namespace with role permissions, resource quotas, and storage, you provide the URL of the Supervisor control plane to DevOps engineers and developers, who can use it to log in to the control plane. Once logged in, DevOps engineers and developers can access the vSphere Namespaces for which they have permissions across the Supervisors configured with the same identity providers that belong to a vCenter Server system. When vCenter Server systems are in Enhanced Linked Mode, DevOps engineers and developers can access all vSphere Namespaces for which they have permissions across all the Supervisors available in the Linked Mode group. The IP address of the Supervisor control plane is a virtual IP generated by NSX or a load balancer in the case of VDS networking to serve as an access point to the Supervisor control plane.

vSphere Administrator Permissions

As vSphere administrator typically your user account can have the following permissions:

Object	Permissions
vCenter Single Sign-On user	Administrators group
vSphere Namespaces user	Members of the Administrators group are granted Edit permissions on all vSphere Namespaces.

Depending on the interface that you use to interact with vSphere IaaS control plane, you can perform different operations with you granted permissions:

Interface	Operations
vSphere Client	When logged in as administrator to the vSphere Client, you can: Activate and configure Supervisors. Create and configure vSphere Namespaces with resource allocations and role permissions for DevOps engineers or developers. Role permissions on vSphere Namespaces are required for users or groups who want to log in to the Supervisor control plane through kubectl to run an manage workloads. Deploy and manage Supervisor Service on Supervisors.
kubectl	If you are logged in to the Supervisor control plane with a vCenter Single Sign-On administrator account you can: View resources in all vSphere Namespaces including system vSphere Namespaces (kube-system and all vmware-system-* namespaces) Edit resources in all non-system vSphere Namespaces, that are namespaces created through the vSphere Client or vCenter Server APIs. However, when logged in to the Supervisor control plane with an account part of the Administrators group, you are not allowed to edit any cluster-level resources, create vSphere Namespaces by using kubectl or create role bindings. You must use the vSphere Client as the primary interface to setting resource quotas, creating and configuring vSphere Namespaces, and setting up user permissions.

Interface

Operations

vSphere Client

When logged in as administrator to the vSphere Client, you can:

Activate and configure Supervisors.
Create and configure vSphere Namespaces with resource allocations and role permissions for DevOps engineers or developers. Role permissions on vSphere Namespaces are required for users or groups who want to log in to the Supervisor control plane through kubectl to run an manage workloads.
Deploy and manage Supervisor Service on Supervisors.

kubectl

If you are logged in to the Supervisor control plane with a vCenter Single Sign-On administrator account you can:

View resources in all vSphere Namespaces including system vSphere Namespaces (kube-system and all vmware-system-* namespaces)
Edit resources in all non-system vSphere Namespaces, that are namespaces created through the vSphere Client or vCenter Server APIs.

However, when logged in to the Supervisor control plane with an account part of the Administrators group, you are not allowed to edit any cluster-level resources, create vSphere Namespaces by using kubectl or create role bindings. You must use the vSphere Client as the primary interface to setting resource quotas, creating and configuring vSphere Namespaces, and setting up user permissions.

DevOps Engineers and Developers Permissions

As a DevOps engineer or developer, typically your user account needs the following permissions:

Object	Permissions
vSphere Namespaces	Edit or Owner
vCenter Single Sign-On user	None or Read-Only

As a DevOps engineer or developer, you use kubectl as your primary interface to interact with vSphere IaaS control plane. You must be able to log in to the Supervisor control plane through the vSphere Plugin for kubectl to view, run, and manage workloads in the vSphere Namespaces that are assigned to you. Therefore, your user account needs Edit or Owner permissions on one or more vSphere Namespaces.

Typically, you don't need to perform any administrative operations on Supervisors through the vSphere Client. In certain cases however, you might want to be able to log in to the vSphere Client to view the resources and workloads in the vSphere Namespaces that are assigned to your account. For this purpose, you might need Read-Only permissions on vSphere.

vSphere Namespaces Privileges

vSphere Namespaces privileges control how you interact with vSphere IaaS control plane. You can set a privilege at different levels in the hierarchy. For example, if you set a privilege at the folder level, you can propagate the privilege to one or more objects within the folder. The object listed in the Required On column must have the privilege set, either directly or inherited.


Privilege Name in the vSphere Client	Description	Required On	Privilege Name in the API
Allows disk decommission operations	Allows for decommissioning operations of data stores.	Data stores	Namespaces.ManageDisks
Backup Workloads component files	Allows for backing up the contents of the etcd cluster (used only in VMware Cloud on AWS).	Clusters	Namespaces.Backup
List accessible namespaces	Allows listing the accessible vSphere Namespaces.	Clusters	Namespaces.ListAccess
Modify cluster-wide configuration	Allows modifying the Supervisor configuration, and creating and deleting vSphere Namespaces.	Clusters	Namespaces.ManageCapabilities
Modify cluster-wide namespace self-service configuration	Allows modifying the vSphere Namespace self-service configuration.	Clusters (for activating and deactivating) Templates (for modifying the configuration) vCenter Server (for creating a template)	Namespaces.SelfServiceManage
Modify namespace configuration	Allows modifying vSphere Namespace configuration options such as resource allocation, user permissions, and content library associations.	Clusters	Namespaces.Manage
Toggle cluster capabilities	Allows manipulating the state of clusterSupervisor capabilities (used internally only for VMware Cloud on AWS).	Clusters	NA
Upgrade clusters to newer versions	Allows initiation of the Supervisor upgrade.	Clusters	Namespaces.Upgrade

Supervisor Services Privileges

Supervisor Services privileges control who can create and manage Supervisor Services on the vSphere IaaS control plane environment.

Table 1. Supervisor Services Privileges
Privilege Name in the vSphere Client	Description	Required On	Privilege Name in the API
Manage Supervisor Services	Allows for creating, updating, or deleting a Supervisor Service. Also allows for installing a Supervisor Service on a Supervisor, and creating or deleting a Supervisor Service version.	Clusters	SupervisorServices.Manage

VM Classes Privileges

VM Classes privileges control who can add and remove virtual machine classes on a vSphere Namespace.

Table 2. Virtual Machine Classes Privileges
Privilege Name in the vSphere Client	Description	Required On	Privilege Name in the API
Manage Virtual Machine Classes	Allows managing virtual machine classes on vSphere Namespaces on a Supervisor.	Clusters	VirtualMachineClasses.Manage

Storage Views Privileges

With the storage views privileges, you will be able to view storage policies in vCenter Server so that you can assign then to vSphere Namespaces.

Table 3. Storage Views Privileges
Privilege Name in the vSphere Client	Description	Required On	Privilege Name in the API
Configure service	Allows privileged users to use all Storage Monitoring Service APIs. Use Storage views.View for privileges to read-only Storage Monitoring Service APIs.	Root vCenter Server	StorageViews.ConfigureService
View	Allows privileged users to use read-only Storage Monitoring Service APIs.	Root vCenter Server	StorageViews.View