Role/Policy-based Authorization

Prerequisites

You have learned about the permissions supported by CCI. For details, see Role/Policy-based Authorization. For the permissions for other services, see System-defined Policies/Roles.

Process Flow

Figure 1 Process of granting CCI permissions

1. Create a user group and assign permissions (the CCIReadOnlyAccess policy as an example).
2. Create an IAM user and add it to the user group.
3. Log in as the IAM user and verify permissions.

   In the authorized region, perform the following operations:

   • Choose Service List > Cloud Container Instance 2.0. On the CCI 2.0 console, click Create Pod in the upper right corner. If the pod cannot be created, the CCIReadOnlyAccess policy has taken effect.
   • Switch to the console of any other service. If a message indicates that you do not have the required permissions for accessing the service, the CCIReadOnlyAccess policy takes effect.

Example Custom Policies

Custom policies can supplement system-defined policies of CCI. You can add actions in custom policies as needed. For details about supported actions, see Actions Supported by Policy-based Authorization.

To create a custom policy, choose either visual editor or JSON.

• Visual editor: Select cloud services, actions, resources, and request conditions. This does not require knowledge of policy syntax.
• JSON: Create a policy in the JSON format from scratch or based on an existing policy.

For details about how to create custom policies, see Creating a Custom Policy. The following are examples of common CCI 2.0 custom policies.

• Example 1: Allowing users to delete a pod

  {
          "Version": "1.1",
          "Statement": [
              {
                  "Effect": "Allow",
                  "Action": [
                      "cci:pod:delete"
                  ]
              }
          ]
  }

• Example 2: Denying pod deletion

  Different policies can be used together. If permissions assigned to a user contain both "Allow" and "Deny" actions, the "Deny" action takes precedence over the "Allow" action.

  

  When you create a "Deny" policy, the fine-grained authentication applies only to the user's direct operations. For example, if you create a "Deny" policy for cci:pod:create, the user cannot create pods. However, if the user has the cci:deployment:create permissions, the user can create pods for the Deployment.

  If you need to assign permissions of the CCI Admin policy to a user but you want to prevent the user from deleting pods, you can create another custom policy for denying pod deletion and attach both policies to the group that the user belongs to. Then the user can perform all operations on CCI 2.0 except deleting pods. The following is an example of a "Deny" policy:

  {
          "Version": "1.1",
          "Statement": [
              {
                  "Effect": "Deny",
                  "Action": [
                      "cci:pod:delete"
                  ]
              }
          ]
  }

• Example 3: Defining permissions for multiple actions in a policy

  A custom policy can contain multiple actions of one service or the actions of multiple services that are of the global or project-level type. The following is an example policy containing actions of multiple services:

  { 
          "Version": "1.1", 
          "Statement": [ 
              { 
                  "Action": [ 
                      "cci:pod:list",
                      "cci:pod:get",
                      "cci:pod:delete",
                      "cci:namespace:list",
                      "cci:namespace:get",
                      "vpc:*:*"
                  ], 
                  "Effect": "Allow" 
              } 
          ] 
  }