About Identity and Access Management for TKG 2.0 Clusters on Supervisor

DevOps engineers connect to Supervisor to provision and manage the life cycle of Tanzu Kubernetes Grid 2.0 clusters. Developers connect to TKG 2.0 clusters to deploy packages, workloads, and services. Administrators might need direct access to TKG 2.0 cluster nodes to troubleshoot. vSphere with Tanzu 8 provides identity and access management tools and methods supporting each use case and role.

TKG 2.0 Cluster Access Is Scoped to the vSphere Namespace

You provision TKG 2.0 clusters in a vSphere Namespace. Likewise, TKG 2.0 cluster permissions are set and scoped at the vSphere Namespace level. When you configure a vSphere Namespace, you set permissions for that namespace, including the identity source, users and groups, and roles. These permissions apply to any TKG cluster provisioned in that vSphere Namespace.

Tanzu Kubernetes Grid on Supervisor supports two user/group authentication methods: vCenter Single Sign-On and an OIDC-compliant external identity provider.

Authentication Using vCenter Single Sign-On and Kubectl

By default, vCenter Single Sign-On is used to authenticate with the vSphere with Tanzu environment, including Supervisor and TKG 2 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.

To authenticate using vCenter Single Sign-On, you use the vSphere Plugin for kubectl. Once authenticated you use kubectl to declaratively provision and manage the life cycle of TKG clusters, deploy TKG cluster workloads, and to deploy other Supervisor features such as vSphere Pods and Supervisor Services.

The kubectl-vsphere plugin depends on kubectl. When you authenticate with kubectl-vsphere, the plugin does a POST with basic authentication to a /wcp/login endpoint on Supervisor. A JSON Web Token (JWT) is then issued from vCenter, which the Supervisor trusts.

To connect using vCenter Single Sign-On, see Connecting to TKG 2.0 Clusters on Supervisor Using vCenter SSO Authentication.

Authentication Using an External Identity Provider and the Tanzu CLI

In addition to vCenter Single Sign-On authentication, you can configure Supervisor with an external identity provider that supports the OpenID Connect protocol. Once configured Supervisor functions as an OAuth 2.0 client and uses the Pinniped authentication service to connect to TKG clusters using the Tanzu CLI. The Tanzu CLI supports provisioning and managing the life cycle of TKG clusters.

Each Supervisor instance can support a single external identity provider.

Once the authentication plugin and OIDC issuer are configured appropriately for the pinniped-auth CLI to work, when you log in to Supervisor using tanzu login --endpoint, the system looks up a few well known configmaps to build the pinniped config configuration file.

To connect using an external OIDC provider, see Connecting to TKG 2.0 Clusters on Supervisor Using an External Identity Provider.

Authentication Using a Hybrid Approach: vCenter SSO with Tanzu CLI

If you are using vCenter Single Sign-On as the identity provider and you want to use the Tanzu CLI, you can take a hybrid approach and log in to Supervisor using the Tanzu CLI and the vSphere Plugin for kubectl. This approach may be useful for installing Tanzu Packages. See Connect to Supervisor Using the Tanzu CLI and vCenter SSO Authentication.

Users and Groups

When you configure the vSphere Namespace, you grant TKG cluster access to users and groups. The user or group to whom you assign permissions must exist in the identity source. Users authenticate with TKG clusters on Supervisor using their identity provider credentials, using either the vCenter Single Sign-On credentials, or using an external identity provider.

You can grant developers TKG cluster access based on their identity provider or using a cluster role and binding on Kubernetes. See Grant Developers vCenter SSO Access to TKG 2.0 Clusters on Supervisor.

Role Permissions

TKG clusters on Supervisor support three roles: viewer, editor, and owner. Role permissions are assigned at and scoped to the vSphere Namespace. See Configuring vSphere Namespaces for TKG 2.0 Clusters on Supervisor.

A user/group granted the Can view role permission on a vSphere Namespace has read-only access to TKG clusters provisioned in that vSphere Namespace.

A user/group granted the Can edit role permission on a vSphere Namespace can create, read, update, and delete TKG clusters in that vSphere Namespace.

A user/group granted the Owner permission on a vSphere Namespace can administer TKG clusters in that vSphere Namespace, and can create and delete additional vSphere Namespaces using kubectl.

Note: The owner role is supported for users coming from the vCenter Single Sign-On identity source. You cannot use the owner role with a user/group from an external identity provider.

When you assign a user/group to the viewer or editor roles, the system creates a RoleBinding and maps it to a ClusterRole. For example, a user/group assigned to the editor role is mapped to the Kubernetes cluster-admin ClusterRole using a RoleBinding. The cluster-admin role lets users provision and operate clusters. You can view this mapping using the command kubectl get rolebinding from the target vSphere Namespace.

kubectl get rolebinding -n tkg2-cluster-namespace
NAME                                                           ROLE                         AGE
wcp:tkg-cluster-namespace:group:vsphere.local:administrators   ClusterRole/edit             33d
wcp:tkg-cluster-namespace:user:vsphere.local:administrator     ClusterRole/edit             33d

When you assign a user/group to the owner role, the system creates a ClusterRoleBinding and maps it to a ClusterRole that allows the user/group to create and delete vSphere Namespaces using kubectl. You cannot view this mapping using the same approach. You must SSH into a Supervisor node to view this mapping.

vSphere Permissions

The table shows the types of vSphere permissions required for various vSphere with Tanzu personas.

Table 1. vSphere Permissions for vSphere with Tanzu Personas

Persona	vSphere Role	vSphere SSO Group	vSphere Namespace
VI /Cloud Admin	Administrator	Administrators	SSO User and/or AD User
DevOps/Platform Operator	Non-admin or custom role	ServiceProviderUsers	SSO User and/or AD User
Developer	ReadOnly or None	None	SSO User and/or AD User

System Administrator Connectivity

Administrators can connect to TKG cluster nodes as the kubernetes-admin user. This method might be appropriate if vCenter Single Sign-On authentication is not available. For troubleshooting purposes, system administrators can connect to a TKG cluster as the vmware-system-user using SSH and a private key. See Connecting to TKG 2.0 Clusters on Supervisor as a Kubernetes Administrator and System User.