1. Summary

Define and implement a standardized RBAC template and Controller logic that allows for "Tenant Admins." These admins should have full lifecycle management permissions over their specific HostedCluster and its associated NodePools but have zero visibility or access to the global Management Cluster resources or other tenants' namespaces.

2. Problem Statement / Background

Currently, granting permissions to manage a Hosted Control Plane (HCP) often requires broad permissions on the Management Cluster.

• Over-privileged Access: To manage a HostedCluster CR, users often need access to the namespace where HyperShift is installed or broad cluster-scoped permissions.

• Lack of Namespace Isolation: There is no automated way to link a user’s permissions on a HostedCluster CR (in namespace A) to the sensitive "Hosted Control Plane" namespace (usually clusters-<hc-namespace>-<hc-name>) where the actual control plane pods (Kube-APIServer, Etcd, etc.) reside.

• Security Risk: A tenant admin could potentially view secrets or configmaps in the management cluster that do not belong to them, violating the principle of least privilege.

3. Proposed Enhancement (User Stories)

• The "HCP Tenant Admin" Role: Provide a pre-defined ClusterRole (e.g., hypershift-tenant-admin) that can be bound to a specific namespace.

• Automated Namespace Scoping: When a HostedCluster is created, the system should automatically allow the Tenant Admin to access the backend "Hosted Control Plane" namespace (the one containing the pods/secrets for their API server) without granting access to other "clusters-*" namespaces.

• Resource Limiting: As a Management Cluster Admin, I want to restrict a Tenant Admin so they can only create/edit NodePools and HostedClusters within their assigned project, preventing them from seeing global infrastructure secrets or node configurations of the Management Cluster.

4. Business Value / Impact

• Secure Multi-tenancy: Enables "Cluster-as-a-Service" models where different departments can manage their own clusters without seeing each other's data.

• Compliance: Meets strict regulatory requirements (like SOC2 or HIPAA) regarding data isolation and access control.

• Operational Safety: Prevents accidental modification of Management Cluster components (like the HyperShift Operator itself) by tenant users.

5. Implementation Example: Aligning with RHACM Patterns

• The requested RBAC should follow the existing pattern used by RHACM for ManagedClusterSets. In RHACM, access is delegated to specific teams without giving them full cluster-wide permissions on the Hub cluster.
• Current Example in RHACM: To give a team management rights over a specific group of clusters, we use:

  oc adm policy add-cluster-role-to-group \ open-cluster-management:clusterset-admin:server-foundation-clusterset \ server-foundation-team-admin

   

• This command allows the server-foundation-team-admin group to manage only the clusters within the server-foundation set, without making them a full Cluster Admin of the ACM Hub.
• Proposed Equivalent for HCP: We need a similar "scoped" role for Hosted Control Planes. For example:

  oc adm policy add-role-to-group \ hypershift:hostedcluster-admin:tenant-a-project \ tenant-a-admin-group \ -n tenant-a-project