After configuring an external identity provider (like Azure Entra) on the vSphere Supervisor, administrators may encounter authorization failures when adding groups at the namespace level. While assigning individual users with a domain works as expected, assigning a group with a domain causes users within that group to receive a "Forbidden" error when executing kubectl commands against the guest clusters.
Example error:
Error from server (Forbidden): namespaces is forbidden: User "[email protected]" cannot list resource "namespaces" in API group "" at the cluster scope
vSphere Supervisor
VKS Guest Clusters
vCenter (VC) permissions dictate that principals must be in User Principal Name (UPN) format (<subject_name>@<domain>). Because Supervisor permissions inherit this standard, assigning a group inherently appends the domain to the group's subject name. When this permission syncs to the guest cluster, the resulting ClusterRoleBinding retains the appended domain (e.g., [email protected]), which causes a mismatch with the domain-less group ID claims provided by the identity provider during authentication.
To resolve this issue, administrators can bypass the domain-appending behavior by utilizing a specific suffix during permission assignment at the Supervisor level:
Identify the specific Group (or Group ID) you wish to grant access to.
In the vSphere Client, assign the namespace permissions to the group by appending the @no-domain suffix to the subject name.
Example: <group_name>@no-domain
Save the permissions.
The Supervisor treats this input as a subject without a domain, successfully satisfying vCenter's strict UPN formatting requirements. When the permission is synced down to the guest cluster, it will correctly generate a ClusterRoleBinding featuring only the base group name, restoring standard RBAC evaluation and cluster access.