Open in app

Sign in

Write

Sign in

Huawei Cloud CCE, RBAC and IAM

Burak Ovalı
10 min readJul 1, 2023

Intro

In this article, we will use Huawei Cloud’s IAM together with Kubernetes’ RBAC authorization. In CCE we will manage permissions for IAM Users and user groups under the tenant account. This combination provides a variety of authorization methods, including IAM fine-grained authorization, IAM token authorization, cluster-scoped authorization, and namespace-wide authorization.

Prerequisites

KooCLI, previously named “HCloud CLI”, is a command line tool for managing cloud service APIs released on API Explorer. With this tool, you can call open APIs of cloud services to manage and use your cloud service resources.

CCE is a highly reliable, high-performance service through which enterprises can manage containerized applications. CCE supports elastic application scaling and native Kubernetes applications and tools, allowing you to easily set up a container runtime environment on the cloud.

Creating IAM User and User Group

Let’s create User Group and IAM User for testing. Next, let’s manage permissions using Kubernetes’ RBAC authorization in combination with them.

You can use the Identity and Access Management service from the console to create an IAM User. In this article, I will proceed by using KooCLI instead of the console.

We will need Domain ID to create IAM User and User Group with KooCLI. You can obtain the Domain ID from My Credentials under the account name. Account ID and Domain ID are the same things.

After obtaining the Account ID value, let’s create a custom parameter in hcloud. This step is not mandatory, it is just a method for quick use.

$ hcloud configure set - cli-profile=default - cli-custom=true

# Fill
Enter the custom parameter name: domainID
2. Encrypt the custom parameter for storage? (y/N): n
3. Enter the parameter value: <accountID-Value>

Then let’s create a group called “cce-access”. The custom parameter created in hcloud is used as “custom.parameterName”. After running the command line, a group called cce-access will be created. Let’s note ID of this group. In this article, this value is “id”: “7df7f0b-someValues-baa680a7”.

$ hcloud IAM KeystoneCreateGroup --group.name=cce-access --group.domain_id="custom.domainID"

## Output
{
  "group": {
    "id": "7df7f0b-someValues-baa680a7",
    "name": "cce-access",
    "description": "",
    "links": {
      "self": "https://iam.ap-southeast-3.myhuaweicloud.com/v3/groups/7df80a7"
    },
    "domain_id": "cc066-someValues-851cf8",
  }
}

Then let’s give this group access to CCE using system-defined rules. By running the following command line, the predefined rules associated with CCE will be listed. Let’s note the id of the rule whose display name is CCE FullAccess.

hcloud IAM KeystoneListPermissions --catalog=CCE
{
  "total_number": 5,
  "roles": [
    {
     ...
     ...
      "id": "a47cc003654b4e7e8aa26144150e970a",
      "display_name": "CCE FullAccess",
      "type": "XA",
      "policy": {
        "Version": "1.1",
        "Statement": [
          {
            "Action": [
              "cce:*:*",
              "ecs:*:*",
              "evs:*:*",
              "vpc:*:*",
              "sfs:*:get*",
              "sfs:shares:ShareAction",
              "aom:*:get",
              "aom:*:list",
              "aom:autoScalingRule:*",
              "apm:icmgr:*",
              "lts:*:*"
            ],
            "Effect": "Allow"
          }
    },
      ...
      ...
  ],
  "links": {
    "next": null,
    "previous": null,
    "self": "https://iam.ap-southeast-3.myhuaweicloud.com/v3/roles?catalog=CCE"
  }
}

After obtaining the rule id, let’s define this rule in the cce-access group. Now all users under this group will also have these permissions.

$ hcloud IAM KeystoneAssociateGroupWithProjectPermission --group_id=7df7f0b-someValues-baa680a7 --role_id=a47cc003654b4e7e8aa26144150e970a

You can run the following command line to check. This command line will output the existing groups and their details.

$ hcloud IAM KeystoneListGroups

## Output
{
  "total_number": 2,
  "groups": [
    {
      "domain_id": "cc066-someValues-851cf8",
      "create_time": 1688039158563,
      "name": "cce-access",
      "description": "",
      "links": {
        "next": null,
        "previous": null,
        "self": "https://iam.ap-southeast-3.myhuaweicloud.com/v3/groups/7df7f0b-someValues-baa680a7"
      },
      "id": "77df7f0b-someValues-baa680a7"
    },
    ...
    ...
    ...
  ],
  "links": {
    "self": "https://iam.ap-southeast-3.myhuaweicloud.com/v3/groups"
  }
}

After creating the group, we can now create an IAM user. Let’s set the username as “read-only-user” and the password as “Test123!!”. After creating the user, user.id will be returned to you. Let’s note this ID.

The first time you log in, it will ask you to set a new password!!

$ hcloud IAM KeystoneCreateUser --user.name="read-only-user" --user.password="Test123!!"

## Output
{
  "user": {
    "id": "b17c-someValues-89cd7",
    "name": "read-only-user",
    "description": "",
    "enabled": true,
    "links": {
      "self": "https://iam.ap-southeast-3.myhuaweicloud.com/v3/users/b17c-someValues-89cd7"
    },
    "password_expires_at": null,
    "domain_id": "cc066-someValues-851cf8",
    "pwd_status": true
  }
}

After creating the user, let’s add the IAM User we created to the User Group. For this, we need User Group ID and IAM User ID.

$ hcloud IAM KeystoneAddUserToGroup --user_id=b17c-someValues-89cd7 --group_id=7df7f0b-someValues-baa680a7

So far the requirements for IAM have been completed. To check for the last time, let’s run the following command line using user.ID. This command line gives us an explanation about the User and the User Group it is associated with.

$ hcloud IAM KeystoneListGroupsForUser --user_id=b17c-someValues-89cd7

## Output
{
  "groups": [
    {
      "domain_id": "cc066-someValues-851cf8",
      "create_time": 1688039158563,
      "name": "cce-access",
      "description": "",
      "links": {
        "next": null,
        "previous": null,
        "self": "https://iam.ap-southeast-3.myhuaweicloud.com/v3/groups/7df7f0b-someValues-baa680a7"
      },
      "id": "7df7f0b-someValues-baa680a7"
    }
  ],
  "links": {
    "self": "https://iam.ap-southeast-3.myhuaweicloud.com/v3/users/b17c-someValues-89cd7/groups"
  }
}

Creating Deployment and Service

Let’s quickly deploy Deployment and LB Service to the existing Kubernetes environment. This step is not mandatory. You can use your own image.

I deploy the demo of the 2048 game to the Kubernetes environment with the following Deployment manifest.

After deploying the Deployment, I will quickly create a Load Balancer Service using Huawei Cloud annotations. Annotations in the Service manifest will automatically create an Elastic Load Balancer for me.

If you’re going to run this manifest, I suggest you pay attention!

After creating the Service and Deployment, let’s check by running the command line below and getting the PublicIP assigned for the Service.

$ kubectl get svc -n default

## Output                                                                                                                                                 08:24:19 ÖS
NAME              TYPE           CLUSTER-IP       EXTERNAL-IP                  PORT(S)        AGE
kubernetes        ClusterIP      10.247.0.1       <none>                       443/TCP        47m
lb-service-game   LoadBalancer   10.247.226.193   119.8.175.133,172.16.0.120   80:30119/TCP   12m

When we request PublicIP, the 2048 game will welcome us.

Kubernetes RBAC

RBAC stands for Role-Based Access Control, and it is a security mechanism used in Kubernetes to control access to resources within a cluster. RBAC allows administrators to define granular permissions and policies for users or groups of users, enabling fine-grained control over who can perform specific actions on Kubernetes objects.

In Kubernetes RBAC, there are three main components:

  1. Roles: A Role is a set of permissions defined within a specific namespace. It grants access to specific resources and operations within that namespace. For example, a Role can allow read access to pods or the ability to create services.
  2. ClusterRoles: Similar to Roles, ClusterRoles define permissions, but they are cluster-wide rather than limited to a specific namespace. ClusterRoles are used to grant access to cluster-level resources and operations such as managing nodes or creating persistent volumes.
  3. RoleBindings and ClusterRoleBindings: These objects bind Roles or ClusterRoles to specific users, groups, or service accounts. RoleBindings are used to grant access within a particular namespace, while ClusterRoleBindings are used to grant access across the entire cluster.

CCE Permission Management

  • Cluster-level permissions: Cluster-level permissions management evolves out of the system policy authorization feature of IAM. IAM users in the same user group have the same permissions. On IAM, you can configure system policies to describe which IAM user groups can perform which operations on cluster resources. For example, you can grant user group A to create and delete cluster X, add a node, or install an add-on, while granting user group B to view information about cluster X.
  • Cluster-level permissions involve CCE non-Kubernetes APIs and support fine-grained IAM policies and enterprise project management capabilities.
  • Namespace-level permissions: You can regulate users’ or user groups’ access to Kubernetes resources in a single namespace based on their Kubernetes RBAC roles. CCE has also been enhanced based on open-source capabilities. It supports RBAC authorization based on IAM user or user group, and RBAC authentication on access to APIs using IAM tokens.
  • Namespace-level permissions involve CCE Kubernetes APIs and are enhanced based on the Kubernetes RBAC capabilities. Namespace-level permissions can be granted to IAM users or user groups for authentication and authorization, but are independent of fine-grained IAM policies.

In general, you configure CCE permissions in two scenarios. The first is creating and managing clusters and related resources, such as nodes. The second is creating and using Kubernetes resources in the cluster, such as workloads and Services.

Combining IAM User and User Groups with RBAC

You can regulate users’ or user groups’ access to Kubernetes resources in a single namespace based on their Kubernetes RBAC roles. The RBAC API declares four kinds of Kubernetes objects: Role, ClusterRole, RoleBinding, and ClusterRoleBinding, which are described as follows:

  • 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. Illustration:

First, let’s create a ClusterRole that includes get, list, and watch (read-only) permissions for all resources.

Likewise, let’s create a Role under the default namespace that includes get, list, and watch (read-only) permissions for all resources.

Let’s create these two yaml files in Kubernetes environment.

$ kubectl apply -f clusterrole-readonly.yaml
## Output                                                                                                                                  09:32:21 ÖS
clusterrole.rbac.authorization.k8s.io/readonly-cr-demo created

$ kubectl apply -f role-readonly.yaml  
## Output                                                                                                                                         09:32:36 ÖS
role.rbac.authorization.k8s.io/readonly-role-demo created

You can list available ClusterRoles and Roles using the following command line.

$ kubectl get clusterrole,role 
                                                                                                                                     09:34:06 ÖS
## Output
NAME # ClusterRole                                                                                                       
clusterrole.rbac.authorization.k8s.io/readonly-cr-demo
NAME # Role                                      
role.rbac.authorization.k8s.io/readonly-role-demo

We combine the ClusterRole and Role with IAM User or User Group.

Here is the annotation we need to add: CCE.com/IAM: “true”. Then subjects.kind and subjects.name are other parameters we need.

When we want to Role Binding a group, it will take the value of subjects.kind Group. The subjects.name will be the groupID. We obtained this value while creating the Group.

After applying the manifest below, ClusterRoleBinding will be performed for all the users under the cce-access group.

We need the same parameters for RoleBinding as for ClusterRoleBinding. But this time we are making a RoleBinding for the User, not the Group. That’s why subjects.kind took the value User instead of Group.

In this post, instead of using the above two (Cluster) RoleBinding manifests, I will apply a RoleBinding manifest for the Group. After running the command line below, users under the cce-access group will have read-only access to resources under the default namespace.

$ kubectl apply -f rolebinding-group.yaml

## Output                                                                                                                             17s 09:43:49 ÖS
rolebinding.rbac.authorization.k8s.io/role_readonly_group created

You can list the available Roles and RoleBindings by running the command line.

$ kubectl get role,rolebinding -n default

## Output Role                                                                                                                               09:44:53 ÖS
NAME                                                CREATED AT
role.rbac.authorization.k8s.io/readonly-role-demo   2023-06-29T18:32:41Z
## Output RoleBinding
NAME                                                        ROLE                      AGE
rolebinding.rbac.authorization.k8s.io/role_readonly_group   Role/readonly-role-demo   46s

Now that you have completed all the processes so far, let’s login with the IAM User and test the permissions.

As you will remember, we set username “read-only-user”, password “Test123!!” when creating IAM User.

--user.name="read-only-user" --user.password="Test123!!"

We can access the IAM User Login page using the link here. The first field will be Tenant Name or Huawei Cloud Account Name. The second field will be IAM User’s Username and the last field will be Password.

Since this is the first time we log in, Huawei will ask us to set a new password.

After logging in, let’s access the CCE service from the Console. We have deployed the 2048 game before. Let’s try to change the resource quotas with read-only RBAC for test-purpose Deployment.

After logging into the CCE service, let’s click on Workloads from the left console. Then let’s choose one of the available deployment resources and click on the Container tab. When we try to change the CPU or Memory Quota from the Edit Quota button, we will encounter the No Access Permission warning. This much!

Conclusion

In conclusion, Huawei Cloud IAM provides powerful features for managing access control and authorization within the cloud environment. IAM Users and User Groups allow for granular control over resource access, ensuring that only authorized individuals or entities can interact with specific resources. Roles and ClusterRoles define sets of permissions, allowing administrators to grant fine-grained access to users or groups. RoleBindings and ClusterRoleBindings associate users or groups with roles, enabling the assignment of permissions at runtime.

When integrating Huawei Cloud with Kubernetes, these IAM concepts extend to the Kubernetes authorization framework. IAM Users and User Groups can be mapped to Kubernetes users, while Roles and ClusterRoles define access permissions within the Kubernetes cluster. RoleBindings and ClusterRoleBindings establish the link between IAM users and Kubernetes roles, enabling seamless integration between the two systems.

Kubernetes
Huawei
Rbac
Cloud Container Engine
Cloud

--

--

Burak Ovalı

Written by Burak Ovalı

44 Followers

Help

Status

About

Careers

Press

Blog

Privacy

Terms

Text to speech

Teams