Clarifying vSphere Supervisor Permissions: Distinguishing vCenter Inventory Roles from Kubernetes RBAC

Products

• VMware vSphere Kubernetes Service

Issue/Introduction

Users attempting to access vSphere Supervisor Clusters via kubectl frequently encounter 403 Forbidden errors, even when they possess "Supervisor Administrator" or "vSphere Administrator" roles. This is often confused with a configuration defect, but it is an expected architectural design.

Environment

vSphere Supervisor Cluster (VKS 9.x)

Cause

The confusion stems from the two-tier permission model in vSphere Supervisor:

1. vCenter Inventory Roles: Roles such as "Supervisor Administrator" govern access within the vSphere Client interface (e.g., viewing namespaces, resource pools, and inventory objects).
2. Kubernetes Namespace RBAC: Access to cluster resources (via kubectl) is governed strictly by Kubernetes RBAC objects, which are mapped to vSphere namespaces.

Being an "Administrator" in vSphere inventory does not automatically grant "Cluster Administrator" privileges in Kubernetes. Users must be explicitly assigned "Namespace Owner" or "Can Edit" roles at the namespace level to interact with resources via kubectl

Resolution

 

• Do not rely on "Cluster-Wide" permissions: SSO users are designed to be restricted by namespace. Commands like kubectl get pods -A will return a "Forbidden" error by design.
   
• Assign Namespace Roles: Permissions for kubectl access must be assigned directly within the vSphere Web UI under Supervisor Management -> Namespaces. Ensure the user/group has "Namespace Owner" or "Can Edit" roles assigned there.
   
• Verify Access: Use kubectl auth can-i to verify access after role assignment.
   
• Scope Operations: Direct users to perform operations within the specific namespace (e.g., kubectl get pods -n <namespace>) rather than attempting cluster-wide queries.