Permissions Management
If you need to assign different permissions to employees in your enterprise to access your DMS for Kafka resources on HUAWEI CLOUD, Identity and Access Management (IAM) is a good choice for fine-grained permissions management. IAM provides identity authentication, permissions management, and access control, helping you secure access to your HUAWEI CLOUD resources.
With IAM, you can use your HUAWEI CLOUD account to create IAM users for your employees, and assign permissions to the users to control their access to specific resource types. For example, some software developers in your enterprise need to use DMS for Kafka resources but should not be allowed to delete the resources or perform any other high-risk operations. In this scenario, you can create IAM users for the software developers and grant them only the permissions required for using DMS for Kafka resources.
If your HUAWEI CLOUD account does not require individual IAM users for permissions management, skip this section.
IAM is free of charge. You pay only for the resources you use. For more information about IAM, see the IAM Service Overview.
Permissions policies of DMS for Kafka are based on DMS. Therefore, when assigning permissions, select DMS permissions policies.
DMS for Kafka Permissions
By default, new IAM users do not have permissions assigned. You need to add a user to one or more groups, and attach permissions policies or roles to these groups. Users inherit permissions from the groups to which they are added and can perform specified operations on cloud services based on the permissions.
DMS for Kafka is a project-level service deployed and accessed in specific physical regions. To assign DMS permissions to a user group, specify the scope as region-specific projects and select projects (for example, cn-north-1 for CN North-Beijing1) for the permissions to take effect. If All projects is selected, the permissions will take effect for the user group in all region-specific projects. When accessing DMS for Kafka, the users need to switch to a region where they have been authorized to use this service.
- Roles: A type of coarse-grained authorization mechanism that defines permissions related to user responsibilities. This mechanism provides only a limited number of service-level roles for authorization. When using roles to grant permissions, you need to also assign other roles on which the permissions depend to take effect. However, roles are not an ideal choice for fine-grained authorization and secure access control.
- Policies: A type of fine-grained authorization mechanism that defines permissions required to perform operations on specific cloud resources under certain conditions. This mechanism allows for more flexible policy-based authorization, meeting requirements for secure access control. For example, you can grant DMS for Kafka users only the permissions for managing instances. Most policies define permissions based on APIs. For the API actions supported by DMS for Kafka, see Permissions Policies and Supported Actions.
Table 1 lists all the system-defined roles and policies supported by DMS for Kafka.
|
Role/Policy Name |
Description |
Type |
Dependency |
|---|---|---|---|
|
DMS FullAccess |
Administrator permissions for DMS. Users granted these permissions can perform all operations on DMS. |
System-defined policy |
None |
|
DMS UserAccess |
Common user permissions for DMS, excluding permissions for creating, modifying, deleting, dumping, and scaling up instances. |
System-defined policy |
None |
|
DMS ReadOnlyAccess |
Read-only permissions for DMS. Users granted these permissions can only view DMS data. |
System-defined policy |
None |
|
DMS Administrator |
Administrator permissions for DMS logical tenancy. Users granted these permissions can perform all operations in DMS Queue Manager. |
System-defined role |
None |
- Currently, DMS uses only the DMS Administrator role.
- DMS FullAccess, DMS UserAccess, and DMS ReadOnlyAccess policies are used to control the operation permissions for DMS for Kafka and DMS for RabbitMQ.
- The DMS FullAccess, DMS UserAccess, and DMS ReadOnlyAccess policies contain OBS actions. Due to data caching, the policy will take effect five minutes after it is attached to a user, user group, or project.
Table 2 lists the common operations supported by each system-defined policy or role of DMS for Kafka. Select the policies or roles as required.
|
Operation |
DMS FullAccess |
DMS UserAccess |
DMS ReadOnlyAccess |
|---|---|---|---|
|
Creating instances |
√ |
× |
× |
|
Changing the billing mode from pay-per-use to yearly/monthly |
√ |
× |
× |
|
Modifying instances |
√ |
× |
× |
|
Deleting instances |
√ |
× |
× |
|
Modifying instance specifications |
√ |
× |
× |
|
Enabling dumping |
√ |
× |
× |
|
Creating dumping tasks |
√ |
√ |
× |
|
Restarting instances |
√ |
√ |
× |
|
Querying instance information |
√ |
√ |
√ |
Last Article: Basic Concepts
Next Article: Billing
Did this article solve your problem?
Thank you for your score!Your feedback would help us improve the website.