WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud
  • Tanzu
    • Application Modernization
    • Tanzu services
    • Tanzu Community Edition
    • Tanzu Kubernetes Grid
    • vSphere with Tanzu
  • Home Lab
  • Nested Virtualization
  • Apple
You are here: Home / VMware Tanzu / Closer look at vSphere Permissions for vSphere with Tanzu 

Closer look at vSphere Permissions for vSphere with Tanzu 

07.22.2021 by William Lam // Leave a Comment

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:

Interface Access
vSphere UI VM Inventory View ✅
vSphere UI Namespace Inventory View ✅
vSphere Namespace View ✅
Kubectl 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:

Interface Access
vSphere UI VM Inventory View ❌
vSphere UI Namespace Inventory View ❌
vSphere Namespace View ❌
Kubectl 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.

Interface Access
Component Access
vSphere UI VM Inventory View ✅
vSphere UI Namespace Inventory View ❌
vSphere Namespace View ✅
Kubectl Access ✅

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.

Interface Access
Component Access
vSphere UI VM Inventory View ✅
vSphere UI Namespace Inventory View ✅
vSphere Namespace View ✅
Kubectl Access ✅

More from my site

  • vSphere with Tanzu using Intel Arc GPU
  • Automated enablement of vSphere with Tanzu using vSphere Zones in vSphere 8
  • Demo of VMware Cloud Consumption Interface (CCI)
  • Beta for VMware Cloud Consumption Interface (CCI) formally Project Cascade
  • Quick Tip - Correctly naming TKR's in Local Content Library for vSphere with Tanzu in vSphere 8

Categories // VMware Tanzu Tags // vSphere with Tanzu

Thanks for the comment! Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Search

Author

William Lam is a Senior Staff Solution Architect working in the VMware Cloud team within the Cloud Infrastructure Business Group (CIBG) at VMware. He focuses on Cloud Native technologies, Automation, Integration and Operation for the VMware Cloud based Software Defined Datacenters (SDDC)

Connect

  • Email
  • GitHub
  • LinkedIn
  • RSS
  • Twitter
  • Vimeo

Recent

  • vSphere with Tanzu using Intel Arc GPU 01/26/2023
  • Quick Tip - Automating allowed and not allowed Datastores for use with vSphere Cluster Services (vCLS) 01/25/2023
  • ESXi with Intel Arc 750 / 770 GPU 01/24/2023
  • How to bootstrap vSAN Express Storage Architecture (ESA) on unsupported hardware? 01/19/2023
  • Automating Virtual Machine screenshots in vSphere 01/18/2023

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2023

 

Loading Comments...