Using the AccessPolicy API to Manage Namespace Permissions (Kubernetes RBAC-based)

Prerequisites

• Before assigning permissions to users or user groups, you need to review the information provided in Namespace Permissions (Kubernetes RBAC-based).
• To use an access policy, an IAM user or user group must have the specific permissions. These include CreateAccessPolicy, UpdateAccessPolicy, DeleteAccessPolicy, ListAccessPolicy, and GetAccessPolicy. Learn about the CCE system policies that can be added to a user group and select appropriate ones as needed. For details about how to assign permissions to a user group, see Granting Cluster Permissions to an IAM User.

Configuring Namespace Permissions Through APIs

You can regulate users' or user groups' access to Kubernetes resources in a single namespace based on their Kubernetes RBAC roles. Users with the configuration permission can configure access policies through APIs.

1. Call the API to create an access policy. For details, see Making an API Request.

   POST /api/v3/access-policies

   The request body is as follows:

   {
       "kind": "AccessPolicy",
       "apiVersion": "v3",
       "name": "policy-test",
       "clusters": [ "*" ],
       "accessScope": {
           "namespaces": [ "default" ]
       },
       "policyType": "CCEClusterAdminPolicy",
       "principal": {
           "type": "user",
           "ids": ["id1", "id2" ]
       }
   }

   Parameter	Item	Description
   name	Name	Name of the access policy.
   clusters[]	Cluster list	ID list of clusters for which access policies need to be added. A maximum of 200 clusters can be authorized at a time. For details about how to obtain a cluster ID, see How to Obtain Parameters in the API URI. The wildcard character (*) is supported, indicating that access policies are added to all clusters. CAUTION: The cluster to which an access policy is applied must be in a normal state. If the cluster is hibernated or abnormal, API request delivery may fail or behave unexpectedly.
   accessScope.namespaces[]	Namespace	List of namespaces for which access policies need to be added. A maximum of 500 namespaces can be authorized at a time. The wildcard character (*) is supported, indicating that access policies are added to all namespaces. When an access policy is added to a specific namespace, a RoleBinding is created within that namespace, and the assigned permissions become effective there. Once the creation process is complete, the corresponding RoleBinding can be obtained within the namespace. When an access policy is added to all namespaces, a ClusterRoleBinding is created, and the assigned permissions become effective within the entire cluster.
   policyType	Permission type	Permission type. Options: CCEClusterAdminPolicy: administrator permissions, including read and write permissions on all resources in all namespaces. CCEAdminPolicy: O&M permissions, including read and write permissions on most resources in all namespaces and read-only permissions on nodes, storage volumes, namespaces, and quota management. CCEEditPolicy: developer permissions, including read-write permissions on most resources in all or selected namespaces. If this kind of permissions is configured for all namespaces, its capability is the same as the O&M permissions. CCEViewPolicy: read-only permissions, including read-only permissions on most resources in all or selected namespaces.
   principal.type	User or user group type.	Type of the user or user group authorized by the access policy. Options: user: IAM user group: user group agency: agency account
   principal.ids[]	User or user group list	List of IDs of IAM users, user groups, or agencies to be authorized. A maximum of 500 IDs can be entered at a time. For details about how to obtain an ID, see Obtaining Account, IAM User, Group, Project, Region, and Agency Information.

2. The CCE management plane automatically synchronizes the access policies to the associated cluster. Run the kubectl command. Then, RoleBinding or ClusterRoleBinding will be created in the cluster.
   

   The synchronization will take several minutes to take effect.

   In this example, the administrator permissions of the default namespace are granted to an IAM user. You can obtain the corresponding RoleBinding in the default namespace.

   1. Check RoleBinding in the cluster.

      kubectl get rolebinding -n default

      In the following command output, role_access_policy_2abf31fc-cd7a-11ef-9ed5-0255ac100047 specifies the automatically created RoleBinding.

      NAME                                                      ROLE                        AGE
      role_access_policy_2abf31fc-cd7a-11ef-9ed5-0255ac100047   ClusterRole/cluster-admin   27s

   2. Check RoleBinding details.

      kubectl get rolebinding role_access_policy_2abf31fc-cd7a-11ef-9ed5-0255ac100047 -n default -o yaml

      Command output:

      apiVersion: rbac.authorization.k8s.io/v1
      kind: RoleBinding
      metadata:
        annotations:
          CCE.com/IAM: "true"
        creationTimestamp: "2025-03-26T07:58:24Z"
        labels:
          rbac.kubernetes.io/GeneratedByAccessPolicy: "true"
        name: role_access_policy_2abf31fc-cd7a-11ef-9ed5-0255ac100047
        namespace: default
        resourceVersion: "1086"
        uid: 7000328f-c91c-4731-b3a6-807713c29f35
      roleRef:
        apiGroup: rbac.authorization.k8s.io
        kind: ClusterRole
        name: cluster-admin
      subjects:
      - apiGroup: rbac.authorization.k8s.io
        kind: User
        name: 069fcc2116c347b89869eae3cd38ba23
      - apiGroup: rbac.authorization.k8s.io
        kind: User
        name: 7af166e21b094f659c35a9e30f67f5a2

3. Log in to the CCE console as the newly authorized IAM user for verification. For more information, see Logging In as an IAM User.

   In the service list, choose Cloud Container Engine. On the CCE console, access the cluster and choose the target namespace. If only the default namespace is authorized and the kube-system namespace is unavailable, the access policy has taken effect.