All Products
Search
Document Center

Tablestore:Configure a custom policy

Last Updated:Dec 06, 2023

This topic describes the Action, Resource, and Condition parameters in Resource Access Management (RAM) policies and the scenarios for which the parameters are suitable.

Action

The Action parameter specifies one or more API operations. You can configure the Action parameter to allow or deny users to access the API operations.

When you create a policy for Tablestore, you must add the ots: prefix to each action and separate multiple actions with commas (,). When you configure the Action parameter, you can also use the asterisk (*) as a wildcard for prefix matching and suffix matching.

The following examples show how to define actions:

Single API operation

"Action": "ots:GetRow"                    

Multiple API operations

"Action": [
"ots:PutRow",
"ots:GetRow"
]                  

All read-only API operations

{
  "Version": "1",
  "Statement": [
    {
      "Action": [
        "ots:BatchGet*",
        "ots:Describe*",
        "ots:Get*",
        "ots:List*",
        "ots:Consume*",
        "ots:Search",
        "ots:ComputeSplitPointsBySize"
      ],
      "Resource": "*",
      "Effect": "Allow"
    }
  ]
}                

All read and write API operations

"Action": "ots:*"               

All SQL-related API operations

"Action": "ots:SQL*"

Resource

The Resource parameter in Tablestore consists of multiple fields including service, region, user_id, instance_name, and table_name. Each field supports the asterisk (*) as a wildcard for prefix matching and suffix matching. You can configure the Resource parameter based on the following format:

acs:ots:[region]:[user_id]:instance/[instance_name]/table/[table_name]            

You must set the value of the service field to ots. The region field specifies the ID of the region in which the resource resides, such as cn-hangzhou. The user_id field specifies the ID of the Alibaba Cloud account. The instance_name field specifies the name of the Tablestore instance. The table_name field specifies the name of the Tablestore table. Configure the preceding fields based on your business requirements.

Note

The name of the Tablestore instance is not case-sensitive. We recommend that you specify the value of the instance_name field in the Resource parameter in lowercase.

The Resource parameter in Tunnel Service is defined by instance rather than table and includes fields such as service, region, user_id, and instance_name. You can configure the Resource parameter based on the following format:

acs:ots:[region]:[user_id]:instance/[instance_name]                         

Typical resource definitions

  • All resources of users in all regions

    "Resource": "acs:ots:*:*:*"                    
  • All instances and their tables of User 123456 in the China (Hangzhou) region

    "Resource": "acs:ots:cn-hangzhou:123456:instance*"                  
  • Instance abc and its tables of User 123456 in the China (Hangzhou) region

    "Resource": [
    "acs:ots:cn-hangzhou:123456:instance/abc",
    "acs:ots:cn-hangzhou:123456:instance/abc/table*"
    ]                   
  • All instances whose names contain the prefix abc and their tables

    "Resource": "acs:ots:*:*:instance/abc*"                   
  • All tables whose names contain the prefix xyz in the instances whose names contain the prefix abc (Instance resources are not included. acs:ots:*:*:instance/abc* cannot match the definition.)

    "Resource": "acs:ots:*:*:instance/abc*/table/xyz*"                    
  • All instances whose names contain the suffix abc and their tables whose names contain the suffix xyz

    "Resource": [
    "acs:ots:*:*:instance/*abc",
    "acs:ots:*:*:instance/*abc/table/*xyz"
    ]                   

Usage notes

  • You can verify the Action and Resource parameters that are configured for a RAM policy by strings. When you configure the Action and Resource parameters, you can use the asterisk (*) as a wildcard for prefix matching and suffix matching. If the Resource parameter is defined as acs:ots:*:*:instance/*/, acs:ots:*:*:instance/abc cannot match the definition. If the Resource parameter is defined as acs:ots:*:*:instance/abc, acs:ots:*:*:instance/abc/table/xyz cannot match the definition.

  • If a user needs to manage instances in the Tablestore console, Tablestore must query the list of instances. Therefore, you must grant the user the read permissions on the acs:ots:[region]:[user_id]:instance/* resources.

  • When you perform an operation on multiple tables at a time by calling API operations, such as BatchGetRow and BatchWriteRow, the backend service separately authenticates each table. You can perform the operation on multiple tables at a time only if all the tables pass the authentication. Otherwise, a permission error is returned.

Tablestore API operations

Tablestore provides the following types of API operations: instance management operations, table operations, data read/write operations, and operations for Tunnel Service. The following tables describe how to configure resources for the API operations.

Instance management operations

Instance management operations are instance-related operations and can be called only by the Tablestore console. If you configure the Action and Resource parameters for instance management operations, some features may be unavailable in the console. The acs:ots:[region]:[user_id]: prefix is omitted from the names of the following resources. Only the instance and table are described.

API operation/Action

Resource

ListInstance

instance/*

InsertInstance

instance/[instance_name]

GetInstance

instance/[instance_name]

DeleteInstance

instance/[instance_name]

Table operations and data read/write operations

Table operations and data read/write operations are performed on tables and rows. Table operations and data read/write operations can be called by the Tablestore console or Tablestore SDKs. If you configure the Action and Resource parameters for table operations and data read/write operations, some features may be unavailable in the console. The acs:ots:[region]:[user_id]: prefix is omitted from the names of the following resources. Only the instance and table are described.

API operation/Action

Resource

ListTable

instance/[instance_name]/table*

CreateTable

instance/[instance_name]/table/[table_name]

UpdateTable

instance/[instance_name]/table/[table_name]

DescribeTable

instance/[instance_name]/table/[table_name]

DeleteTable

instance/[instance_name]/table/[table_name]

GetRow

instance/[instance_name]/table/[table_name]

PutRow

instance/[instance_name]/table/[table_name]

UpdateRow

instance/[instance_name]/table/[table_name]

DeleteRow

instance/[instance_name]/table/[table_name]

GetRange

instance/[instance_name]/table/[table_name]

BatchGetRow

instance/[instance_name]/table/[table_name]

BatchWriteRow

instance/[instance_name]/table/[table_name]

ComputeSplitPointsBySize

instance/[instance_name]/table/[table_name]

StartLocalTransaction

instance/[instance_name]/table/[table_name]

CommitTransaction

instance/[instance_name]/table/[table_name]

AbortTransaction

instance/[instance_name]/table/[table_name]

CreateIndex

instance/[instance_name]/table/[table_name]

DropIndex

instance/[instance_name]/table/[table_name]

CreateSearchIndex

instance/[instance_name]/table/[table_name]

DeleteSearchIndex

instance/[instance_name]/table/[table_name]

ListSearchIndex

instance/[instance_name]/table/[table_name]

DescribeSearchIndex

instance/[instance_name]/table/[table_name]

Search

instance/[instance_name]/table/[table_name]

CreateTunnel

instance/[instance_name]/table/[table_name]

DeleteTunnel

instance/[instance_name]/table/[table_name]

ListTunnel

instance/[instance_name]/table/[table_name]

DescribeTunnel

instance/[instance_name]/table/[table_name]

ConsumeTunnel

instance/[instance_name]/table/[table_name]

BulkImport

instance/[instance_name]/table/[table_name]

BulkExport

instance/[instance_name]/table/[table_name]

SQL_Select

instance/[instance_name]/table/[table_name]

SQL_Create

instance/[instance_name]/table/[table_name]

SQL_DropMapping

instance/[instance_name]/table/[table_name]

Operations for Tunnel Service

Operations for Tunnel Service are tunnel-related operations and can be called by the Tablestore console or Tablestore SDKs. If you configure the Action and Resource parameters for operations for Tunnel Service, some features may be unavailable in the console. The acs:ots:[region]:[user_id]: prefix is omitted from the names of the following resources. Only the instance and table are described.

API operation/Action

Resource

ListTable

instance/[instance_name]

CreateTable

instance/[instance_name]

UpdateTable

instance/[instance_name]

DescribeTable

instance/[instance_name]

DeleteTable

instance/[instance_name]

GetRow

instance/[instance_name]

PutRow

instance/[instance_name]

UpdateRow

instance/[instance_name]

DeleteRow

instance/[instance_name]

GetRange

instance/[instance_name]

BatchGetRow

instance/[instance_name]

BatchWriteRow

instance/[instance_name]

ComputeSplitPointsBySize

instance/[instance_name]

StartLocalTransaction

instance/[instance_name]

CommitTransaction

instance/[instance_name]

AbortTransaction

instance/[instance_name]

CreateIndex

instance/[instance_name]

DropIndex

instance/[instance_name]

CreateSearchIndex

instance/[instance_name]

DeleteSearchIndex

instance/[instance_name]

ListSearchIndex

instance/[instance_name]

DescribeSearchIndex

instance/[instance_name]

Search

instance/[instance_name]

CreateTunnel

instance/[instance_name]

DeleteTunnel

instance/[instance_name]

ListTunnel

instance/[instance_name]

DescribeTunnel

instance/[instance_name]

ConsumeTunnel

instance/[instance_name]

Condition

The policies supported by Tablestore include IP address-based access control, HTTPS-based access control, multi-factor authentication (MFA)-based access control, TLS version-based access control, time-based access control, and policy-based access control.

IP address-based access control

You can create custom policies to specify the IP addresses or CIDR blocks that are allowed or denied to access Tablestore resources. IP address-based access control is suitable for the following scenarios:

  • Allow access from multiple IP addresses.

    The following sample code provides an example on how to allow requests only from the IP addresses 10.10.XX.XX and 10.11.XX.XX.XX to access Tablestore resources.

    {
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ots:*",
            "Resource": "acs:ots:*:*:*",
            "Condition": {
                "IpAddress": {
                    "acs:SourceIp": [
                        "10.10.XX.XX",
                        "10.11.XX.XX"
                    ]
                }
            }
        }
    ],
    "Version": "1"
    }                           
  • Allow access only from one IP address or CIDR block.

    The following sample code provides an example on how to allow requests only from the IP address 10.10.XX.XX or CIDR block 10.10.XX.XX/24 to access Tablestore resources.

    {
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ots:*",
            "Resource": "acs:ots:*:*:*",
            "Condition": {
                "IpAddress": {
                    "acs:SourceIp": [
                        "10.10.XX.XX",
                        "10.10.XX.XX/24"
                    ]
                }
            }
        }
    ],
    "Version": "1"
    }                            

HTTPS-based access control

You can create a custom policy to allow only the requests that are sent over HTTPS to access Tablestore resources.

The following sample code provides an example on how to allow only the requests that are sent over HTTPS to access Tablestore resources.

{
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ots:*",
            "Resource": "acs:ots:*:*:*",
            "Condition": {
                "Bool": {
                    "acs:SecureTransport": "true"
                }
            }
        }
    ],
    "Version": "1"
}                    

TLS version-based access control

You can create a custom policy to allow only the requests that are sent over TLS V1.2 or TLS V1.3 to access Tablestore resources.

The following sample code provides an example on how to allow only the requests that are sent over TLS V1.2 or TLS V1.3 to access Tablestore resources.

{
    "Version": "1",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "ots:*",
            ],
            "Resource": [
                "*"
            ],
            "Condition": {
                "StringNotEquals": {
                  "ots:TLSVersion": [
                    "TLSv1.2",
                    "TLSv1.3"
                  ]
                }
            }
        }
    ]
}

MFA-based access control

You can create a custom policy to allow only the requests that pass MFA to access Tablestore resources.

The following sample code provides an example on how to allow only the requests that pass MFA to access Tablestore resources.

{
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ots:*",
            "Resource": "acs:ots:*:*:*",
            "Condition": {
                "Bool": {
                    "acs:MFAPresent ": "true"
                }
            }
        }
    ],
    "Version": "1"
}                    

Time-based access control

You can create a custom policy to specify the access time of requests. Access requests that are earlier than the specified point in time are allowed or denied.

The following sample code provides an example on how to allow users to access Tablestore resources only before 00:00 on January 1, 2016 (UTC+8).

{
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ots:*",
            "Resource": "acs:ots:*:*:*",
            "Condition": {
                "DateLessThan": {
                    "acs:CurrentTime": "2016-01-01T00:00:00+08:00"
                }
            }
        }
    ],
    "Version": "1"
}                    

Scenarios

This section describes the specific policies and authorization methods that are supported for the Action, Resource, and Condition parameters.

Scenario 1: Multiple authorization conditions

In this scenario, RAM users that use the 10.10.XX.XX/24 CIDR block can manage the instances named online-01 and online-02 and all tables in these instances, including reading data from and writing data to the tables. Access is allowed only over HTTPS before 00:00:00 on January 1, 2016.

  1. Log on to the RAM console. You must first activate the RAM service.

  2. Create a custom policy.

    1. In the left-side navigation pane, choose Permissions > Policies.

    2. On the Policies page, click Create Policy.

    3. On the Create Policy page, click the JSON tab. On the JSON tab, enter the following code in the policy document:

      {
      "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": "2016-01-01T00:00:00+08:00"
                  },
                  "Bool": {
                      "acs:SecureTransport": "true"
                  }
              }
          }
      ],
      "Version": "1"
      }                            
    4. Click Next to edit policy information. Enter the name and description of the policy in the Basic information section.

    5. Click OK.

  3. Attach the policy to a RAM user.

    1. In the left-side navigation pane, choose Identities > Users.

    2. On the Users page, find the RAM user to whom you want to attach the policy. Click Add Permissions in the Actions column.

    3. In the Add Permissions panel, click Custom Policy, search for the policy that you created, and add the policy to the Selected section.

    4. Click OK.

    5. Click Complete.

Scenario 2: Reject requests

In this scenario, RAM users that use the IP address 10.10.XX.XX cannot write data to tables that reside in the China (Beijing) region and that belong to instances whose names contain the online or product prefix. This policy does not take effect for operations on instances.

  1. Log on to the RAM console. You must first activate the RAM service.

  2. Create a custom policy.

    1. In the left-side navigation pane, choose Permissions > Policies.

    2. On the Policies page, click Create Policy.

    3. On the Create Policy page, click the JSON tab. On the JSON tab, enter the following code in the policy document:

      {
          "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"
                          ]
                      }
                  }
              }
          ],
          "Version": "1"
      }                 
    4. Click Next to edit policy information. Enter the name and description of the policy in the Basic information section.

    5. Click OK.

  3. Attach the policy to a RAM user.

    1. In the left-side navigation pane, choose Identities > Users.

    2. On the Users page, find the RAM user to whom you want to attach the policy. Click Add Permissions in the Actions column.

    3. In the Add Permissions panel, click Custom Policy, search for the policy that you created, and add the policy to the Selected section.

    4. Click OK.

    5. Click Complete.