Understanding Project Roles and VKS Cluster Permission Models in VCF Automation 9.1.0
Article ID: 443022
Updated On:
Products
Issue/Introduction
This KB article provides a summary of FAQ regarding the relationship and behavioral specifications between the Project Roles defined in the VCF Automation 9.1.0 Organization Portal and the deployed VKS clusters.
Please note that this information is accurate as of VCF 9.1.0.
The behavior and product specifications described here are subject to change in future releases.
Environment
- VCF Automation 9.1.0
- vSphere Kubernetes Service
Resolution
Q1. What VCF Automation Project Role is required to execute "DOWNLOAD KUBECONFIG" for a VKS Guest Cluster?
Only the "Project Administrator" and "Project Advanced User" roles can perform this action.
Note that even when attempting to generate a kubeconfig using the VCF CLI, a Project User cannot generate or obtain it unless a Project Administrator (or a Project Advanced User) has previously executed the "vcf cluster register vcfa-jwt-authenticator" command against the target VKS Cluster.
Q2. Is it expected behavior that a "Project User" or "Project Auditor" cannot execute "DOWNLOAD KUBECONFIG"?
Yes, this is the expected behavior by design.
Project Auditor
The Project Auditor is a read-only role. In the current product specification, downloading the kubeconfig automatically grants broad administrative privileges (equivalent to cluster-admin) to the VKS cluster. Therefore, downloading is blocked for this role due to security reasons.
Project User
In VCF Automation, the Project User is designed as a "Catalog Consumer" role, rather than a direct end-user or operator role for the VKS Guest Cluster. For this reason, while a Project User can deploy a VKS cluster from the provided service catalog, direct access permission (DOWNLOAD KUBECONFIG) to the cluster is not automatically granted.
To learn how to assign appropriate permissions and allow a Project User to use a VKS cluster, please refer to KB - How to configure RBAC for VKS Clusters deployed via VCF Automation in VCF 9.1.0.
Q3. Is it expected behavior that the "edit-xxxx" pseudo group is assigned to the kubeconfig obtained by a "Project Advanced User" or "Project Administrator"?
Yes, this is the expected behavior by design.
The initial kubeconfig downloaded via the "DOWNLOAD KUBECONFIG" action grants powerful administrative privileges equivalent to cluster-admin through the "edit-xxxx" pseudo group.
Because this kubeconfig contains an authentication token that includes full administrative privileges, distributing this file to general users is not recommended.
Additional Information
Feedback
