Tablestore:Create a custom policy

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*"

Instance management operations

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

Table operations and data read/write operations

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

Operations for Tunnel Service

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

IP address-based access control

You can create an IP address whitelist to specify the IP addresses or CIDR blocks that are allowed access to 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 to access Tablestore resources only from the IP addresses 10.10.XX.XX and 10.11.XX.XX.XX:

  {
  "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 to access Tablestore resources only from the IP address 10.10.XX.XX or CIDR block 10.10.XX.XX/24:

  {
  "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 sent 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"
}                    

Scenario 1: Multiple access control conditions

In this scenario, RAM users who use the 10.10.XX.XX/24 CIDR block can manage the instances named online-01 and online-02 and all tables in the 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. Take note that you must 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. In the Basic information section, enter the name and description of the policy.

   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. In the Actions column, click Add Permissions.

   3. In the Grant Permission panel, select Custom Policy, search for the name of the policy you created, and select the check box next to the policy to add the policy to the Selected Policies column.

   4. Click Grant permissions.

   5. Click Close.

Scenario 2: Reject requests

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

1. Log on to the RAM console. Take note that you must 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. In the Basic information section, enter the name and description of the policy.

   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. In the Actions column, click Add Permissions.

   3. In the Grant Permission panel, select Custom Policy, search for the name of the policy you created, and select the check box next to the policy to add the policy to the Selected Policies column.

   4. Click Grant permissions.

   5. Click Close.