Closer look at vSphere Permissions for vSphere with Tanzu 

Questions regarding vSphere Permissions for vSphere with Tanzu has been frequently brought up more lately and the majority of questions that I have seen, has primarily focused on the behavior of the vSphere UI Inventory. After taking a closer look and experimenting with a few permutations within my lab, I realized that most folks were simply focusing on what they were most familiar with, which is using the vSphere UI to interact with vSphere.

Although vSphere with Tanzu is tightly integrated with vSphere and the vSphere UI is certainly a primary interface, it is certainly not the only interface nor is it always the interface for end users like a developer. Depending on the needs of your end users and how your organization wishes to grant access to a vSphere Namespace, there are actually a few options that are available to you. In fact, users can interact with vSphere with Tanzu without ever logging into the vSphere UI and that is completely valid and may even be desirable for some organizations.

Note: The custom kubectl plugin for vSphere (kubectl-vsphere) which is needed to interact with vSphere with Tanzu can be downloaded by simply opening a browser (or use wget) to following URL: https://[SUPERVISOR-CLUSTER-IP]/wcp/plugin/[OS]-amd64/vsphere-plugin.zip, where OS is darwin, linux or windows (e.g. https://172.17.33.33/wcp/plugin/darwin-amd64/vsphere-plugin.zip)

Below are the results of my testing using the various vSphere Roles and Groups including the various behavior across the different consumption interfaces including the vSphere UI. To help better illustrate the results, I am also using some example personas, these are purely used as an example and may differ based on your organizational needs.

Persona: VI/Cloud Admin

In this scenario, the user is a vSphere Administrator and has the following memberships:

• vSphere Role: Administrator
• vSphere SSO Group: Administrators
• vSphere Namespace: SSO User and/or Active Directory User

The user will be able to view and manage all vSphere infrastructure including the vSphere Namespaces and the respective workloads including TKG Workload Clusters and/or VMs via the VM Service.

Here is a summary of this users access:

Persona: Developers

In this scenario, the user is a consumer of the vSphere Namespace and will be able to provision both TKG Workload Clusters and/or VMs in a self-service manner using the kubectl CLI. Depending on the needs of your organization and the requirement of your end users, you have a couple of options.

Option 1 - In this first option, the user has the following memberships:

• vSphere Role: None
• vSphere SSO Group: None
• vSphere Namespace: SSO User and/or Active Directory User

The user may not have or want to login to the vSphere UI and as long as they have been granted access to a specific vSphere Namespace and given the Supervisor Cluster IP Address, they will be able to login and start deploying and managing their workloads.

Here is a summary of this users access:

As an aside, although end users may not have a graphical interface such as the vSphere UI, there are many Kubernetes based UI/Terminal tools out there including my favorite, which is Octant. Simply download the client and once started, it will login using your k8s configuration file and you will now have access to all your TKG Workload Clusters and can easily switch between them.

Option 2 - In this second option, the user has the following memberships:

• vSphere Role: ReadOnly
• vSphere SSO Group: None
• vSphere Namespace: SSO User and/or Active Directory User

In addition to all the interactions described in Option 1 using kubectl, users will now also have the ability login to the vSphere UI. Although users will not see their vSphere Namespace and the respective workloads in the vSphere Inventory view, they can navigate to the Namespaces tab under the vSphere Cluster level and get a view of all their resources and workloads as shown in the screenshot below. To be honest, this is not a view I normally navigate to and I often forget about, but it does provide users with all relavent information as it pertains to their vSphere Namespace-based workloads in the vSphere UI, which is especially handy if you still have a need to manage or access your traditional VMs.

Persona: DevOps/Platform Operations

In this scenario, the user may not be part of the core vSphere Administrator team but is part of a Platform Team who is responsible for managing, supporting and/or creating the TKG Workload Clusters and has the following memberships:

• vSphere Role: Non-Administrator or Custom Role
• vSphere SSO Group: ServiceProviderUsers
• vSphere Namespace: SSO User and/or Active Directory User

This persona may not exists in every organization, but it is certainly a growing trend (see this blog post for more details) and may have a need to easily view all vSphere Namespace-based workloads using the classic vSphere Inventory view.

Note: This option was initially covered in this blog post.