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.
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.
cluster-adminClusterRole using a RoleBinding. The
cluster-adminrole lets users provision and operate clusters. You can view this mapping using the command
kubectl get rolebindingfrom 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.
The table shows the types of vSphere permissions required for various 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.