Before you can start consuming a vSphere with Tanzu enabled vSphere Cluster, you need to first create and configure a vSphere Namespace. This is a pretty straight forward process (check out this quick video if you are interested). One of the required configuration is to setup up permissions for which user/groups can access and consume the vSphere Namespace using one of the three default roles.
A question was recently raised in the community on the definition of each role since the user was not able to find more details in the official documentation. Here is a quick summary for each role and its functionality:
- Owner - Can modify and delete vSphere Namespace
- Can Edit - Can modify vSphere Namespace
- Can View - Can perform read only operations on vSphere Namespace
Note: I have already shared this feedback with the vSphere with Tanzu Product Manager to help improve our documentation on this topic
There was also a related question on whether these roles mapped into Kubernetes (K8s) layer, which is the Supervisor Cluster in your vSphere with Tanzu enabled vSphere Cluster? This actually got me curious since I am still a novice when it comes to K8s access control (RBAC). I decided to take a closer look and with some trial error, I was able to see how these vSphere Namespace roles, which is a vCenter Server construct maps into the respective K8s constructs within the Supervisor Cluster.
Disclaimer: This information is purely for educational purposes, administrators only need to worry about the three vSphere Namespace roles for configuring access control. How this maps into K8s constructs is not something that is required for functionality.
Before we explore how these vSphere Namespace roles maps into K8s, lets configure three different users for each of the respective roles:
When you assign a user/group to one of these roles within vCenter Server, a RoleBinding is created for each user/group that is then mapped to one of two ClusterRole: edit or view. If you are curious on the detailed definition for each of the ClusterRole, I have gone ahead shared the details in the following two Github gists:
If you are logged into your Supervisor Cluster using kubectl, you can view this mapping by running the following command:
kubectl get rolebinding
For those with a keen eye, you may have noticed something interesting, that the administrator and william user both have the same ClusterRole/edit role even though they were assigned different vSphere Namespace roles? I certainly caught this nuance and wondered how vSphere was differentiating between these two users, since only the administrator user was the only one who could actually delete the vSphere Namespace.
It turns out, that an additional ClusterRoleBinding is also created for those assigned the Owner role which then maps to ClusterRole that controls whether a user/group can delete a vSphere Namespace. The ClusterRoleBinding is not something that can be viewed by ordinary users including the administrator account and you must be logged in directly into the Supervisor Cluster (see Option 2 for the process if you are interested).
To view this specific ClusterRoleBinding, you can run the following command for the specific vSphere Namespace and then search for "wcp:user":
kubectl get clusterrolebinding -n primp-industries | grep 'wcp:user'
Putting all this together, here is how a vSphere Namespace role (a vCenter Server construct) is mapped into the K8s layer of the Supervisor Cluster which includes a ClusterRole and can also include a ClusterRoleBinding.
Thanks for the post