If you want to grant users the minimum required permissions on the ApsaraMQ for Kafka console and API operations without sharing the AccessKey pair of your Alibaba Cloud account, you can use Resource Access Management (RAM) to manage the permissions. This helps ensure the security of your resources.
RAM policies
In RAM, a policy includes a set of permissions that are specified based on the policy structure and syntax. Each policy specifies the resources on which permissions are granted, the operations that can be performed or cannot be performed on specific resources, and the conditions that are required for the policy to take effect. For information about the structure and syntax of policies, see Policy structure and syntax.
In RAM, a policy is a resource entity. ApsaraMQ for Kafka supports the following types of policies:
System policy: System policies are created and maintained by Alibaba Cloud. You can use system policies to perform coarse-grained permission control on RAM users. You cannot modify system policies.
Custom policy: You can create, update, and delete custom policies. You can use custom policies to perform fine-grained permission control on RAM users. You need to manage the versions of custom policies.
System policies
The following table describes system policies that are supported by ApsaraMQ for Kafka.
Policy | Description |
AliyunKafkaFullAccess | The management permissions on ApsaraMQ for Kafka. RAM users to whom this policy is attached are granted the permissions to perform all operations in the ApsaraMQ for Kafka console and call all API operations of ApsaraMQ for Kafka. This policy grants permissions that are equivalent to the permissions of an Alibaba Cloud account on ApsaraMQ for Kafka. |
AliyunKafkaReadOnlyAccess | The read-only permissions on ApsaraMQ for Kafka. RAM users to whom this policy is attached are granted only the read-only permissions on all ApsaraMQ for Kafka resources that belong to their Alibaba Cloud accounts. This policy does not grant permissions to perform operations in the ApsaraMQ for Kafka console or call the API operations of ApsaraMQ for Kafka. |
Sample system policy
In this example, the AliyunKafkaFullAccess system policy is attached to a RAM user. After the policy is attached, the RAM user is granted the permissions to perform all operations on the ApsaraMQ for Kafka console and call all API operations of ApsaraMQ for Kafka. The granted permissions are equivalent to the permissions of the corresponding Alibaba Cloud account on ApsaraMQ for Kafka. The following code shows the content of the policy:
{
"Version": "1",
"Statement": [
{
"Action": "alikafka:*",
"Resource": "*",
"Effect": "Allow"
},
{
"Action": "ram:CreateServiceLinkedRole",
"Resource": "*",
"Effect": "Allow",
"Condition": {
"StringEquals": {
"ram:ServiceName": [
"connector.alikafka.aliyuncs.com",
"instanceencryption.alikafka.aliyuncs.com",
"alikafka.aliyuncs.com",
"etl.alikafka.aliyuncs.com"
]
}
}
}
]
}
Custom policies
The following table describes custom policies that are supported by ApsaraMQ for Kafka.
Action | Permission description | Read-only |
ReadOnly | Only reads all resources. | Yes |
ListInstance | Views instances. | Yes |
StartInstance | Deploys instances. | No |
UpdateInstance | Updates instance configurations. | No |
ReleaseInstance | Releases instances. | No |
ListTopic | Views topics. | Yes |
CreateTopic | Creates topics. | No |
UpdateTopic | Updates topic configurations. | No |
DeleteTopic | Deletes topics. | No |
ListGroup | Views groups. | Yes |
CreateGroup | Creates groups. | No |
UpdateGroup | Updates group configurations. | No |
DeleteGroup | Deletes groups. | No |
QueryMessage | Queries messages. | Yes |
SendMessage | Sends messages. | No |
DownloadMessage | Downloads messages. | Yes |
CreateMessageSearch | Enables message retrieval. | No |
OperateMessageSearch | Starts and stops message retrieval tasks. | No |
ListMessageSearch | Views retrieved messages. | Yes |
DeleteMessageSearch | Deletes message retrieval tasks. | No |
CreateDeployment |
| No |
DeleteDeployment |
| No |
ListDeployments | Views connectors. | Yes |
UpdateDeploymentRemark | Changes connector descriptions. | No |
GetDeploymentLog | Queries the operational logs of connectors. | Yes |
OperateDeployment | Starts and stops connectors. | No |
CreateOtsSinkDeployment | Creates Tablestore sink connectors. | No |
OperateOtsSinkDeployment | Starts and stops Tablestore sink connectors. | No |
DeleteOtsSinkDeployment | Deletes Tablestore sink connectors. | No |
CreateAdbSinkDeployment | Creates AnalyticDB sink connectors. | No |
OperateAdbSinkDeployment | Starts and stops AnalyticDB sink connectors. | No |
DeleteAdbSinkDeployment | Deletes AnalyticDB sink connectors. | No |
EnableAcl | Enables the access control list (ACL) feature. | No |
CreateAcl | Creates ACLs. | No |
DeleteAcl | Deletes ACLs. | No |
ListAcl | Queries ACLs. | Yes |
CreateSaslUser | Creates Simple Authentication and Security Layer (SASL) users. | No |
DeleteSaslUser | Deletes SASL users. | No |
ListSaslUser | Queries SASL users. | Yes |
CreateETLTask | Creates extract, transform, and load (ETL) tasks. | No |
ListETLTask | Queries ETL tasks. | Yes |
DeleteETLTask | Deletes ETL tasks. | No |
Sample custom policy
In this example, the AliyunKafkaCustomAccess policy is attached to a RAM user. After the policy is attached, the RAM user is granted only the permissions to view the alikafka_post-cn-xxx instance and the topics and groups on the instance, query messages, and download messages in the ApsaraMQ for Kafka console or by calling API operations. The following code shows the content of the policy:
{
"Version": "1",
"Statement": [
{
"Action": [
"alikafka:ListInstance",
"alikafka:ListTopic",
"alikafka:ListGroup",
"alikafka:QueryMessage",
"alikafka:DownloadMessage"
],
"Resource": "acs:alikafka:*:*:alikafka_post-cn-xxx",
"Effect": "Allow"
}
]
}
References
For information about how to grant permissions to a RAM user, see Grant permissions to RAM users and Grant permissions across Alibaba Cloud accounts.