Using IAM Roles or Policies to Grant Access to DEW

If you need to perform permission management on role-based authorization model in DEW, see Identity and Access Management (IAM). With IAM, you can:

Create IAM users for personnel based on your enterprise's organizational structure. Each IAM user has their own identity credentials for accessing DEW resources.
Grant users only the permissions required to perform a task.
Entrust a Huawei account or a cloud service to perform efficient O&M on your DEW resources.

If your account does not require individual IAM users, skip this section.

This section describes how to perform role-based authorization. Figure 1 shows the process.

Prerequisites

Before assigning permissions to a user group, you need to understand the DEW permissions that can be added to the user group and select appropriate permissions. For details about the system permissions supported by DEW, see Permissions Management. To grant permissions for other services, learn about all permissions supported by IAM.

Authorization Process

Figure 1 Authorizing the DEW access permission to a user
Click to enlarge

Create a user group and grant it permissions.
Create a user group on the IAM console and grant the user group the KMS CMKFullAccess permission (indicating full permissions for keys).
Create an IAM user and add it to the created user group.
Create a user on the IAM console and add the user to the group created in 1.
Log in as the IAM user and verify permissions.
Log in to the console as newly created user, and verify that the user only has read permissions for DEW.
- Choose Service List > Data Encryption Workshop. In the navigation pane, choose Key Pair Service. If a message is displayed, indicating lack of permissions, the KMS CMKFullAccess policy has taken effect.
- Click Service List and select a service other than DEW. If a message is displayed indicating that you do not have permission to access the service, the KMS CMKFullAccess policy has taken effect.

Example Custom Policies

Custom policies can be created as a supplement to the system policies of DEW. For the actions supported for custom policies, see Permissions and Supported Actions.

You can create custom policies in either of the following ways:

Visual editor: Select cloud services, actions, resources, and request conditions without the need to know policy syntax.
JSON: Edit JSON policies from scratch or based on an existing policy.

For details, see Creating a Custom Policy. The following provides examples of custom DEW policies.

Example: authorizing users to create and import keys

{    "Version": "1.1",    "Statement": [        {            "Effect": "Allow",            "Action": [                "kms:cmk:create",                "kms:cmk:getMaterial",                "kms:cmkTag:create",                "kms:cmkTag:batch",                "kms:cmk:importMaterial"            ]        }    ]}

For example, select Specify resource path.
When you create a custom policy on the IAM console, select Specific, set Resources to Specific, secretName to Specify resource path, and click Add Resource Path.

As shown in Figure 2, the rules for setting the resource path are as follows:
- If KMS is selected, set Path to the key ID, which can be obtained from the key management list.
- If CSMS is selected, set Path to the secret name, which can be obtained from the secret list.
Figure 2 Specifying a resource path

Example: denying deletion of key tags
A deny policy must be used in conjunction with other policies to take effect. If the permissions assigned to a user contain both Allow and Deny actions, the Deny actions take precedence over the Allow actions.

The following method can be used if you need to assign permissions of the KMS Administrator policy to a user but also forbid the user from deleting key tags (kms:cmkTag:delete). Create a custom policy with the action to delete key tags, set its Effect to Deny, and assign both this and the KMS Administrator policies to the group the user belongs to. Then the user can perform all operations except deleting key tags. The following is a policy for denying key pair tags.
```
{    "Version": "1.1",    "Statement": [        {            "Effect": "Deny",            "Action": [                "kms:cmkTag:delete"            ]        }    ]}
```

Example: authorizing users to use keys

{    "Version": "1.1",    "Statement": [        {            "Effect": "Allow",            "Action": [                "kms:dek:crypto",                "kms:cmk:get",                "kms:cmk:crypto",                "kms:cmk:generate",                "kms:cmk:list"            ]        }    ]}

Example: multi-action policy

A custom policy can contain actions of multiple services that are all of the global or project-level type. The following is a policy with multiple statements:

{    "Version": "1.1",    "Statement": [        {            "Effect": "Allow",            "Action": [                "rds:task:list"            ]        },        {            "Effect": "Allow",            "Action": [                "kms:dek:crypto",                "kms:cmk:get",                "kms:cmk:crypto",                "kms:cmk:generate",                "kms:cmk:list"            ]        }    ]}

KMS Resources

A resource is an object that exists within a service. KMS resources include customer master keys (CMKs). When creating a custom policy, you can specify a resource path to select specific resources.