Performing Cluster Namespace RBAC

Background

CCE permissions are classified into cluster permissions and namespace permissions. Namespace permissions are based on Kubernetes RBAC and can be used to grant permissions on resources in clusters and namespaces.

Currently, the CCE console provides four types of namespace-level ClusterRole permissions by default: cluster-admin, admin, edit, and view. However, these permissions apply to resources in the namespace regardless of resource types (pods, Deployments, and Services).

Solution

Kubernetes RBAC enables you to easily grant permissions on namespace resources.

• Role: defines a set of rules for accessing Kubernetes resources in a namespace.
• RoleBinding: defines the relationship between users and roles.
• ClusterRole: defines a set of rules for accessing Kubernetes resources in a cluster (including all namespaces).
• ClusterRoleBinding: defines the relationship between users and cluster roles.

Role and ClusterRole specify actions that can be performed on specific resources. RoleBinding and ClusterRoleBinding bind roles to specific users, user groups, or ServiceAccounts. See the following figure.

Figure 1 Role binding

The user in the preceding figure can be an IAM user or user group in CCE. You can efficiently control permissions on namespace resources through RoleBindings.

The section describes how to use Kubernetes RBAC to grant user user-example with the permission for viewing pods. (This is the only permission the user has.)

Prerequisites

RBAC is supported only on clusters of v1.11.7-r2 or later.

Creating an IAM User and User Group

Log in to IAM and create an IAM user named user-example and a user group named cce-role-group. For details about how to create an IAM user and user group, see Creating IAM Users and Creating User Groups.

Grant the CCE FullAccess permission to the cce-role-group user group. For details about how to grant permissions to a user group, see Assigning Permissions to User Groups.

CCE FullAccess has the permissions for cluster operations (such as cluster creation), but does not have the permissions to operate Kubernetes resources (such as viewing pods).

Creating a Cluster

Log in to CCE and create a cluster.

Do not use IAM user user-example to create a cluster because CCE automatically assigns the cluster-admin permissions of all namespaces in the cluster to the user who creates the cluster. That is, the user can fully control the resources in the cluster and all its namespaces.

Log in to the CCE console as IAM user user-example, download the kubectl configuration file in the cluster and connect to the cluster. Run the following command to obtain the pod information. The output shows that user-example does not have the permission to view the pods or other resources. This indicates that user-example does not have the permissions to operate Kubernetes resources.

# kubectl get pod
Error from server (Forbidden): pods is forbidden: User "0c97ac3cb280f4d91fa7c0096739e1f8" cannot list resource "pods" in API group "" in the namespace "default"
# kubectl get deploy
Error from server (Forbidden): deployments.apps is forbidden: User "0c97ac3cb280f4d91fa7c0096739e1f8" cannot list resource "deployments" in API group "apps" in the namespace "default"

Creating a Role and RoleBinding

Log in to the CCE console, download the kubectl configuration file in the cluster and connect to the cluster. Create a Role and RoleBinding.

Log in as the account used to create the cluster because CCE automatically assigns the cluster-admin permissions to the account. That is, the account has the permissions to create Roles and RoleBindings. Alternatively, you can use IAM users who have the permissions to create Roles and RoleBindings.

The procedure for creating a Role is very simple. To be specific, specify a namespace and then define rules. The rules in the following example are to allow GET and LIST operations on pods in the default namespace.

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default                          # Namespace
  name: role-example
rules:
- apiGroups: [""]
  resources: ["pods"]                         # The pod can be accessed.
  verbs: ["get", "list"]                      # The GET and LIST operations can be performed.

• apiGroups indicates the API group to which the resource belongs.
• resources indicates the resources that can be operated. Pods, Deployments, ConfigMaps, and other Kubernetes resources are supported.
• verbs indicates the operations that can be performed. get indicates querying a specific object, and list indicates listing all objects of a certain type. Other value options include create, update, and delete.

For details, see Using RBAC Authorization.

After creating a Role, you can bind the Role to a specific user, which is called RoleBinding. The following shows an example:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: RoleBinding-example
  namespace: default
  annotations:
    CCE.com/IAM: 'true'
roleRef:
  kind: Role
  name: role-example
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: User
  name: 0c97ac3cb280f4d91fa7c0096739e1f8    # IAM user ID
  apiGroup: rbac.authorization.k8s.io

The subjects section binds a Role with an IAM user so that the IAM user can obtain the permissions defined in the Role, as shown in the following figure.

Figure 2 A RoleBinding binds the Role to the user.

You can also specify a user group in the subjects section. In this case, all users in the user group obtain the permissions defined in the Role.

subjects:
- kind: Group
  name: 0c96fad22880f32a3f84c009862af6f7    # User group ID
  apiGroup: rbac.authorization.k8s.io

Verification

Use IAM user user-example to connect to the cluster and view the pods. The pods can be viewed.

# kubectl get pod
NAME                                   READY   STATUS    RESTARTS   AGE
nginx-658dff48ff-7rkph                 1/1     Running   0          4d9h
nginx-658dff48ff-njdhj                 1/1     Running   0          4d9h
# kubectl get pod nginx-658dff48ff-7rkph
NAME                     READY   STATUS    RESTARTS   AGE
nginx-658dff48ff-7rkph   1/1     Running   0          4d9h