Access control rules-OpenSearch(Open Search)-阿里云帮助中心

By default, your Alibaba Cloud account has full permissions to manage its OpenSearch applications. You can use Alibaba Cloud's Resource Access Management (RAM) service to grant RAM users permissions to access and manage your OpenSearch resources.

Note

Note:

The new console provides more granular RAM permissions than the previous version. To use RAM users with the new console, you must create new RAM authorization policies.
RAM user functionality is supported only in API and SDK versions 3.0 and later, not in V2.
Third-party data source products must adhere to the RAM permission model. You need to grant the RAM user corresponding permissions in the third-party product. You cannot grant a RAM user permissions for ODPS services. This is because a platform limitation prevents a RAM user from listing all projects under the main account, even after the main account authorizes a project for that user. As a result, the RAM user cannot reference the project as a data source in OpenSearch. We recommend you first use your main account to connect to ODPS, and then use a RAM user to work with the OpenSearch application.
To configure an RDS data source in the console using a RAM user, you must also grant the RAM user permissions for the data source. Otherwise, the connection to the RDS service will fail. For more information, see the RDS access authorization section below.
Actions that start with Search (primarily SearchApp and SearchSuggest) do not currently support condition-based authentication using IP addresses. Configuring such conditions will cause authentication to fail.

When permissions take effect

Permissions that you grant to a RAM user take effect approximately 5 minutes after the authorization policy is created or updated.

Minimum common permission sets

To access the OpenSearch console, a RAM user needs a combination of permissions. The following sections provide common minimum permission sets for reference, including permissions to search an application, list applications, view application details, access monitoring and alarms, and authorize RDS access.

Minimum search permissions

To test document retrieval by sending search requests to an application using the SDK, you need permissions to search that application. The following example grants permissions to perform a document retrieval test on an application named app_schema_demo.

{
    "Statement": [
    {
            "Effect": "Allow",
            "Action": "opensearch:SearchApp",
            "Resource": "acs:opensearch:*:*:apps/app_schema_demo"
        }
    ],
    "Version": "1"
}

Application list permissions

A RAM user needs the following permissions to view the application list in the console.

{
    "Statement": [
        {
            "Action": [
                "opensearch:ListAppGroup",
                "opensearch:DescribeAppStatistics",
                "opensearch:ListAppGroupErrors"
            ],
            "Effect": "Allow",
            "Resource": "acs:opensearch:*:*:app-groups/*"
        }
    ],
    "Version": "1"
}

Application detail permissions

Because the monitoring and alarms features are integrated into the application details page, a RAM user must have permission to view application details to use these features. The following example grants permissions to view the details of the application named app_schema_demo.

{
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "opensearch:DescribeAppGroup",
                "opensearch:ListApp",
                "opensearch:DescribeApp"
            ],
            "Resource": "acs:opensearch:*:*:app-groups/app_schema_demo"
        },
        {
            "Action": "opensearch:ListUserAnalyzers",
            "Effect": "Allow",
            "Resource": "acs:opensearch:*:*:user-analyzers/*"
        }
    ],
    "Version": "1"
}

Monitoring and alarms permissions

The monitoring and alarms feature is built on CloudMonitor. You can find the read-only policy for CloudMonitor by searching for AliyunCloudMonitorReadOnlyAccess in the RAM policy templates.

{
    "Version": "1",
    "Statement": [
        {
            "Action": [
                "cms:Get*",
                "cms:List*",
                "cms:Query*",
                "cms:BatchQuery*"
            ],
            "Resource": "*",
            "Effect": "Allow"
        },
        {
            "Action": "opensearch:DescribeApp",
            "Resource": "acs:opensearch:*:*:app-groups/*",
            "Effect": "Allow"
        }
    ]
}

RDS access authorization

Accessing an RDS data source involves the tables and fields APIs. Because connecting to RDS requires adding an IP address to the IP whitelist, you must also grant the RAM user permission to modify the IP whitelist. Without this permission, the connection to RDS will fail with an error indicating that the RDS IP whitelist could not be set. You can configure RDS permissions directly in the RAM console. On the Overview page, create a custom authorization policy or assign a role, and then attach the policy to the RAM user on the User Management page (see the RDS authorization documentation). The following policy shows the minimum permission set required for OpenSearch to access RDS:

Read Learn about the meaning of variables to understand the variables, such as $regionid, $accountid, and $dbinstanceid, in the Resource element.

You can also use the wildcard character * for parameter values in the Resource element.

{
  "Version": "1",
  "Statement": [
      {
          "Action": "rds:DescribeDBInstanceAttribute",
          "Resource": "acs:rds:$regionid:$accountid:dbinstance/$dbinstanceid",
          "Effect": "Allow"
      },
      {
          "Action": "rds:ModifySecurityIps",
          "Resource": "acs:rds:$regionid:$accountid:dbinstance/$dbinstanceid",
          "Effect": "Allow"
      },
      {
          "Action": "rds:DescribeDBInstanceIPArrayList",
          "Resource": "acs:rds:$regionid:$accountid:dbinstance/$dbinstanceid",
          "Effect": "Allow"
      },
      {
          "Action": "rds:DescribeDBInstanceNetInfoForChannel",
          "Resource": "acs:rds:$regionid:$accountid:dbinstance/$dbinstanceid",
          "Effect": "Allow"
      }
  ]
}

Runtime API permissions

To make API calls for search, data push, and suggestions, add the following permissions.

{
	"Statement": [
	 {
	  "Effect": "Allow",
	  "Action": [
	   "opensearch:PushDoc",
	   "opensearch:SearchApp"
	  ],
	  "Resource": [
	   "acs:opensearch:$regionId:*:apps/$appGroupName",
	   "acs:opensearch:$regionId:*:app-groups/$appGroupName"
	  ]
	 },
	 {
	  "Action": "opensearch:SearchSuggest",
	  "Effect": "Allow",
	  "Resource": "acs:opensearch:$regionId:*:suggestions/$suggestionIdentity"
	 }
	],
	"Version": "1"
   }

Authorization examples

To allow a RAM user to perform tasks in the console, you typically need to grant a combination of Action permissions. You can grant broad permissions such as Describe* and List*, or you can create a more specific set of permissions tailored to your needs.

Example 1

Grant a RAM user under the main account 1234 full permissions for all applications in all regions. After you create this policy, you must attach it to the RAM user in the RAM console or by using the RAM SDK. 1. Create a policy.

{
  "Statement": [
    {
      "Action": "opensearch:*",
      "Effect": "Allow",
      "Resource": "acs:opensearch:*:1234:apps/*"
    }
  ],
  "Version": "1"
}

2. Attach the policy to the specified RAM user.

Example 2

Grant a RAM user under the main account 1234 full permissions for all applications in the China (Hangzhou) region (cn-hangzhou). After you create this policy, you must attach it to the RAM user in the RAM console or by using the RAM SDK.

1. Create a policy.

{
  "Statement": [
    {
      "Action": "opensearch:*",
      "Effect": "Allow",
      "Resource": "acs:opensearch:cn-hangzhou:1234:apps/*"
    }
  ],
  "Version": "1"
}

2. Attach the policy to the specified RAM user.

Note

Note:

If you use the wildcard character (*) in the resource format, it matches all resource types.
If you specify a specific application name in the resource format, an Action of opensearch:* grants permissions only for actions related to that application. It does not include permissions for opensearch:ListApp or opensearch:CreateApp.
Each Action must correspond to the correct resource format. For example, opensearch:ListApp and opensearch:CreateApp apply to all applications and require the resource to be specified as *. Note that these two actions use a different resource format than other actions.
If your authorization policy only includes resources for specific applications but you also need opensearch:ListApp and opensearch:CreateApp permissions, you must create an additional policy that includes these two actions with the resource format as * and attach it to the RAM user.

Troubleshoot console authentication issues

When a RAM user accesses the console, a "RAM user authentication failed" message may appear. Click Error Details in the dialog box to see detailed request information, including the REQUEST_ID, METHOD, URL, PARAMS, BODY, and RESPONSE fields. To resolve the issue:

In the PARAMS field of the error details, find the requested POP Action, for example, ListAppGroups. If the action has a DryRun suffix, such as CreateAppDryRun, the corresponding action is the one without the suffix (CreateApp).
In the Application authorization rule list, find the corresponding RAM Action and Resource Pattern for ListAppGroups. (Note: The RAM Action may not be the same as the POP Action.)
Create an authorization policy with the required permissions and attach it to the RAM user.