Tablestore RAM Policy-Tablestore(Tablestore)-阿里云帮助中心

A Resource Access Management (RAM) policy is a permission policy attached to a RAM identity (user, user group, or role). To control what a RAM user or role can do with Tablestore resources, attach a RAM policy that specifies the allowed operations and resources.

How it works

RAM policies use identity-based authorization. A policy attached to a RAM user, user group, or role specifies the operations (Action) the identity can perform, the resources (Resource) it can access, and the conditions (Condition) under which the policy applies.

When a RAM identity sends a request, the system evaluates all applicable policies in the following order:

Explicit deny takes precedence: If any policy contains a Deny rule that matches the request, the request is denied immediately.
Look for an explicit allow: If no Deny rule matches, the request is allowed when a matching Allow rule exists.
Implicit deny: If neither a Deny nor an Allow rule matches, the request is denied by default.

Tablestore supports two types of RAM policies:

System policies: Predefined by Alibaba Cloud for common authorization scenarios. You can attach these policies but cannot modify them.
Custom policies: Created and maintained by you. Custom policies give fine-grained control over resource scope, operations, and the conditions under which they apply.

Grant permissions with a system policy

Alibaba Cloud creates system policies, which you can attach to a user identity directly in the RAM console. The following procedure uses a RAM user as an example.

Go to the RAM Users page, and in the Actions column of the target user, click Grant Permission.

In the search box, enter the name of the system policy you want to attach, and then select it. Tablestore supports the following three system policies:

System policy	Permission scope
AliyunOTSFullAccess	Full management permissions for Tablestore.
AliyunOTSReadOnlyAccess	Read-only access to Tablestore.
AliyunOTSWriteOnlyAccess	Write-only access to Tablestore.

Click OK to complete the permission setup.

Grant permissions with a custom policy

You create and maintain custom policies in two steps: create the policy, then attach it to a user identity.

Step 1: Create a custom policy

Go to the Policies page and click Create Policy.

Select JSON Editor and enter the policy in JSON format in the editor.

The following example policy allows all operations on the instance named example-instance and on all tables in it.

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ots:*",
      "Resource": [
        "acs:ots:*:*:instance/example-instance",
        "acs:ots:*:*:instance/example-instance/table/*"
      ]
    }
  ]
}

A RAM policy contains two top-level elements: Version and Statement.

Top-level element	Description
Version	The policy version. Fixed at `1`, not modifiable.
Statement	The body of the policy. Contains one or more authorization or denial rules. Each rule contains four sub-elements: Effect (authorization effect), Action (authorized operation), Resource (authorized resource), and Condition (authorization condition). See the following table for details.

Statement sub-element	Description
Effect	The effect of the policy. Valid values: `Allow` or `Deny`.
Action	The specific operations performed on the resource. Add the `ots:` prefix and use the wildcard `*` when needed.
Resource	The resource scope. Format: `acs:ots:[region]:[user_id]:instance/[instance_name]/table/[table_name]`.
Condition	The conditions under which the policy takes effect. If you specify multiple conditions, all conditions must be met (logical AND) for the policy to apply.

For complete policy elements and syntax, see Authorization policy syntax and elements.

Click OK, enter a Policy Name, and then click OK to complete the custom policy creation.

Step 2: Attach the policy to a user identity

Attach the policy you created in the previous step to a user identity. The following procedure uses a RAM user as an example.

Go to the RAM Users page, and in the Actions column of the target user, click Grant Permission.
Enter the custom policy name in the search box and select the target policy.
Click OK to complete the permission setup.

Common authorization scenarios

The following scenarios are typical RAM policy use cases in Tablestore. Each includes a complete JSON policy example.

Scenario 1: Grant read and write permissions with combined IP, time, and protocol conditions

Allow users from the 10.10.XX.XX/24 CIDR block to read from and write to the online-01 and online-02 instances and all tables in them, but only over HTTPS and only before 2028-01-01 00:00:00.

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ots:*",
      "Resource": [
        "acs:ots:*:*:instance/online-01",
        "acs:ots:*:*:instance/online-01/table*",
        "acs:ots:*:*:instance/online-02",
        "acs:ots:*:*:instance/online-02/table*"
      ],
      "Condition": {
        "IpAddress": {
          "acs:SourceIp": [
            "10.10.XX.XX/24"
          ]
        },
        "DateLessThan": {
          "acs:CurrentTime": "2028-01-01T00:00:00+08:00"
        },
        "Bool": {
          "acs:SecureTransport": "true"
        }
      }
    }
  ]
}

Scenario 2: Deny write requests from a specific IP address to specific instances

Deny users from IP address 10.10.XX.XX write access to all tables in instances whose names start with online or product in the China (Beijing) region. This rule does not restrict operations on the instances themselves.

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "ots:Create*",
        "ots:Insert*",
        "ots:Put*",
        "ots:Update*",
        "ots:Delete*",
        "ots:BatchWrite*"
      ],
      "Resource": [
        "acs:ots:cn-beijing:*:instance/online*/table*",
        "acs:ots:cn-beijing:*:instance/product*/table*"
      ],
      "Condition": {
        "IpAddress": {
          "acs:SourceIp": [
            "10.10.XX.XX"
          ]
        }
      }
    }
  ]
}

Scenario 3: Restrict a RAM user to manage only specified instances

Allow a RAM user to manage only the specified instances. The policy contains three Statements that grant the console query permissions, full operation permissions on the target instance, and CloudMonitor query permissions, respectively.

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ots:ListInstance",
        "ots:ListTagResources"
      ],
      "Resource": "acs:ots:*:*:instance/*"
    },
    {
      "Effect": "Allow",
      "Action": "ots:*",
      "Resource": [
        "acs:ots:*:*:instance/yourInstance",
        "acs:ots:*:*:instance/yourInstance/table*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": "cms:Query*",
      "Resource": "*"
    }
  ]
}

Each Statement plays a specific role, as described in the following table.

Policy	Description
`{ "Effect": "Allow", "Action": [ "ots:ListInstance", "ots:ListTagResources" ], "Resource": "acs:ots:::instance/*" }`	The Overview page in the Tablestore console loads the instance list and tag list. This Statement grants the RAM user the query permissions required to load them. Note A RAM user that manages instances through the console must have these permissions.
`{ "Effect": "Allow", "Action": "ots:", "Resource": [ "acs:ots:::instance/yourInstance", "acs:ots:::instance/yourInstance/table" ] }`	Grants the RAM user all permissions on the `yourInstance` instance and the tables in it.
`{ "Effect": "Allow", "Action": "cms:Query", "Resource": "" }`	Grants the RAM user CloudMonitor permissions to view monitoring data for instances and tables.