Manage PolarDB permissions for RAM users with custom policies - PolarDB

When system policies don't cover your access requirements, create custom policies to grant RAM users precise control over specific PolarDB clusters, operations, IP addresses, or encryption settings.

Prerequisites

Before you begin, ensure that you have:

An Alibaba Cloud account. If not, sign up first.
Familiarity with how PolarDB resources are specified in RAM policies. See Use RAM for resource authorization.

To customize permissions or grant the specific permissions on tables, you can use the permission management feature of Database Management Service (DMS). See Manage user permissions on MySQL databases.

Policy structure

A RAM policy is a JSON document that defines who can do what on which resources and under what conditions. Each policy contains one or more Statement objects, each with:

Field	Required	Description
`Action`	Yes	The API operations to allow or deny (e.g., `polardb:CreateBackup`)
`Resource`	Yes	The PolarDB resources the statement applies to — a specific cluster ARN or `*` for all
`Effect`	Yes	`Allow` or `Deny`
`Condition`	No	Additional constraints such as source IP or encryption requirements

For policy syntax details, see Policy structure and syntax.

Create and attach a custom policy

Create a custom policy using one of the examples below as a starting point. See Create custom policies.
Attach the policy to the RAM user. See Grant permissions to a RAM user.

Policy examples

Restrict access to specific clusters

Use this policy when you have multiple PolarDB clusters and want a RAM user to manage only a subset — for example, clusters i-001 and i-002.

Suitable for: cluster administrators who need full control over designated clusters.

{
  "Statement": [
    {
      "Action": "polardb:*",
      "Effect": "Allow",
      "Resource": [
        "acs:polardb:*:*:*/i-001",
        "acs:polardb:*:*:*/i-002"
      ]
    },
    {
      "Action": "polardb:Describe*",
      "Effect": "Allow",
      "Resource": "*"
    }
  ],
  "Version": "1"
}

`Resource` in the first statement: acs:polardb:*:*:*/i-001 targets a specific cluster by its ID (the last segment of the ARN). Full management access applies only to i-001 and i-002.
**Action: polardb:Describe* on Resource: "*"**: Required for the RAM user to see any clusters in the PolarDB console. Without this, the console cluster list appears empty.

The authorized RAM user can view all the clusters and resources, but can manage only the two clusters whose IDs are i-001 and i-002. You can still manage the two clusters by using API operations, command-line interfaces (CLIs), or software development kits (SDKs).

Restrict access to specific features

Use this policy when you want a RAM user to perform only a fixed set of operations across all PolarDB clusters — for example, a backup administrator or a security officer.

Suitable for: role-based access control where a RAM user needs limited operations such as backup management or whitelist configuration.

{
  "Statement": [
    {
      "Action": [
        "polardb:Describe*",
        "polardb:CreateBackup",
        "polardb:DeleteBackup",
        "polardb:ModifyDBClusterAccessWhitelist"
      ],
      "Resource": "*",
      "Effect": "Allow"
    }
  ],
  "Version": "1"
}

This policy allows the RAM user to query cluster information and backups, create and delete backups, and modify whitelists for all PolarDB clusters in the account. All other operations are denied by default.

To adjust the allowed operations, replace or extend the Action list with specific API operation names. See Services that work with RAM for the full list of PolarDB API operations that support RAM authorization.

Restrict access by IP address

Use this policy when you need to ensure that a RAM user can only access PolarDB clusters from specific IP addresses — for example, from a corporate network or a bastion host.

Suitable for: security-sensitive environments where cluster access must be confined to known network locations.

{
  "Version": "1",
  "Statement": [
    {
      "Action": "*",
      "Effect": "Allow",
      "Resource": "*",
      "Condition": {
        "IpAddress": {
          "acs:SourceIp": [
            "xxx.xxx.x.x"
          ]
        }
      }
    }
  ]
}

`acs:SourceIp`: Replace xxx.xxx.x.x with the allowed IP address or CIDR block.
Effect: The RAM user can manage all PolarDB clusters in the account, but only from the specified IP addresses. Requests from any other address are denied.

Restrict TDE status

Use this policy when you want to restrict the TDE status for RAM users when creating clusters — for example, to enforce an encryption-at-rest policy for compliance.

Suitable for: compliance officers or security teams enforcing mandatory encryption standards.

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "polardb:*",
      "Resource": "*",
      "Condition": {
        "Bool": {
          "polardb:EncryptionRequired": [
            "false"
          ]
        }
      }
    }
  ]
}

`Effect: Deny`: Blocks any PolarDB action where polardb:EncryptionRequired evaluates to false. All operations are denied unless TDE is enabled.

What's next

Use RAM for resource authorization — understand the PolarDB resource ARN format and how to target specific clusters, regions, or accounts in your policies
Services that work with RAM — full list of PolarDB API operations that support RAM authorization
Policy structure and syntax — reference for all policy fields, condition operators, and supported values