How Resource Explorer works with IAM - Amazon Resource Explorer
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China.

How Resource Explorer works with IAM

Before you use IAM to manage access to Amazon Resource Explorer, you should understand what IAM features are available to use with Resource Explorer. To get a high-level view of how Resource Explorer and other Amazon Web Services work with IAM, see Amazon Web Services that work with IAM in the IAM User Guide.

Like any other Amazon Web Service, Resource Explorer requires permissions to use its operations to interact with your resources. To search, users must have permission to retrieve the details about a view, and also to search using the view. To create indexes or views, or to modify them or any other Resource Explorer settings, you must have additional permissions.

Attach IAM identity-based policies to your roles and users that grant those permissions. Resource Explorer provides several managed policies that pre-define common sets of permissions and attach them to your IAM groups, roles, and users.

Resource Explorer identity-based policies

With IAM identity-based policies, you can specify allowed or denied actions against specific resources and the conditions under which those actions are allowed or denied. Resource Explorer supports specific actions, resources, and condition keys. To learn about all of the elements that you use in a JSON policy, see IAM JSON policy elements reference in the IAM User Guide.


Administrators can use Amazon JSON policies to specify who has access to what. That is, which principal can perform actions on what resources, and under what conditions.

The Action element of a JSON policy describes the actions that you can use to allow or deny access in a policy. Policy actions usually have the same name as the associated Amazon API operation. There are some exceptions, such as permission-only actions that don't have a matching API operation. There are also some operations that require multiple actions in a policy. These additional actions are called dependent actions.

Include actions in a policy to grant permissions to perform the associated operation.

Policy actions in Resource Explorer use the resource-explorer-2 service prefix before the action. For example, to grant someone permission to search using a view, with the Resource Explorer Search API operation, you include the resource-explorer-2:Search action in their policy. Policy statements must include either an Action or NotAction element. Resource Explorer defines its own set of actions that describe tasks that you can perform with this service. These align with the Resource Explorer API operations.

To specify multiple actions in a single statement, separate them with commas as shown in the following example.

"Action": [ "resource-explorer-2:action1", "resource-explorer-2:action2" ]

You can specify multiple actions using wildcard characters (*). For example, to specify all actions that begin with the word Describe, include the following action.

"Action": "resource-explorer-2:Describe*"

For a list of Resource Explorer actions, see Actions Defined by Amazon Resource Explorer in the Amazon Service Authorization Reference.


Administrators can use Amazon JSON policies to specify who has access to what. That is, which principal can perform actions on what resources, and under what conditions.

The Resource JSON policy element specifies the object or objects to which the action applies. Statements must include either a Resource or a NotResource element. As a best practice, specify a resource using its Amazon Resource Name (ARN). You can do this for actions that support a specific resource type, known as resource-level permissions.

For actions that don't support resource-level permissions, such as listing operations, use a wildcard (*) to indicate that the statement applies to all resources.

"Resource": "*"


The primary Resource Explorer resource type is the view.

The Resource Explorer view resource has the following ARN format.


The Resource Explorer ARN format is shown in the following example.


The ARN for a view includes a unique identifier at the end to ensure that every view is unique. This helps ensure that an IAM policy that granted access to an old, deleted view doesn't accidentally grant access to a new view that happens to have the same name. Every new view receives a new, unique ID at the end to ensure that ARNs are never reused.

For more information about the format of ARNs, see Amazon Resource Names (ARNs).

You use IAM identity-based policies attached to the individual roles and users, or groups of them and specify the view as the Resource. Doing this lets you grant search access through one view to one set of roles and users, and access through a completely different view to a different set of roles and users.

For example, to grant permission to a single view named ProductionResourcesView in an IAM policy statement, first get the Amazon resource name (ARN) of the view. You can use the Views page in the console to view the details of a view, or invoke the ListViews operation to retrieve the full ARN of the view you want. Then, include it in a policy statement, like that shown in the following example that grants permission to modify the definition of only one view.

"Effect": "Allow", "Action": "UpdateView", "Resource": "arn:aws:resource-explorer-2:cn-north-1:123456789012:view/ProductionResourcesView/<unique-id>"

To allow the actions on all views that belong to a specific account, use the wildcard character (*) in the relevant part of the ARN. The following example grants search permission to all views in a specified Amazon Web Services Region and account.

"Effect": "Allow", "Action": "Search", "Resource": "arn:aws-cn:resource-explorer-2:cn-north-1:123456789012:view/*"

Some Resource Explorer actions, such as CreateView, aren't performed against a specific resource, because, as in the following example, the resource doesn't exist yet. In such cases, you must use the wildcard character (*) for the entire resource ARN.

"Effect": "Allow", "Action": "resource-explorer-2:CreateView" "Resource": "*"

If you specify a path that ends in a wildcard character, then you can restrict the CreateView operation to creating views with the approved path. The following example policy piece shows how to allow the user to create views only under the path view/ProductionViews/.

"Effect": "Allow", "Action": "resource-explorer-2:CreateView" "Resource": "arn:aws-cn:resource-explorer-2:cn-north-1:123456789012:view/ProductionViews/*""


Another resource type that you can use to control access to Resource Explorer functionality is the index.

The primary way that you interact with the index is to turn on Resource Explorer in an Amazon Web Services Region by creating an index in that Region. After that, you do almost everything else by interacting with the view.

One thing that you can do with the index is to control who can create views in each Region.


After you create a view, IAM authorizes all other view actions against only the ARN of the view, and not the index.

The index has an ARN that you can reference in a permission policy. A Resource Explorer index ARN has the following format.


See the following example of an Resource Explorer index ARN.


Some Resource Explorer actions check authentication against multiple resource types. For example, the CreateView operation authorizes against both the ARN of the index and the ARN of the view as it will be after Resource Explorer creates it. To grant administrators permission to manage the Resource Explorer service, you can use "Resource": "*" to authorize actions for any resource, index, or view.

Alternatively, you can restrict a user to only being able to work with specified Resource Explorer resources. For example, to limit actions to only Resource Explorer resources in a specified Region, you can include an ARN template that matches both the index and the view, but calls out only a single Region. In the following example, the ARN matches only indexes or views in only the us-west-2 Region of the specified account. Specify the Region in the third field of the ARN, but use a wildcard character (*) in the final field to match any resource type.

"Resource": "arn:aws-cn:resource-explorer-2:us-west-2:123456789012:*

For more information, see Resources Defined by Amazon Resource Explorer in the Amazon Service Authorization Reference. To learn with which actions you can specify the ARN of each resource, see Actions Defined by Amazon Resource Explorer.

Condition keys

Resource Explorer doesn't provide any service-specific condition keys, but it does support using some global condition keys. To see all Amazon global condition keys, see Amazon global condition context keys in the IAM User Guide.

Administrators can use Amazon JSON policies to specify who has access to what. That is, which principal can perform actions on what resources, and under what conditions.

The Condition element (or Condition block) lets you specify conditions in which a statement is in effect. The Condition element is optional. You can create conditional expressions that use condition operators, such as equals or less than, to match the condition in the policy with values in the request.

If you specify multiple Condition elements in a statement, or multiple keys in a single Condition element, Amazon evaluates them using a logical AND operation. If you specify multiple values for a single condition key, Amazon evaluates the condition using a logical OR operation. All of the conditions must be met before the statement's permissions are granted.

You can also use placeholder variables when you specify conditions. For example, you can grant an IAM user permission to access a resource only if it is tagged with their IAM user name. For more information, see IAM policy elements: variables and tags in the IAM User Guide.

Amazon supports global condition keys and service-specific condition keys. To see all Amazon global condition keys, see Amazon global condition context keys in the IAM User Guide.

To see a list of the condition keys that you can use with Resource Explorer, see Condition Keys for Amazon Resource Explorer in the Amazon Service Authorization Reference. To learn which actions and resources you can use a condition key with, see Actions Defined by Amazon Resource Explorer.


To view examples of Resource Explorer identity-based policies, see Amazon Resource Explorer identity-based policy examples.

Authorization based on Resource Explorer tags

You can attach tags to Resource Explorer views or pass tags in a request to Resource Explorer. To control access based on tags, you provide tag information in the condition element of a policy using the resource-explorer-2:ResourceTag/key-name, aws:RequestTag/key-name, or aws:TagKeys condition keys. For more information about tagging Resource Explorer resources, see Adding tags to views. For using tag-based authorization in Resource Explorer, see Using tag-based authorization to control access to your views.

Resource Explorer IAM roles

An IAM role is an entity within your Amazon Web Services account that has specific permissions.

Using temporary credentials with Resource Explorer

You can use temporary credentials to sign in with federation, assume an IAM role, or to assume a cross-account role. You obtain temporary security credentials by calling Amazon Security Token Service (Amazon STS) API operations such as AssumeRole or GetFederationToken.

Resource Explorer supports using temporary credentials.

Service-linked roles

Service-linked roles allow Amazon Web Services to access resources in other services to complete an action on your behalf. Service-linked roles appear in your IAM account and are owned by the service. An IAM administrator can view but not edit the permissions for service-linked roles.

Resource Explorer uses service-linked roles to perform its work. For details about Resource Explorer service-linked roles, see Using service-linked roles for Resource Explorer.