All Products
Search
Document Center

:RAM policies

Last Updated:Feb 01, 2024

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

  • Creates Function Compute sink connectors.

  • Creates MaxCompute sink connectors.

  • Creates Object Storage Service (OSS) sink connectors.

  • Creates Elasticsearch sink connectors.

  • Creates MySQL source connectors.

  • Creates Data Lake Analytics (DLA) sink connectors.

No

DeleteDeployment

  • Deletes Function Compute sink connectors.

  • Deletes MaxCompute sink connectors.

  • Deletes OSS sink connectors.

  • Deletes Elasticsearch sink connectors.

  • Deletes MySQL source connectors.

  • Deletes DLA sink connectors.

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.