# Working with views A *view* is the mechanism used to query the resources listed in an index. The view defines what information in the index is visible and available for search and discovery purposes. A user never directly queries the Resource Explorer index. Instead, queries must always go through a view which lets the view creator limit which resources the user can see in search results. ## Granting access to a view Resource Explorer provides three types of views: User views, AWS managed views, and AWS service views. **User views** User views are created and managed by users or administrators. When automatic setup occurs, Resource Explorer creates user-owned default views that include tags for comprehensive filtering capabilities. **AWS service views** A [service view](aws-service-views.md) is a pre-defined view owned and managed by AWS services (not customer accounts) in AWS Resource Explorer that enables controlled access to resource data. A Resource Explorer-owned view is a type of service view that acts as a fallback when no user-owned default view exists in a Region. These views cannot be modified or deleted by users and provide basic search functionality through Resource Explorer-owned indexes. **AWS managed views** A [managed view](aws-managed-views.md) provides other AWS services with the ability to access resource information indexed by Resource Explorer for your AWS account or organization with your consent. Views are stored on a per-Region basis. A view can access only the Resource Explorer index in that AWS Region. To access account-wide search results, you must use a view in the Region that contains the *aggregator index* for the account. The **Quick setup** option creates a default view in the AWS Region with the aggregator index and with filters that include all resources in all AWS Regions used by the account. For information about how to create views, see [Configuring a Resource Explorer view to provide access to resource searches](customer-views.md#configure-views). For information about how to use views in a query, see [Using AWS Resource Explorer to search for resources](using-search.md). Every view has an [Amazon resource name (ARN)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) that you can reference in permission policies to grant access to individual views. You can also pass a view's ARN as a parameter to any API or AWS CLI operation that interacts with a view. The ARN of a view looks similar to the following example. ``` arn:aws:resource-explorer-2:us-east-1:123456789012:view/My-View-Name/1a2b3c4d-5d6e-7f8a-9b0c-abcd11111111 ``` **Note** Every view ARN includes an AWS generated UUID at the end. This helps to ensure that users who might have had access to views with a specific name that was deleted can't automatically access a new view created with the same name. ## Comparison of view types The following table compares the different types of views available in Resource Explorer: | Feature | User Views | Managed Views | Service Views | | --- | --- | --- | --- | | Created by | User | AWS Service (per account) | AWS Service (global) | | Can user modify | Yes | No | No | | Can user delete | Yes | Via service only | No | | Requires user setup | Yes | Service manages | No | | Access to config/relationship data | No | Yes | Yes | | Streaming support | No | No | Yes | # User views User views are created and managed by users or administrators. When automatic setup occurs, Resource Explorer creates user-owned default views that include tags for comprehensive filtering capabilities. When you create a view, you specify filters that restrict which resources are included in search results. For example, you could choose to include only resources of a few specified resource types that are used by those to whom you grant access to this view. Results from queries that users make with a view are always automatically filtered to include only those resources that match the view's criteria. To grant access to use a view, you can use assign permissions using one of the following methods. To provide access, add permissions to your users, groups, or roles: + Users and groups in AWS IAM Identity Center: Create a permission set. Follow the instructions in [Create a permission set](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html) in the *AWS IAM Identity Center User Guide*. + Users managed in IAM through an identity provider: Create a role for identity federation. Follow the instructions in [Create a role for a third-party identity provider (federation)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html) in the *IAM User Guide*. + IAM users: + Create a role that your user can assume. Follow the instructions in [Create a role for an IAM user](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html) in the *IAM User Guide*. + (Not recommended) Attach a policy directly to a user or add a user to a user group. Follow the instructions in [Adding permissions to a user (console)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) in the *IAM User Guide*. Grant permission to allow your roles, groups, or users to invoke the `resource-explorer-2:GetView` and `resource-explorer-2:Search` operations on a view identified by its [Amazon resource name (ARN)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html). Alternatively, you can use the [Resource Explorer read only AWS managed policy](security_iam_awsmanpol.md#security_iam_awsmanpol_AWSResourceExplorerReadOnlyAccess) for all principals who need to use the view to search. You can create multiple views that have different filters and scopes and thus return different subsets of your resource information. Then, you can grant permissions for each view to those users who need to see the information included by that view's results. ## Configuring a Resource Explorer view to provide access to resource searches Views are the key to searching for your resources. Every AWS Resource Explorer search operation must use a view. Views are the method the administrator can use to control access to the information about resources in your AWS account. A view can be accessed by only principals (IAM roles or users) that have permission to use that view. To search successfully with Resource Explorer, a principal must have `Allow` access to both the `resource-explorer-2:GetView` and `resource-explorer-2:Search` operations on the view's [ARN](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html). Views contain built-in filters that the administrator can use to limit results to only items of interest. For example, you can create a view that includes only resources related to a certain project. Users who don't need to see information about other projects can use this view to see only those resources of interest. A view is a Regional resource. The view is created and stored in a specific AWS Region and returns in its results only information from the index in that Region. To include results from across all Regions in the account, the view must reside in the Region that contains the [aggregator index](getting-started-terms-and-concepts.md#term-aggr-index). That Region contains a replica of the indexes from all other Regions in the account. There are several key elements to every view: **Permissions to search** You can use standard AWS permission policies to control who can use each view. This is provided by [identity-based permission policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_id-based) attached to the principals that give you granular control over who can see the information provided by each view. For example, you can grant access to the `Production-resources` view to allow searching only by the engineers that operate your production services. Then, you can grant different permissions to the `Pre-production-resources` view to allow searching for pre-production resources by your developers. If you use the AWS managed policy named `AWSResourceExplorerReadOnlyAccess` with your principals, it grants them the ability to search using any view in the account. Alternatively, you can create your own permissions policy and grant the following permissions for only specified views: + `resource-explorer-2:GetView` + `resource-explorer-2:Search` To provide access, add permissions to your users, groups, or roles: + Users and groups in AWS IAM Identity Center: Create a permission set. Follow the instructions in [Create a permission set](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html) in the *AWS IAM Identity Center User Guide*. + Users managed in IAM through an identity provider: Create a role for identity federation. Follow the instructions in [Create a role for a third-party identity provider (federation)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html) in the *IAM User Guide*. + IAM users: + Create a role that your user can assume. Follow the instructions in [Create a role for an IAM user](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html) in the *IAM User Guide*. + (Not recommended) Attach a policy directly to a user or add a user to a user group. Follow the instructions in [Adding permissions to a user (console)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) in the *IAM User Guide*. For more information about permissions related to views, see [Granting access to Resource Explorer views for search](configure-views-grant-access.md). **Filtering the search** A view serves as a virtual window through which the user can see the resources in the account. You can create multiple views, each presenting a different view of the larger picture. For example, you can create a view that allows searching only resources associated with your pre-production environment, as identified by tags attached to your resources. Then, you could create a separate view that allows searching only resources in your production environment, based on different values in the tags. If you configure multiple views with different `FilterString` values, you don't have to re-enter those query parameters every time you [Search](https://docs.aws.amazon.com/resource-explorer/latest/apireference/API_Search.html). Views also can specify which optional pieces of information about the resources to include in the results. The default list of fields is always included in results. In addition to the default list, you can request that the view also include any tags attached to the resource. **Scope of the search** + **Region scope** – When you search in an AWS Region with Resource Explorer, the results can include only resources that are indexed in that Region. The index in most Regions is labelled `LOCAL` because it contains information about resources within only that Region. Searches in those Regions can return only those resources. + **Account scope** – You can promote one local index to be the aggregator index for the account. When you do this, all other Regions where Resource Explorer is turned on replicate their index information to the Region with the aggregator index. If you search in that Region, those results include resources from all Regions with user-owned (local) indexes in the account. When you use the **Quick Setup** option to configure the server, Resource Explorer automatically creates an aggregator index in the Region you specify. Also, the **Quick Setup** option creates a default view in that Region to support searching all resources in the account across all Regions with user-owned (local) indexes. ### Default views If a user attempts to search without explicitly specifying a view, Resource Explorer uses the *default view* defined for that AWS Region. Resource Explorer automatically creates a default view as follows: + If you turn on Resource Explorer using the AWS Management Console and choose the **Quick setup** option, you must specify which Region contains the aggregator index for the account. Resource Explorer automatically creates a default view in the specified aggregator index Region. + If you register Resource Explorer using the AWS Management Console and choose the **Advanced setup** option, you can *optionally* choose to create the aggregator index for the account in a specified Region. If you do this, Resource Explorer creates a default view automatically in the aggregator index Region. + If you register Resource Explorer by using the console and choose *not* to register an aggregator index Region, Resource Explorer creates a default view for the local index in each Region. + If you register Resource Explorer by using the AWS CLI or the API operations, Resource Explorer doesn't automatically create a default view. Instead, you must configure the default view manually for each Region where you expect users to search from. **Topics** + [ ## Configuring a Resource Explorer view to provide access to resource searches ](#configure-views) + [ # Creating Resource Explorer views to use for search ](configure-views-create.md) + [ # Granting access to Resource Explorer views for search ](configure-views-grant-access.md) + [ # Setting a default view in an AWS Region ](configure-views-set-default.md) + [ # Adding tags to views ](configure-views-tag.md) + [ # Sharing Resource Explorer views ](configure-views-share.md) + [ # Deleting views in Resource Explorer ](configure-views-delete.md) # Creating Resource Explorer views to use for search All searches must use a [*view*](customer-views.md#configure-views). A view defines filters that determine which resources can be returned by queries that use the view. Views also control who can search for resources. ****Resource Explorer-owned views**** Resource Explorer provides Resource Explorer-owned views that are service-managed and cannot be modified or deleted by users. These views serve as automatic fallbacks to ensure search functionality remains available even when no user-owned views exist in a Region. Resource Explorer-owned views do not include resource tags in search results. When automatic setup occurs, Resource Explorer creates a default user-owned view in each Region that includes Tags. The view hierarchy follows this priority: user-owned views are used first, with automatic fallback to Resource Explorer-owned views when no user-owned view is available. A view is stored in an AWS Region, and returns search results from only that Region's index. If the Region contains the [aggregator index](manage-aggregator-region.md), then the view returns search results from the user-owned index in every Region in the account. Multi-account views allow you to search for resources in accounts across your organization. Only the management account, or a delegated administrator for the organization, can create a multi-account view. Resource Explorer can create a default view for you during initial set up if you chose the relevant options in either [Quick Setup](https://console.aws.amazon.com/systems-manager/quick-setup/create-configuration?configurationType=AWSQuickSetupType-ResourceExplorer) for Resource Explorer in the Systems Manager console. At any later time, you can create additional views that have different filters for different sets of users. You can create a view by using the AWS Management Console or by running AWS CLI commands or their equivalent API operations in an AWS SDK. **Minimum permissions** To run this procedure, you must have the following permissions. Note that with Resource Explorer's automatic setup, view creation is optional since Resource Explorer-owned views provide fallback search functionality: + **Action:** `resource-explorer-2:CreateView` **Resource:** This can be `*` to allow creation of a view in any AWS Region in the account. + **When view creation is needed:** While Resource Explorer automatically creates default views during setup and provides Resource Explorer-owned views as fallbacks, you may want to create custom views for specific filtering requirements, tag-based searches, or to control access permissions for different user groups. ------ #### [ AWS Management Console ] **To create a view** 1. Open the Resource Explorer console **[Views](https://console.aws.amazon.com/resource-explorer/home#/views)** page and choose **Create view**. 1. On the **Create view** page, for **Name**, enter a name for the view. The name must be no more than 64 characters long, and can include letters, digits, and the hyphen (-) character. The name must be unique within its AWS Region. 1. Choose the AWS Region in which you want to create the view. To create a view that returns resources from all Regions in the account, choose the AWS Region that contains the aggregator index. 1. (Optional) For **Scope**, choose whether your search returns multi-account resources, or returns resources only from your account. Account level scope is the default. Only the management account or delegated administrator can see the option to create a multi-account view. 1. Choose whether to filter the results. + **Include all resources** No query filters are included. All resources in the index associated with the view can be returned in search results. + **Include only resources that match a specified filter** Turns on the **Resource filters** check box where you can choose filter *names* and *operators*. For an explanation of each of the available filter names and operators, see [Filters](using-search-query-syntax.md#query-syntax-filters). + Choose the optional resource attributes to include in results from this view. Select the check box next to **Tags** to let users search for resources based on their tag key names and values. If you don't include tags in the view then users can't make search requests that use tag keys and values to further filter the results. + Optionally, you can attach tags to the view. Expand the **Tags** box, and enter up to 50 tag key/value pairs. You can use tags to categorize resources, or as part of an attribute-based access control (ABAC) security permission strategy. For more information, see [Adding tags to views](configure-views-tag.md). + Choose **Create view**. The console returns to the **Search** page where you can use your new view to perform a search. **Next step:** Grant the principals in your account permissions to search with your new view. For more information, see [Granting access to Resource Explorer views for search](configure-views-grant-access.md) ------ #### [ AWS CLI ] **To create a view** Run the following command to create a view in the specified AWS Region. The following example creates a view that returns only resources related to the Amazon EC2 service that are tagged with a `Stage` key and the value `prod`. ``` $ aws resource-explorer-2 create-view \ --region us-west-2 \ --view-name "My-EC2-Prod-Resources" \ --filters FilterString="service:ec2 tag:stage=prod" \ --included-properties Name=tags { "View": { "Filters": { "FilterString": "service:ec2 tag:stage=prod" }, "IncludedProperties": [ { "Name": "tags" } ], "LastUpdatedAt": "2022-08-03T16:13:37.625000+00:00", "Owner": "123456789012", "Scope": "arn:aws:iam::123456789012:root", "ViewArn": "arn:aws:resource-explorer-2:us-west-2:123456789012:view/My-EC2-Prod-Resources/1a2b3c4d-5d6e-7f8a-9b0c-abcd11111111" } } ``` **To create an organization level view** The following example creates a view that returns resources from across your organization. This must be performed by the organization's management account, or a delegated administrator account. 1. Run the `aws organizations describe-organization` command to get your organization ARN. 1. Run the following command to create a view for the specified organization. ``` $ aws resource-explorer-2 create-view \ --region us-west-2 \ --view-name entire-org-view \ --scope "arn:aws:organizations::111111111111:organization/o-exampleorgid" { "View": { "Filters": { "FilterString": "" }, "IncludedProperties": [], "LastUpdatedAt": "2022-08-03T16:13:37.625000+00:00", "Owner": "111111111111", "Scope": "arn:aws:organizations::111111111111:organization/o-exampleorgid", "ViewArn": "arn:aws:resource-explorer-2:us-west-2:111111111111:view/entire-org-view/1a2b3c4d-5d6e-7f8a-9b0c-abcd11111111" } } ``` **To create an organizational unit level view** The following example creates a view that returns resources from all members of this organizational unit. This view behaves similarly to an organizational level view. This must be performed by the organization's management account, or a delegated administrator account. 1. Run the `aws organizations describe-organizational-unit` command to get your organization ARN. 1. Run the following command to create a view for the specified organizational unit. ``` $ aws resource-explorer-2 create-view \ --region us-west-2 \ --view-name entire-ou-view \ --scope "arn:aws:organizations::222222222222:ou/o-exampleorgid/ou-exampleouid" { "View": { "Filters": { "FilterString": "" }, "IncludedProperties": [], "LastUpdatedAt": "2022-08-03T16:13:37.625000+00:00", "Owner": "222222222222", "Scope": "arn:aws:organizations::222222222222:ou/o-exampleorgid/ou-exampleouid", "ViewArn": "arn:aws:resource-explorer-2:us-west-2:222222222222:view/entire-ou-view/1a2b3c4d-5d6e-7f8a-9b0c-abcd11111111" } } ``` **Next step:** Grant the principals in your account permissions to search with your new view. For more information, see [Granting access to Resource Explorer views for search](configure-views-grant-access.md) ------ # Granting access to Resource Explorer views for search Before users can search with a new view, you must grant access to AWS Resource Explorer views. To do this, use an identity-based permission policy to the AWS Identity and Access Management (IAM) principals that need to search with the view. To provide access, add permissions to your users, groups, or roles: + Users and groups in AWS IAM Identity Center: Create a permission set. Follow the instructions in [Create a permission set](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html) in the *AWS IAM Identity Center User Guide*. + Users managed in IAM through an identity provider: Create a role for identity federation. Follow the instructions in [Create a role for a third-party identity provider (federation)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html) in the *IAM User Guide*. + IAM users: + Create a role that your user can assume. Follow the instructions in [Create a role for an IAM user](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html) in the *IAM User Guide*. + (Not recommended) Attach a policy directly to a user or add a user to a user group. Follow the instructions in [Adding permissions to a user (console)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) in the *IAM User Guide*. You can use either of the following methods: + **Use an existing AWS managed policy**. Resource Explorer provides several pre-defined AWS managed policies for your use. For details of all of the available AWS managed policies, see [AWS managed policies for AWS Resource Explorer](security_iam_awsmanpol.md). For example, you could use the `AWSResourceExplorerReadOnlyAccess` policy to grant search permissions to all views in the account. + **Create your own permission policy and assign it to the principals**. If you create your own policy, you can restrict access to a single view, or a subset of the available views by specifying the [Amazon resource name (ARN)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) of each view in the `Resource` element of the policy statement. For example, You can use the following example policy to grant that principal the ability to search using only that one view. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "resource-explorer-2:Search", "resource-explorer-2:GetView" ], "Resource": "arn:aws:resource-explorer-2:us-east-1:123456789012:view/MyTestView/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" } ] } ``` ------ Use the IAM console to create the permission policies and to use them with the principals that need those permissions. For more information about IAM permission policies, see the following topics: + [Policies and permissions in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) + [Adding and removing IAM identity permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) + [Understanding permissions granted by a policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_understand.html) ## Using tag-based authorization to control access to your views If you choose to create multiple views with filters that return results with only certain resources, then you might also want to restrict access to those views to only the principals who need to see those resources. You can provide this type of security for the views in your account by using an [attribute-based access control (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) strategy. The *attributes* used by ABAC are the tags attached both to the principals attempting to perform operations in AWS and to the resources they attempt to access. ABAC uses standard IAM permission policies attached to the principals. The policies use `Condition` elements in the policy statements to allow access only when both the tags attached to the requesting principal and the tags attached to the affected resource match the requirements in the policy. For example, you could attach a tag `"Environment" = "Production"` to all of the AWS resources that support your company's production application. To ensure that only principals that are authorized to access the production environment can see those resources, create a Resource Explorer view that uses that tag as a [filter](using-search-query-syntax.md#query-syntax-filters). Then, to restrict access to the view to only the appropriate principals, you grant permissions using a policy that has a condition similar to the following example elements. ``` { "Effect": "Allow", "Action": [ "service:Action1", "service:Action2" ], "Resource": "arn:aws:arn-of-a-resource", "Condition": { "StringEquals": {"aws:ResourceTag/Environment": "${aws:PrincipalTag/Environment}"} } } ``` That `Condition` in the previous example specifies that the request is allowed ***only*** if the `Environment` tag attached to the principal making the request matches the `Environment` tag attached to the resource specified in the request. If those two tags don't exactly match, or if either tag is missing, then the Resource Explorer denies the request. **Important** To successfully use ABAC to secure access to your resources, you must first restrict access to the ability to add or modify the tags attached to your principals and resources. If a user can add or modify the tags attached an AWS principal or resource then that user can affect the permissions controlled by those tags. In a secure ABAC environment, only approved security administrators have permission to add or modify the tags attached to principals, and only security administrators and resource owners can add or modify the tags attached to resources. For more information about how to successfully implement an ABAC strategy, see the following topics in the *IAM User Guide*: + [IAM tutorial: Define permissions to access AWS resources based on tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) + [Controlling access to AWS resources using tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html) After you have the necessary ABAC infrastructure in place, you can use start using tags to control who can search using the Resource Explorer views in your account. For example policies that illustrate the principle, see the following example permission policies: + [Granting access to a view based on tags](security_iam_id-based-policy-examples.md#security_iam_id-based-policy-examples-abac-views) + [Granting access to create a view based on tags](security_iam_id-based-policy-examples.md#security_iam_id-based-policy-examples-abac-createview) # Setting a default view in an AWS Region In AWS Resource Explorer, you can define many views in an AWS Region, where each view addresses different search requirements. We recommend that you set ***one*** view in each Region as the *default view* for that Region. Resource Explorer automatically creates default user-owned views during setup that include Tags for enhanced search functionality. If no user-owned view exists in a Region, Resource Explorer automatically falls back to using a Resource Explorer-owned view to ensure search functionality remains available. Resource Explorer-owned views are service-managed and cannot be modified or deleted, and they do not include resource tags in search results. Resource Explorer uses the default view whenever a user performs a search and doesn't explicitly specify which view to use. The [Unified Search](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/using-search.html) bar at the top of every AWS Management Console page uses the default view in the aggregator Region if an aggregator index exists, or the default view in the current Region if no aggregator is configured. This provides regional search results without requiring cross-region setup. You can select only a view that exists in the Region to be that Region's default view. If another Region has a view that you want to use, you must first create a copy of that view in the Region in which you want to make it the default view. **Tip** There is no *copy view* operation. You must create a view in the target Region and then copy the settings from the existing view to the new view. You can specify a view as the default for its Region by using the AWS Management Console or by running AWS CLI commands or their equivalent API operations in an AWS SDK. ------ #### [ AWS Management Console ] **To set a default view** 1. On the Resource Explorer **[Views](https://console.aws.amazon.com/resource-explorer/home#/views)** page, choose the option button next to the view that you want to make the default for its Region. 1. Choose **Actions**, then choose **Set as default** or set as default in the **Default** column. ------ #### [ AWS CLI ] **To set a default view** Run the following command to set the specified view as the default for its Region. The following example sets the specified view to be the default for all searches performed in the us-east-1 Region. That view must exist in the Region in which you run the command. ``` $ aws resource-explorer-2 associate-default-view \ --region us-east-1 \ --view-arn arn:aws:resource-explorer-2:us-east-1:123456789012:view/MyViewName/1a2b3c4d-5d6e-7f8a-9b0c-abcd11111111 { "ViewArn": "arn:aws:resource-explorer-2:us-east-1:123456789012:view/MyViewName/1a2b3c4d-5d6e-7f8a-9b0c-abcd11111111" } ``` ------ # Adding tags to views You can add tags to your views to categorize them. Tags are customer-supplied metadata that take the form of a key name string and an associated optional value string. For general information about tagging AWS resources, see [Tagging AWS Resources](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) in the *Amazon Web Services General Reference*. ## Add tags to your views You can add tags to your Resource Explorer views by using the AWS Management Console or by running AWS CLI commands or their equivalent API operations in an AWS SDK. ------ #### [ AWS Management Console ] **To add tags to a view** 1. Open the Resource Explorer **[Views](https://console.aws.amazon.com/resource-explorer/home#/views)** page and choose the name of the view that you want to tag to display its **Details** page. 1. Under **Tags**, choose **Manage tags**. 1. To add a tag, choose **Add tag** and then enter a tag key name and optional value. **Note** You can also delete a tag by choosing the **X** next to the tag. You can attach up to 50 user-defined tags to a resource. Any tags that are created and managed automatically by AWS don't count against this quota. 1. When you're done with all tag changes, choose **Save changes**. ------ #### [ AWS CLI ] **To add tags to a view** Run the following command to add tags to a view. The following example add tags with the key name `environment` and the value `production` to the specified view. ``` $ aws resource-explorer-2 tag-resource \ --resource-id arn:aws:resource-explorer-2:us-east-1:123456789012:view/MyViewName/1a2b3c4d-5d6e-7f8a-9b0c-abcd11111111 \ --tags environment=production ``` The preceding command produces no output if it succeeds. **Note** To remove an existing tag from a view, use the `untag-resource` command. ------ ## Controlling permissions with tags One key use of tagging is to support an [attribute-based access control (ABAC) strategy](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html). ABAC can help simplify permission management by letting you tag resources. Then, you grant permission to users for resources that are tagged a certain way. For example, consider this scenario. For a view called `ViewA`, you attach the tag `environment=prod` (*key name=value*). Another `ViewB` might be tagged `environment=beta`. You tag your roles and users with the same tags and values, based on which environment each role or user should be able to access. Then, you could assign an AWS Identity and Access Management (IAM) permission policy to your IAM roles, groups, and users. The policy grants permission to access and search using a view only if the role or user making the search request has an `environment` tag with the same value as the `environment` tag attached to the view. The benefit to this approach is that it's dynamic and doesn't require you to maintain a list of who has access to which resources. Instead, you ensure that all resources (your views) and principals (IAM roles and users) are tagged properly. Then, the permissions update automatically without you having to change any policies. ## Referencing tags in an ABAC policy After your views are tagged, you can choose to use those tags to control access dynamically to those views. The following example policy assumes that both your IAM principals and your views are tagged with the tag key `environment` and some value. When that is done, you can attach the following example policy to your principals. Your roles and users can then `Search` using any views that are tagged with an `environment` tag value that exactly matches the `environment` tag attached to the principal. If both the principal and view have the `environment` tag but the values don't match, or if either is missing the `environment` tag then Resource Explorer denies the search request. For more information about using ABAC to securely grant access to your resources, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) # Sharing Resource Explorer views Views in AWS Resource Explorer primarily use [resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) to grant access. Similar to Amazon S3 bucket policies, these policies are attached to the view and specify who can use the view. This is in contrast to AWS Identity and Access Management (IAM) identity-based policies. An IAM identity-based policy is assigned to a role, group, or user, and it specifies which actions and resources that role, group, or user can access. You can use either type of policy with Resource Explorer views, as follows: + Within the management account or delegated administrator account that owns the resource, use ***either*** policy type to grant access, provided that no other policy explicitly denies access to the view for that principal. + Across accounts, you must use ***both*** policy types. The resource-based policy attached to the view in the *sharing* account turns on sharing with another *consuming* account. However, that policy doesn't grant access to the individual users or roles in the consuming account. The administrator in the consuming account must also assign an identity-based policy to the desired roles and users in the consuming account. That policy grants access to the [Amazon resource name (ARN)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) of the view. To share views with other accounts, you must use AWS Resource Access Manager (AWS RAM). AWS RAM handles the complexity of resource-based policies for you. Before you can share, you must perform the following tasks: + [Turn on multi-account search](https://docs.aws.amazon.com/resource-explorer/latest/userguide/manage-service-multi-account.html). + Ensure that your resource-based policy or the IAM identity-based policy you use to share and unshare views includes the `resource-explorer-2:GetResourcePolicy`, `resource-explorer-2:PutResourcePolicy` and `resource-explorer-2:DeleteResourcePolicy` permissions. To share a view, you must be the organization's management account or a delegated administrator. You specify the accounts or identities that you want to share the resource with. AWS RAM fully supports Resource Explorer views. AWS RAM uses policies similar to those described in the following sections, based on the types of the principals that you choose to share with. For instructions on how to share resources, see [Sharing your AWS resources](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html) in the *AWS Resource Access Manager User Guide*. Administrators and delegated administrators can create and share 3 types of views: organization scope view, organizational unit (OU) scope views, and account-level scope views. They can share with organizations, OUs, or accounts. When accounts join or leave the organization, AWS RAM automatically grants or revokes the shared view. ## Permissions policy to share view with AWS accounts The following example policy shows how you can make a view available to the principals in two different AWS accounts: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "111122223333", "444455556666" ] }, "Action": [ "resource-explorer-2:Search", "resource-explorer-2:GetView" ], "Resource": [ "arn:aws:resource-explorer-2:us-east-1:123456789012:view/policy-name/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" ] } ] } ``` ------ The administrator in each of the specified accounts must now specify which roles and users can access the view by attaching identity-based permissions policies to the roles, groups, and users. The administrators of accounts 111122223333 or 444455556666 can create the following example policy. Then, they can assign the policy to roles, groups, and users in those accounts who are to be allowed to search using the view shared from the originating account. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "resource-explorer-2:Search", "resource-explorer-2:GetView" ], "Resource": [ "arn:aws:resource-explorer-2:us-east-1:123456789012:view/policy-name/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" ] } ] } ``` ------ You can use these IAM identity-based policies as part of an attribute-based access control (ABAC) security strategy. In that paradigm, you make sure that all of your resources and all of your identities are tagged. Then, you specify in your policies which tag keys and values must match between the identity and the resource for access to be allowed. For information about tagging the views in your account, see [Adding tags to views](configure-views-tag.md). For more information about attribute-based access control, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) and [Controlling access to AWS resources using tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html), both in the *IAM User Guide*. # Deleting views in Resource Explorer When you no longer need an AWS Resource Explorer view, you can delete it. You can delete views by using the AWS Management Console or by running AWS CLI commands or their equivalent API operations in an AWS SDK. **Note** You can't delete a view that is currently designated as the default for its AWS Region. To delete the view, you must remove the view as the default. To do this, you can run the [DisassociateDefaultView](https://docs.aws.amazon.com/resource-explorer/latest/apireference/API_DisassociateDefaultView.html) API operation in that Region. **Minimum permissions** To run this procedure, you must have the following permissions: + **Action:** `resource-explorer-2:DeleteView` **Resource:** The [ARN](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) of the view to delete ------ #### [ AWS Management Console ] **To delete a view** 1. On the Resource Explorer console **[Views](https://console.aws.amazon.com/resource-explorer/home#/views)** page, choose the option button next to the view that you want to delete. 1. Choose **Actions**, and then choose **Delete**. 1. In the confirmation dialog box, type the name of the view, and then choose **Delete**. ------ #### [ AWS CLI ] **To delete a view** Run the following command to delete the view with the specified Amazon Resource Name (ARN). ``` $ aws resource-explorer-2 delete-view \ --view-arn arn:aws:resource-explorer-2:us-east-1:123456789012:view/MyViewName/1a2b3c4d-5d6e-7f8a-9b0c-abcd11111111 { "ViewArn": "arn:aws:resource-explorer-2:us-east-1:123456789012:view/MyViewName/1a2b3c4d-5d6e-7f8a-9b0c-abcd11111111" } ``` ------ # What are AWS service views AWS service views are pre-defined views (cannot be modified or deleted) that enable controlled resource data access by AWS service teams. AWS Resource Explorer is a platform service that other service teams can take a dependency on to provide value-added services to customers, while providing access and usage transparency to customers. Service views represent one of three integration patterns (user views, AWS managed views, and AWS service views) that other AWS services can use to integrate with Resource Explorer. There are two types of service views: + **Resource Explorer-defined service views:** Used by Resource Explorer itself to power features like the default search functionality. + **Service-defined service views:** Created by an AWS service during onboarding to access specific resource data. Customers cannot use this view directly to view resources. ## Key characteristics of service views AWS service views have the following key characteristics: **Service-defined service view** Service views are created during AWS service onboarding and cannot be modified or deleted by customers. **Pre-defined configuration** Service views include specific filters and properties defined during service onboarding to meet the service's integration requirements. **Global availability** Service views are automatically available to authorized callers without setup as a global resource. ## How service views work Service views support two primary use cases: + **Search and discovery**: + **Resource Explorer-defined service views**: Customers can use this view to discover resources in the default search functionality. + **Service-defined service views**: Services can search for customer resources with customer credentials. + **Resource streaming:** Services receive real-time resource change notifications through event streams Customers can manage service views through the following actions: Customer opt-in is required for streaming access through service views. Customers must explicitly grant permission through the Resource Explorer `CreateStreamingAccessForService` API action. AWS services must create their own service views and can only use the service views they have created. ## Customer experience Customers can manage service views through the following actions: ### Viewing available service views **How can customers see what service views exist?** Customers can view all available service views by using the `ListServiceViews` API action. This API action returns a list of all service views that are available in their account, including both Resource Explorer-defined and service-defined views. The response includes the view name, ARN, and configuration details. ### Monitoring service access **How can customers see which services currently have access?** Customers can monitor which services have streaming access to their resources by using the `ListStreamingAccessForServices` API action. This action provides a complete list of all services that are currently authorized to receive resource updates, allowing customers to maintain visibility over their resource data sharing. ## Permissions and security Service views maintain strong security controls: + **Customer control:** Customers retain control over which services can access their resources (resource streaming only) + **Service-linked role-based access limitations:** When AWS services use SLRs with Resource Explorer permissions, customers must accept the predefined permissions or choose not to use the service + **Customer options:** To revoke Search\$1/List\$1 access granted through SLRs, customers must disable the entire service integration + **IAM integration:** Works with existing IAM policies and Resource Explorer permissions + **Service principal allowlisting:** Only pre-approved AWS services can create and use service views ## Related topics + [Configuring a Resource Explorer view to provide access to resource searches](customer-views.md#configure-views) + [Identity and access management for AWS Resource Explorer](security_iam.md) + [Terms and concepts for Resource Explorer](getting-started-terms-and-concepts.md) # AWS managed views A *managed view* is how other AWS services can access resource information indexed by Resource Explorer for your AWS account or organization with your consent. **Topics** + [ ## About managed views ](#about-managed-views) + [ # Listing managed views ](listing-managed-views.md) + [ # Deleting managed views ](deleting-managed-views.md) ## About managed views Managed views can be updated or deleted only by the service that created the managed view. An AWS service creates a managed view using [IAM forward access sessions (FAS)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html) or a [service-linked role (SLR)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create-service-linked-role.html). Resource Explorer uses a [resource-based policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) to control access to the managed view. When an AWS service creates a managed view, Resource Explorer attaches the resource-based policy to the view. This policy allows the managing AWS service to use and delete the view and allows view's resource owners to list and retrieve details about the view. The following is an example resource-based policy attached to a managed view: Managed views can only be updated or deleted by the service that created the managed view. An AWS service creates a managed view using [IAM forward access sessions (FAS)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html) or a [service-linked role (SLR)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create-service-linked-role.html). Resource Explorer uses a [resource-based policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) to control access to the managed view. When an AWS service creates a managed view, Resource Explorer attaches the resource-based policy to the view. This policy allows the managing AWS service to use and delete the view and allows view's resource owners to list and retrieve details about the view. The following is an example resource-based policy attached to a managed view: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "view_UUID_ACCESS_TO_SERVICE_PRINCIPAL", "Effect": "Allow", "Principal": { "Service": "sampleservice.amazonaws.com" }, "Action": [ "resource-explorer-2:GetManagedView", "resource-explorer-2:Search" ], "Resource": "arn:aws:resource-explorer-2:us-east-1:111122223333:managed-view/ExampleManagedViewName/EXAMPLE8-90ab-cdef-fedc-EXAMPLE11111", "Condition": { "StringEquals": { "aws:SourceAccount": "111122223333" } } }, { "Sid": "view_UUID_DENY_ACCESS_TO_NON_SERVICE_PRINCIPAL", "Effect": "Deny", "Principal": "*", "Condition": { "ForAllValues:StringNotEquals": { "aws:PrincipalServiceNamesList": [ "sampleservice.amazonaws.com" ] } }, "NotAction": [ "resource-explorer-2:GetManagedView" ], "Resource": "arn:aws:resource-explorer-2:us-east-1:111122223333:managed-view/ExampleManagedViewName/EXAMPLE8-90ab-cdef-fedc-EXAMPLE11111" } ] } ``` ------ # Listing managed views You can see which managed views you have access to on the **Views** page in the Resource Explorer console. You can also run AWS CLI commands or their equivalent API operations in an AWS SDK to list the managed views you have access to in your currently selected AWS Region and retrieve view details. To run these commands, you must have the following permissions: + **Action**: `resource-explorer-2:GetManagedView` **Resource**: The ARN of the specified view. + **Action**: `resource-explorer-2:ListManagedViews` **Resource**: The ARN of the specified view. **To list your available managed views** Run the following command to list managed views in the specified AWS Region: ``` aws resource-explorer-2 list-managed-views --region region ``` The command output is a list of ARNs. ``` { "ManagedViews": [ "arn:aws:resource-explorer-2:us-east-1:111122223333:managed-view/ManagedViewNameA/1a2b3c4d-5d6e-7f8a-9b0c-abcd11111111", "arn:aws:resource-explorer-2:us-east-1:444455556666:managed-view/ManagedViewNameB/1a2b3c4d-5d6e-7f8a-9b0c-abcd22222222" ] } ``` **To retrieve managed view details** Run the following command to retrieve details about a specified managed view using the view's ARN: ``` aws resource-explorer-2 get-managed-view \ --managed-view-arn arn:aws:resource-explorer-2:us-east-1:111122223333:managed-view/ManagedViewNameA/1a2b3c4d-5d6e-7f8a-9b0c-abcd11111111 ``` The command output provides details about the specified managed view, similar to the following: ``` { "ManagedView": { "ManagedViewArn": "arn:aws:resource-explorer-2:us-east-1:111122223333:managed-view/ManagedViewNameA/1a2b3c4d-5d6e-7f8a-9b0c-abcd11111111", "ManagedViewName": "ManagedViewNameA", "TrustedService": "sampleservice.amazonaws.com", "LastUpdatedAt": "2024-01-01T01:01:01.100000+00:00", "Owner": "111111111111", "Scope": "arn:aws:iam::111111111111:root", "Filters": { "FilterString": "" }, "IncludedProperties": [ { "Name": "tags" } ], "ResourcePolicy": "{\"Version\":\"YYYY-MM-DD\",\"Statement\":[{\"Sid\":\"EXAMPLE8-90ab-cdef-fedc-EXAMPLE11111_ACCESS_TO_SERVICE_PRINCIPAL\",\"Effect\":\"Allow\",\"PrincipalGroup\":{\"AWS\":\"sservicea.amazonaws.com\"},\"Action\":[\"resource-explorer-2:GetManagedView\",\"resource-explorer-2:DeleteManagedView\",\"resource-explorer-2:Search\"],\"Resource\":\"arn:aws:resource-explorer-2:us-east-1:111122223333:managed-view/ExampleManagedViewName/EXAMPLE8-90ab-cdef-fedc-EXAMPLE11111\",\"Condition\":{\"StringEquals\":{\"aws:SourceAccount\":\"111122223333\"}}},{\"Sid\":\"EXAMPLE8-90ab-cdef-fedc-EXAMPLE11111_DENY_ACCESS_TO_NON_SERVICE_PRINCIPAL\",\"Effect\":\"Deny\",\"Principal\":\"*\",\"NotAction\":\"resource-explorer-2:GetManagedView\",\"Resource\":\"arn:aws:resource-explorer-2:us-east-1:111122223333:managed-view/ExampleManagedViewName/EXAMPLE8-90ab-cdef-fedc-EXAMPLE11111\",\"Condition\":{\"ForAllValues:StringNotEquals\":{\"aws:PrincipalServiceNamesList\":\"servicea.amazonaws.com\"}}}]}", "Version": "1" } } ``` # Deleting managed views Managed views can only be deleted by the AWS service that manages them. Before the managing service can delete the view, you may need to perform service-specific tasks to remove a managed view from your account. Resource Explorer managed views use the AWS Systems Manager `AWSManagedViewForSSM` unified console resource, which allows Systems Manager to access resource information indexed by Resource Explorer for your organization. If you want to delete the managed view, you must disable the unified console in Systems Manager. For instructions, see [Disabling the Systems Manager unified console](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-disable-integrated-console.html) in the *AWS Systems Manager User Guide*. Managed views can only be deleted by the AWS service that manages them. Before the managing service can delete the view, you may need to perform service-specific tasks to remove a managed view from your account. Resource Explorer managed views use the AWS Systems Manager `AWSManagedViewForSSM` unified console resource, which allows Systems Manager to access resource information indexed by Resource Explorer for your organization. If you want to delete the managed view, you must disable the unified console in Systems Manager. For instructions, see [Disabling the Systems Manager unified console](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-disable-integrated-console.html) in the *AWS Systems Manager User Guide*.