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 Event-Driven Automation using Tanzu Application Platform (TAP) on Tanzu Kubernetes Grid Service
  • Quick deep dive into vSphere Namespace roles
  • Quick demo videos of new VMware Cloud with Tanzu services
  • Single node Supervisor Control Plane VM for vSphere with Tanzu now possible in vSphere 7.0 Update 3
  • Quick Tip - How to deploy NSX Advanced Load Balancer (NSX-ALB) with a single Service Engine
Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

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)

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

Connect

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

Support

Recent

  • ESXi running in unexpected places ... 05/20/2022
  • Quick Tip - Adding a vTPM (Virtual Trusted Platform Module) to a Nested ESXi VM 05/13/2022
  • vSphere Event-Driven Automation using VMware Event Router on VMware Cloud on AWS with Knative or AWS EventBridge 05/10/2022
  • Integrating VMware Event Broker Appliance (VEBA) with Zapier 04/28/2022
  • Using Terraform to activate Tanzu Kubernetes Grid Service on VMware Cloud on AWS 04/27/2022

Advertisment

Copyright WilliamLam.com © 2022

 

Loading Comments...