# Amazon EMR identity-based policy examples
By default, a users and roles don't have permission to create or modify Amazon EMR resources. They also can't perform tasks using the AWS Management Console, AWS CLI, or AWS API. An IAM administrator must create IAM policies that grant users and roles permission to perform specific API operations on the specified resources they need. The administrator must then attach those policies to the a users or groups that require those permissions.
To learn how to create an IAM identity-based policy using these example JSON policy documents, see [Creating policies on the JSON tab](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) in the *IAM User Guide*.
**Topics**
+ [Policy best practices for Amazon EMR](security_iam_service-with-iam-policy-best-practices.md)
+ [Allow users to view their own permissions](security_iam_id-based-policy-examples-view-own-permissions.md)
+ [Amazon EMR managed policies](emr-managed-iam-policies.md)
+ [IAM policies for tag-based access to clusters and EMR notebooks](emr-fine-grained-cluster-access.md)
+ [Denying the ModifyInstanceGroup action in Amazon EMR](emr-cluster-deny-modifyinstancegroup.md)
+ [Troubleshooting Amazon EMR identity and access](security_iam_troubleshoot.md)
# Policy best practices for Amazon EMR
Identity-based policies are very powerful. They determine whether someone can create, access, or delete Amazon EMR resources in your account. These actions can incur costs for your AWS account. When you create or edit identity-based policies, follow these guidelines and recommendations:
+ **Get Started Using AWS Managed Policies** – To start using Amazon EMR quickly, use AWS managed policies to give your employees the permissions they need. These policies are already available in your account and are maintained and updated by AWS. For more information, see [Get started using permissions with AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-use-aws-defined-policies) in the *IAM User Guide* and [Amazon EMR managed policies](emr-managed-iam-policies.md).
+ **Grant Least Privilege** – When you create custom policies, grant only the permissions required to perform a task. Start with a minimum set of permissions and grant additional permissions as necessary. Doing so is more secure than starting with permissions that are too lenient and then trying to tighten them later. For more information, see [Grant least privilege](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) in the *IAM User Guide*.
+ **Enable MFA for Sensitive Operations** – For extra security, require a users to use multi-factor authentication (MFA) to access sensitive resources or API operations. For more information, see [Using multi-factor authentication (MFA) in AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) in the *IAM User Guide*.
+ **Use Policy Conditions for Extra Security** – To the extent that it's practical, define the conditions under which your identity-based policies allow access to a resource. For example, you can write conditions to specify a range of allowable IP addresses that a request must come from. You can also write conditions to allow requests only within a specified date or time range, or to require the use of SSL or MFA. For more information, see [IAM JSON policy elements: Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) in the *IAM User Guide*.
# Allow users to view their own permissions
This example shows how you might create a policy that allows a users to view the inline and managed policies that are attached to their user identity. This policy includes permissions to complete this action on the console or programmatically using the AWS CLI or AWS API.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUser",
"iam:GetUserPolicy",
"iam:ListAttachedUserPolicies",
"iam:ListGroupsForUser",
"iam:ListUserPolicies"
],
"Resource": [
"arn:aws:iam::*:user/${aws:username}"
]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicy",
"iam:GetPolicyVersion",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListGroups",
"iam:ListPolicies",
"iam:ListPolicyVersions",
"iam:ListUsers"
],
"Resource": [
"*"
]
}
]
}
```
------
# Amazon EMR managed policies
The easiest way to grant full access or read-only access to required Amazon EMR actions is to use the IAM managed policies for Amazon EMR. Managed policies offer the benefit of updating automatically if permission requirements change. If you use inline policies, service changes may occur that cause permission errors to appear.
Amazon EMR will be deprecating existing managed policies (v1 policies) in favor of new managed policies (v2 policies). The new managed policies have been scoped-down to align with AWS best practices. After the existing v1 managed policies are deprecated, you will not be able to attach these policies to any new IAM roles or users. Existing roles and users that use deprecated policies can continue to use them. The v2 managed policies restrict access using tags. They allow only specified Amazon EMR actions and require cluster resources that are tagged with an EMR-specific key. We recommend that you carefully review the documentation before using the new v2 policies.
The v1 policies will be marked deprecated with a warning icon next to them in the **Policies** list in the IAM console. The deprecated policies will have the following characteristics:
+ They will continue to work for all currently attached users, groups, and roles. Nothing breaks.
+ They cannot be attached to new users, groups, or roles. If you detach one of the policies from a current entity, you cannot reattach it.
+ After you detach a v1 policy from all current entities, the policy will no longer be visible and can no longer be used.
The following table summarizes the changes between current policies (v1) and v2 policies.
**Amazon EMR managed policy changes**
| Policy type | Policy names | Policy purpose | Changes to v2 policy |
| --- | --- | --- | --- |
| Default EMR service role and attached managed policy | Role name: **EMR\$1DefaultRole** V1 policy (to be deprecated): **AmazonElasticMapReduceRole** (EMR Service Role) V2 (scoped-down) policy name: [`AmazonEMRServicePolicy_v2`](emr-iam-role.md) | Allows Amazon EMR to call other AWS services on your behalf when provisioning resources and performing service-level actions. This role is required for all clusters. | Policy adds the new permission `"ec2:DescribeInstanceTypeOfferings"`. This API operation returns a list of instance types that are supported by a list of given Availability Zones. |
| IAM managed policy for full Amazon EMR access by attached user, role, or group | V2 (scoped) policy name: [`AmazonEMRServicePolicy_v2`](emr-managed-policy-fullaccess-v2.md) | Allows users full permissions for EMR actions. Includes iam:PassRole permissions for resources. | Policy adds a prerequisite that users must add user tags to resources before they can use this policy. See [Tagging resources to use managed policies](#manually-tagged-resources). iam:PassRole action requires iam:PassedToService condition set to specified service. Access to Amazon EC2, Amazon S3, and other services is not allowed by default. See [IAM Managed Policy for Full Access (v2 Managed Default Policy)](emr-managed-policy-fullaccess-v2.md). |
| IAM managed policy for read-only access by attached user, role, or group | V1 policy (to be deprecated): [`AmazonElasticMapReduceReadOnlyAccess`](emr-managed-policy-readonly.md) V2 (scoped) policy name: [`AmazonEMRReadOnlyAccessPolicy_v2`](emr-managed-policy-readonly-v2.md) | Allows users read-only permissions for Amazon EMR actions. | Permissions allow only specified elasticmapreduce read-only actions. Access to Amazon S3 is access not allowed by default. See [IAM Managed Policy for Read-Only Access (v2 Managed Default Policy)](emr-managed-policy-readonly-v2.md). |
| Default EMR service role and attached managed policy | Role name: **EMR\$1DefaultRole** V1 policy (to be deprecated): **AmazonElasticMapReduceRole** (EMR Service Role) V2 (scoped-down) policy name: [`AmazonEMRServicePolicy_v2`](emr-iam-role.md) | Allows Amazon EMR to call other AWS services on your behalf when provisioning resources and performing service-level actions. This role is required for all clusters. | The v2 service role and v2 default policy replace the deprecated role and policy. The policy adds a prerequisite that users must add user tags to resources before they can use this policy. See [Tagging resources to use managed policies](#manually-tagged-resources). See [Service role for Amazon EMR (EMR role)](emr-iam-role.md). |
| Service role for cluster EC2 instances (EC2 instance profile) | Role name: **EMR\$1EC2\$1DefaultRole** Deprecated policy name: **AmazonElasticMapReduceforEC2Role** | Allows applications running on an EMR cluster to access other AWS resources, such as Amazon S3. For example, if you run Apache Spark jobs that process data from Amazon S3, the policy needs to allow access to such resources. | Both default role and default policy are on the path to deprecation. There is no replacement AWS default managed role or policy. You need to provide a resource-based or identity-based policy. This means that, by default, applications running on an EMR cluster do not have access to Amazon S3 or other resource unless you manually add these to the policy. See [Default role and managed policy](emr-iam-role-for-ec2.md#emr-ec2-role-default). |
| Other EC2 service role policies | Current policy names: **AmazonElasticMapReduceforAutoScalingRole, AmazonElasticMapReduceEditorsRole, AmazonEMRCleanupPolicy** | Provides permissions that Amazon EMR needs to access other AWS resources and perform actions if using auto scaling, notebooks, or to clean up EC2 resources. | No changes for v2. |
## Securing iam:PassRole
The Amazon EMR full-permissions default managed policies incorporate `iam:PassRole` security configurations, including the following:
+ `iam:PassRole` permissions only for specific default Amazon EMR roles.
+ `iam:PassedToService` conditions that allow you to use the policy with only specified AWS services, such as `elasticmapreduce.amazonaws.com` and `ec2.amazonaws.com`.
You can view the JSON version of the [AmazonEMRFullAccessPolicy\$1v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRFullAccessPolicy_v2) and [AmazonEMRServicePolicy\$1v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRServicePolicy_v2) policies in the IAM console. We recommend that you create new clusters with the v2 managed policies.
To create custom policies, we recommend that you begin with the managed policies and edit them according to your requirements.
For information about how to attach policies to a users (principals), see [Working with managed policies using the AWS Management Console](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-using.html#policies_using-managed-console) in the *IAM User Guide*.
## Tagging resources to use managed policies
**AmazonEMRServicePolicy\$1v2** and **AmazonEMRFullAccessPolicy\$1v2** depend on scoped-down access to resources that Amazon EMR provisions or uses. The scope down is achieved by restricting access to only those resources that have a predefined user tag associated with them. When you use either of these two policies, you must pass the predefined user tag `for-use-with-amazon-emr-managed-policies = true` when you provision the cluster. Amazon EMR will then automatically propagate that tag. Additionally, you must add a user tag to the resources listed in the following section. If you use the Amazon EMR console to launch your cluster, see [Considerations for using the Amazon EMR console to launch clusters with v2 managed policies](#emr-cluster-v2policy-awsconsole-launch).
To use managed policies, pass the user tag `for-use-with-amazon-emr-managed-policies = true` when you provision a cluster with the CLI, SDK, or another method.
When you pass the tag, Amazon EMR propagates the tag to private subnet ENI, EC2 instance, and EBS volumes that it creates. Amazon EMR also automatically tags security groups that it creates. However, if you want Amazon EMR to launch with a certain security group, you must tag it. For resources that are not created by Amazon EMR, you must add tags to those resources. For example, you must tag Amazon EC2 subnets, EC2 security groups (if not created by Amazon EMR), and VPCs (if you want Amazon EMR to create security groups). To launch clusters with v2 managed policies in VPCs, you must tag those VPCs with the predefined user tag. See, [Considerations for using the Amazon EMR console to launch clusters with v2 managed policies](#emr-cluster-v2policy-awsconsole-launch).
**Propagated user-specified tagging**
Amazon EMR tags resources that it creates using the Amazon EMR tags that you specify when creating a cluster. Amazon EMR applies tags to the resources it creates during the lifetime of the cluster.
Amazon EMR propagates user tags for the following resources:
+ Private Subnet ENI (service access elastic network interfaces)
+ EC2 Instances
+ EBS Volumes
+ EC2 Launch Template
**Automatically-tagged security groups**
Amazon EMR tags EC2 security groups that it creates with the tag that is required for v2 managed policies for Amazon EMR, `for-use-with-amazon-emr-managed-policies`, regardless of which tags you specify in the create cluster command. For a security group that was created before the introduction of v2 managed policies, Amazon EMR does not automatically tag the security group. If you want to use v2 managed policies with the default security groups that already exist in the account, you need to tag the security groups manually with `for-use-with-amazon-emr-managed-policies = true`.
**Manually-tagged cluster resources**
You must manually tag some cluster resources so that they can be accessed by Amazon EMR default roles.
+ You must manually tag EC2 security groups and EC2 subnets with the Amazon EMR managed policy tag `for-use-with-amazon-emr-managed-policies`.
+ You must manually tag a VPC if you want Amazon EMR to create default security groups. EMR will try to create a security group with the specific tag if the default security group doesn't already exist.
Amazon EMR automatically tags the following resources:
+ EMR-created EC2 Security Groups
You must manually tag the following resources:
+ EC2 Subnet
+ EC2 Security Groups
Optionally, you can manually tag the following resources:
+ VPC - only when you want Amazon EMR to create security groups
## Considerations for using the Amazon EMR console to launch clusters with v2 managed policies
You can provision clusters with v2 managed policies using the Amazon EMR console. Here are some considerations when you use the console to launch Amazon EMR clusters.
+ You do not need to pass the predefined tag. Amazon EMR automatically adds the tag and propagates it to the appropriate components.
+ For components that need to be manually tagged, the old Amazon EMR console tries to automatically tag them if you have the required permissions to tag resources. If you don’t have the permissions to tag resources or if you want to use the console, ask your administrator to tag those resources.
+ You cannot launch clusters with v2 managed policies unless all the prerequisites are met.
+ The old Amazon EMR console shows you which resources (VPC/Subnets) need to be tagged.
# IAM managed policy for full access (v2 managed default policy) for Amazon EMR
The v2 scoped EMR default managed policies grant specific access privileges to users. They require a predefined Amazon EMR resource tag and `iam:PassRole` condition keys to resources used by Amazon EMR, such as the `Subnet` and `SecurityGroup` you use to launch your cluster.
To grant required actions scoped for Amazon EMR, attach the `AmazonEMRFullAccessPolicy_v2` managed policy. This updated default managed policy replaces the [`AmazonElasticMapReduceFullAccess`](emr-managed-policy-fullaccess.md) managed policy.
`AmazonEMRFullAccessPolicy_v2` depends on scoped-down access to resources that Amazon EMR provisions or uses. When you use this policy, you need to pass the user tag `for-use-with-amazon-emr-managed-policies = true` when provisioning the cluster. Amazon EMR will automatically propagate the tag. Additionally, you may need to manually add a user tag to specific types of resources, such as EC2 security groups that were not created by Amazon EMR. For more information, see [Tagging resources to use managed policies](emr-managed-iam-policies.md#manually-tagged-resources).
The [https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEMRFullAccessPolicy_v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEMRFullAccessPolicy_v2) policy secures resources by doing the following:
+ Requires resources to be tagged with the pre-defined Amazon EMR managed policies tag `for-use-with-amazon-emr-managed-policies` for cluster creation and Amazon EMR access.
+ Restricts the `iam:PassRole` action to specific default roles and `iam:PassedToService` access to specific services.
+ No longer provides access to Amazon EC2, Amazon S3, and other services by default.
Following are the contents of this policy.
**Note**
You can also use the console link [https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEMRFullAccessPolicy_v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEMRFullAccessPolicy_v2) to view the policy.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "RunJobFlowExplicitlyWithEMRManagedTag",
"Effect": "Allow",
"Action": [
"elasticmapreduce:RunJobFlow"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "ElasticMapReduceActions",
"Effect": "Allow",
"Action": [
"elasticmapreduce:AddInstanceFleet",
"elasticmapreduce:AddInstanceGroups",
"elasticmapreduce:AddJobFlowSteps",
"elasticmapreduce:AddTags",
"elasticmapreduce:CancelSteps",
"elasticmapreduce:CreateEditor",
"elasticmapreduce:CreatePersistentAppUI",
"elasticmapreduce:CreateSecurityConfiguration",
"elasticmapreduce:DeleteEditor",
"elasticmapreduce:DeleteSecurityConfiguration",
"elasticmapreduce:DescribeCluster",
"elasticmapreduce:DescribeEditor",
"elasticmapreduce:DescribeJobFlows",
"elasticmapreduce:DescribePersistentAppUI",
"elasticmapreduce:DescribeSecurityConfiguration",
"elasticmapreduce:DescribeStep",
"elasticmapreduce:DescribeReleaseLabel",
"elasticmapreduce:GetBlockPublicAccessConfiguration",
"elasticmapreduce:GetManagedScalingPolicy",
"elasticmapreduce:GetPersistentAppUIPresignedURL",
"elasticmapreduce:GetAutoTerminationPolicy",
"elasticmapreduce:ListBootstrapActions",
"elasticmapreduce:ListClusters",
"elasticmapreduce:ListEditors",
"elasticmapreduce:ListInstanceFleets",
"elasticmapreduce:ListInstanceGroups",
"elasticmapreduce:ListInstances",
"elasticmapreduce:ListSecurityConfigurations",
"elasticmapreduce:ListSteps",
"elasticmapreduce:ListSupportedInstanceTypes",
"elasticmapreduce:ModifyCluster",
"elasticmapreduce:ModifyInstanceFleet",
"elasticmapreduce:ModifyInstanceGroups",
"elasticmapreduce:OpenEditorInConsole",
"elasticmapreduce:PutAutoScalingPolicy",
"elasticmapreduce:PutBlockPublicAccessConfiguration",
"elasticmapreduce:PutManagedScalingPolicy",
"elasticmapreduce:RemoveAutoScalingPolicy",
"elasticmapreduce:RemoveManagedScalingPolicy",
"elasticmapreduce:RemoveTags",
"elasticmapreduce:SetTerminationProtection",
"elasticmapreduce:StartEditor",
"elasticmapreduce:StopEditor",
"elasticmapreduce:TerminateJobFlows",
"elasticmapreduce:ViewEventsFromAllClustersInConsole"
],
"Resource": [
"*"
]
},
{
"Sid": "ViewMetricsInEMRConsole",
"Effect": "Allow",
"Action": [
"cloudwatch:GetMetricStatistics"
],
"Resource": [
"*"
]
},
{
"Sid": "PassRoleForElasticMapReduce",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::*:role/EMR_DefaultRole",
"arn:aws:iam::*:role/EMR_DefaultRole_V2"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "elasticmapreduce.amazonaws.com*"
}
}
},
{
"Sid": "PassRoleForEC2",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::*:role/EMR_EC2_DefaultRole"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "ec2.amazonaws.com*"
}
}
},
{
"Sid": "PassRoleForAutoScaling",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::*:role/EMR_AutoScaling_DefaultRole"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "application-autoscaling.amazonaws.com*"
}
}
},
{
"Sid": "ElasticMapReduceServiceLinkedRole",
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Resource": [
"arn:aws:iam::*:role/aws-service-role/elasticmapreduce.amazonaws.com*/AWSServiceRoleForEMRCleanup*"
],
"Condition": {
"StringEquals": {
"iam:AWSServiceName": [
"elasticmapreduce.amazonaws.com",
"elasticmapreduce.amazonaws.com.rproxy.govskope.ca.cn"
]
}
}
},
{
"Sid": "ConsoleUIActions",
"Effect": "Allow",
"Action": [
"ec2:DescribeAccountAttributes",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeImages",
"ec2:DescribeKeyPairs",
"ec2:DescribeNatGateways",
"ec2:DescribeRouteTables",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"ec2:DescribeVpcEndpoints",
"s3:ListAllMyBuckets",
"iam:ListRoles"
],
"Resource": [
"*"
]
}
]
}
```
------
# IAM managed policy for full access (on path to deprecation)
The `AmazonElasticMapReduceFullAccess` and `AmazonEMRFullAccessPolicy_v2` AWS Identity and Access Management (IAM) managed policies grant all the required actions for Amazon EMR and other services.
**Important**
The `AmazonElasticMapReduceFullAccess` managed policy is on the path to deprecation, and no longer recommended for use with Amazon EMR. Instead, use [`AmazonEMRFullAccessPolicy_v2`](emr-managed-policy-fullaccess-v2.md). When the IAM service eventually deprecates the v1 policy, you won't be able to attach it to a role. However, you can attach an existing role to a cluster even if that role uses the deprecated policy.
The Amazon EMR full-permissions default managed policies incorporate `iam:PassRole` security configurations, including the following:
+ `iam:PassRole` permissions only for specific default Amazon EMR roles.
+ `iam:PassedToService` conditions that allow you to use the policy with only specified AWS services, such as `elasticmapreduce.amazonaws.com` and `ec2.amazonaws.com`.
You can view the JSON version of the [AmazonEMRFullAccessPolicy\$1v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRFullAccessPolicy_v2) and [AmazonEMRServicePolicy\$1v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRServicePolicy_v2) policies in the IAM console. We recommend that you create new clusters with the v2 managed policies.
You can view the contents of the deprecated v1 policy in the AWS Management Console at [https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonElasticMapReduceFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonElasticMapReduceFullAccess). The `ec2:TerminateInstances` action in the policy grants permission to the a user or role to terminate any of the Amazon EC2 instances associated with the IAM account. This includes instances that are not part of an EMR cluster.
# IAM managed policy for read-only access (v2 managed default policy) for Amazon EMR
To grant read-only privileges to Amazon EMR, attach the **AmazonEMRReadOnlyAccessPolicy\$1v2** managed policy. This default managed policy replaces the [`AmazonElasticMapReduceReadOnlyAccess`](emr-managed-policy-readonly.md) managed policy. The content of this policy statement is shown in the following snippet. Compared with the `AmazonElasticMapReduceReadOnlyAccess` policy, the `AmazonEMRReadOnlyAccessPolicy_v2` policy does not use wildcard characters for the `elasticmapreduce` element. Instead, the default v2 policy scopes the allowable `elasticmapreduce` actions.
**Note**
You can also use the AWS Management Console link [https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEMRReadOnlyAccessPolicy_v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEMRReadOnlyAccessPolicy_v2) to view the policy.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ElasticMapReduceActions",
"Effect": "Allow",
"Action": [
"elasticmapreduce:DescribeCluster",
"elasticmapreduce:DescribeEditor",
"elasticmapreduce:DescribeJobFlows",
"elasticmapreduce:DescribeSecurityConfiguration",
"elasticmapreduce:DescribeStep",
"elasticmapreduce:DescribeReleaseLabel",
"elasticmapreduce:GetBlockPublicAccessConfiguration",
"elasticmapreduce:GetManagedScalingPolicy",
"elasticmapreduce:GetAutoTerminationPolicy",
"elasticmapreduce:ListBootstrapActions",
"elasticmapreduce:ListClusters",
"elasticmapreduce:ListEditors",
"elasticmapreduce:ListInstanceFleets",
"elasticmapreduce:ListInstanceGroups",
"elasticmapreduce:ListInstances",
"elasticmapreduce:ListSecurityConfigurations",
"elasticmapreduce:ListSteps",
"elasticmapreduce:ListSupportedInstanceTypes",
"elasticmapreduce:ViewEventsFromAllClustersInConsole"
],
"Resource": [
"*"
]
},
{
"Sid": "ViewMetricsInEMRConsole",
"Effect": "Allow",
"Action": [
"cloudwatch:GetMetricStatistics"
],
"Resource": [
"*"
]
}
]
}
```
------
# IAM managed policy for read-only access (on path to deprecation)
The `AmazonElasticMapReduceReadOnlyAccess` managed policy is on the path to deprecation. You cannot attach this policy when launching new clusters. `AmazonElasticMapReduceReadOnlyAccess` has been replaced with [`AmazonEMRReadOnlyAccessPolicy_v2`](emr-managed-policy-readonly-v2.md) as the Amazon EMR default managed policy. The content of this policy statement is shown in the following snippet. Wildcard characters for the `elasticmapreduce` element specify that only actions that begin with the specified strings are allowed. Keep in mind that because this policy does not explicitly deny actions, a different policy statement may still be used to grant access to specified actions.
**Note**
You can also use the AWS Management Console to view the policy.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticmapreduce:Describe*",
"elasticmapreduce:List*",
"elasticmapreduce:ViewEventsFromAllClustersInConsole",
"s3:GetObject",
"s3:ListAllMyBuckets",
"s3:ListBucket",
"sdb:Select",
"cloudwatch:GetMetricStatistics"
],
"Resource": [
"*"
],
"Sid": "AllowELASTICMAPREDUCEDescribe"
}
]
}
```
------
# AWS managed policy: EMRDescribeClusterPolicyForEMRWAL
You can't attach `EMRDescribeClusterPolicyForEMRWAL` to your IAM entities. This policy is attached to a service-linked role that allows Amazon EMR to perform actions on your behalf. For more information on this service-linked role, see [Using service-linked roles with Amazon EMR for write-ahead logging](using-service-linked-roles-wal.md).
This policy grants read-only permissions that allow the WAL service for Amazon EMR to find and return the status of a cluster. For more information about Amazon EMR WAL, see [Write-ahead logs (WAL) for Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hbase-wal.html).
**Permissions details**
This policy includes the following permissions:
+ `emr` – Allows principals to describe cluster status from Amazon EMR. This is required so that Amazon EMR can confirm when a cluster has terminated and then, after thirty days, clean up any WAL logs left behind by the cluster.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticmapreduce:DescribeCluster"
],
"Resource": [
"*"
],
"Sid": "AllowELASTICMAPREDUCEDescribecluster"
}
]
}
```
------
## AWS managed policies for Amazon EMR
An AWS managed policy is a standalone policy that is created and administered by AWS. AWS managed policies are designed to provide permissions for many common use cases so that you can start assigning permissions to users, groups, and roles.
Keep in mind that AWS managed policies might not grant least-privilege permissions for your specific use cases because they're available for all AWS customers to use. We recommend that you reduce permissions further by defining [ customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) that are specific to your use cases.
You cannot change the permissions defined in AWS managed policies. If AWS updates the permissions defined in an AWS managed policy, the update affects all principal identities (users, groups, and roles) that the policy is attached to. AWS is most likely to update an AWS managed policy when a new AWS service is launched or new API operations become available for existing services.
For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*.
# Amazon EMR updates to AWS managed policies
View details about updates to AWS managed policies for Amazon EMR since this service began tracking these changes.
| Change | Description | Date |
| --- | --- | --- |
| [`AmazonEMRServicePolicy_v2`](emr-iam-role.md) – Update to an existing policy | Added ec2:CreateVpcEndpoint, ec2:ModifyVpcEndpoint, and ec2:CreateTags required for optimal experience, starting with Amazon EMR release 7.5.0. | March 4, 2025 |
| [`AmazonEMRServicePolicy_v2`](emr-iam-role.md) – Update to an existing policy | Added elasticmapreduce:CreatePersistentAppUI, elasticmapreduce:DescribePersistentAppUI, and elasticmapreduce:GetPersistentAppUIPresignedURL. | February 28, 2025 |
| [`EMRDescribeClusterPolicyForEMRWAL`](EMRDescribeClusterPolicyForEMRWAL.md) – New policy | Added a new policy so that Amazon EMR can determine cluster status for WAL cleanup thirty days after cluster termination. | August 10, 2023 |
| [`AmazonEMRFullAccessPolicy_v2`](emr-managed-policy-fullaccess-v2.md) and [`AmazonEMRReadOnlyAccessPolicy_v2`](emr-managed-policy-readonly-v2.md) – Update to an existing policy | Added elasticmapreduce:DescribeReleaseLabel and elasticmapreduce:GetAutoTerminationPolicy. | April 21, 2022 |
| [`AmazonEMRFullAccessPolicy_v2`](emr-managed-policy-fullaccess-v2.md) – Update to an existing policy | Added ec2:DescribeImages for [Using a custom AMI to provide more flexibility for Amazon EMR cluster configuration](emr-custom-ami.md). | February 15, 2022 |
| [**Amazon EMR managed policies**](emr-managed-iam-policies.md) | Updated to clarify use of predefined user tags. Added section on using the AWS console to launch clsuters with v2 managed policies. | September 29, 2021 |
| [`AmazonEMRFullAccessPolicy_v2`](emr-managed-policy-fullaccess-v2.md) – Update to an existing policy | Changed the PassRoleForAutoScaling and PassRoleForEC2 actions to use the StringLike condition operator to match "iam:PassedToService":"application-autoscaling.amazonaws.com\$1" and "iam:PassedToService":"ec2.amazonaws.com\$1", respectively. | May 20, 2021 |
| [`AmazonEMRFullAccessPolicy_v2`](emr-managed-policy-fullaccess-v2.md) – Update to an existing policy | Removed invalid action `s3:ListBuckets` and replaced with `s3:ListAllMyBuckets` action. Updated service-linked role (SLR) creation to be explicitly scoped-down to the only SLR that Amazon EMR has with explicit Service Principles. The SLRs that can be created are exactly the same as before this change. | March 23, 2021 |
| [`AmazonEMRFullAccessPolicy_v2`](emr-managed-policy-fullaccess-v2.md) – New policy | Amazon EMR added new permissions to scope access to resources and to add a prerequisite that users must add predefined user tag to resources before they can use Amazon EMR managed policies. `iam:PassRole` action requires `iam:PassedToService` condition set to specified service. Access to Amazon EC2, Amazon S3, and other services is not allowed by default. | March 11, 2021 |
| [`AmazonEMRServicePolicy_v2`](emr-iam-role.md) – New policy | Adds a prerequisite that users must add user tags to resources before they can use this policy. | March 11, 2021 |
| [`AmazonEMRReadOnlyAccessPolicy_v2`](emr-managed-policy-readonly-v2.md) – New policy | Permissions allow only specified elasticmapreduce read-only actions. Access to Amazon S3 is access not allowed by default. | March 11, 2021 |
| Amazon EMR started tracking changes | Amazon EMR started tracking changes for its AWS managed policies. | March 11, 2021 |
# IAM policies for tag-based access to clusters and EMR notebooks
You can use conditions in your identity-based policy to control access to clusters and EMR notebooks based on tags.
For more information about adding tags to clusters, see [Tagging EMR clusters](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-tags.html).
The following examples demonstrate different scenarios and ways to use condition operators with Amazon EMR condition keys. These IAM policy statements are intended for demonstration purposes only and should not be used in production environments. There are multiple ways to combine policy statements to grant and deny permissions according to your requirements. For more information about planning and testing IAM policies, see the [IAM User Guide](https://docs.aws.amazon.com/IAM/latest/UserGuide/).
**Important**
Explicitly denying permission for tagging actions is an important consideration. This prevents users from tagging a resource and thereby granting themselves permissions that you did not intend to grant. If you don't deny tagging actions for a resource, a user can modify tags and circumvent the intention of the tag-based policies.
## Example identity-based policy statements for clusters
The following examples demonstrate identity-based permissions policies that are used to control the actions that are allowed with EMR clusters.
**Important**
The `ModifyInstanceGroup` action in Amazon EMR does not require that you specify a cluster ID. For that reason, denying this action based on cluster tags requires additional consideration. For more information, see [Denying the ModifyInstanceGroup action in Amazon EMR](emr-cluster-deny-modifyinstancegroup.md).
**Topics**
+ [Allow actions only on clusters with specific tag values](#emr-cluster-access-example-tagvalue)
+ [Require cluster tagging when a cluster is created](#emr-cluster-access-example-require-tagging)
+ [Allow actions on clusters with a specific tag, regardless of tag value](#emr-cluster-access-example-tag)
### Allow actions only on clusters with specific tag values
The following examples demonstrate a policy that allows a user to perform actions based on the cluster tag `department` with the value `dev` and also allows a user to tag clusters with that same tag. The final policy example demonstrates how to deny privileges to tag EMR clusters with anything but that same tag.
In the following policy example, the `StringEquals` condition operator tries to match `dev` with the value for the tag `department`. If the tag `department` hasn't been added to the cluster, or doesn't contain the value `dev`, the policy doesn't apply, and the actions aren't allowed by this policy. If no other policy statements allow the actions, the user can only work with clusters that have this tag with this value.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Stmt12345678901234",
"Effect": "Allow",
"Action": [
"elasticmapreduce:DescribeCluster",
"elasticmapreduce:ListSteps",
"elasticmapreduce:TerminateJobFlows",
"elasticmapreduce:SetTerminationProtection",
"elasticmapreduce:ListInstances",
"elasticmapreduce:ListInstanceGroups",
"elasticmapreduce:ListBootstrapActions",
"elasticmapreduce:DescribeStep"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/department": "dev"
}
}
}
]
}
```
------
You can also specify multiple tag values using a condition operator. For example, to allow all actions on clusters where the `department` tag contains the value `dev` or `test`, you could replace the condition block in the earlier example with the following.
```
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/department":["dev", "test"]
}
}
```
### Require cluster tagging when a cluster is created
As in the prior example, the following policy example looks for the same matching tag: the value `dev` for the `department` tag. But in this example, the `RequestTag` condition key specifies that the policy applies during tag creation. So you must create a cluster with a tag that matches the specified value.
To create a cluster with a tag, you must also have permission for the `elasticmapredue:AddTags` action. For this statement, the `elasticmapreduce:ResourceTag` condition key ensures that IAM only grants access to tag resources with the value `dev` on the `department` tag. The `Resource` element is used to limit this permission to cluster resources.
For the `PassRole` resources, you must provide the AWS account ID or alias, the service role name in the `PassRoleForEMR` statement, and the instance profile name in the `PassRoleForEC2` statement. For more information about the IAM ARN format, see [IAM ARNs](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-arns) in the *IAM User Guide*.
For more information about matching tag-key values, see [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag) in the *IAM User Guide*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "RunJobFlowExplicitlyWithTag",
"Effect": "Allow",
"Action": [
"elasticmapreduce:RunJobFlow"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/department": "dev"
}
}
},
{
"Sid": "AddTagsForDevClusters",
"Effect": "Allow",
"Action": [
"elasticmapreduce:AddTags"
],
"Resource": [
"arn:aws:elasticmapreduce:*:*:cluster/*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/department": "dev"
}
}
},
{
"Sid": "PassRoleForEMR",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::123456789012:role/Role-Name-With-Path"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "elasticmapreduce.amazonaws.com*"
}
}
},
{
"Sid": "PassRoleForEC2",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::123456789012:role/Role-Name-With-Path"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "ec2.amazonaws.com*"
}
}
}
]
}
```
------
### Allow actions on clusters with a specific tag, regardless of tag value
You can also allow actions only on clusters that have a particular tag, regardless of the tag value. To do this, you can use the `Null` operator. For more information, see [Condition operator to check existence of condition keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Conditions_Null) in the *IAM User Guide*. For example, to allow actions only on EMR clusters that have the `department` tag, regardless of the value it contains, you could replace the Condition blocks in the earlier example with the following one. The `Null` operator looks for the presence of the tag `department` on an EMR cluster. If the tag exists, the `Null` statement evaluates to false, matching the condition specified in this policy statement, and the appropriate actions are allowed.
```
1. "Condition": {
2. "Null": {
3. "elasticmapreduce:ResourceTag/department":"false"
4. }
5. }
```
The following policy statement allows a user to create an EMR cluster only if the cluster will have a `department` tag, which can contain any value. For the `PassRole` resource, you need to provide the AWS account ID or alias, and the service role name. For more information about the IAM ARN format, see [IAM ARNs](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-arns) in the *IAM User Guide*.
For more information specifying the null ("false") condition operator, see [Condition operator to check existence of condition keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_Null) in the *IAM User Guide*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CreateClusterTagNullCondition",
"Effect": "Allow",
"Action": [
"elasticmapreduce:RunJobFlow"
],
"Resource": [
"*"
],
"Condition": {
"Null": {
"aws:RequestTag/department": "false"
}
}
},
{
"Sid": "AddTagsNullCondition",
"Effect": "Allow",
"Action": [
"elasticmapreduce:AddTags"
],
"Resource": [
"arn:aws:elasticmapreduce:*:*:cluster/*"
],
"Condition": {
"Null": {
"elasticmapreduce:ResourceTag/department": "false"
}
}
},
{
"Sid": "PassRoleForElasticMapReduce",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::123456789012:role/Role-Name-With-Path"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "elasticmapreduce.amazonaws.com*"
}
}
},
{
"Sid": "PassRoleForEC2",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::123456789012:role/Role-Name-With-Path"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "ec2.amazonaws.com*"
}
}
}
]
}
```
------
## Example identity-based policy statements for EMR Notebooks
The example IAM policy statements in this section demonstrate common scenarios for using keys to limit allowed actions using EMR Notebooks. As long as no other policy associated with the principal (user) allows the actions, the condition context keys limit allowed actions as indicated.
**Example – Allow access only to EMR Notebooks that a user creates based on tagging**
The following example policy statement, when attached to a role or user, allows the a user to work only with notebooks that they have created. This policy statement uses the default tag applied when a notebook is created.
In the example, the `StringEquals` condition operator tries to match a variable representing the current users a user ID (`{aws:userId}`) with the value of the tag `creatorUserID`. If the tag `creatorUserID` hasn't been added to the notebook, or doesn't contain the value of the current user's ID, the policy doesn't apply, and the actions aren't allowed by this policy. If no other policy statements allow the actions, the user can only work with notebooks that have this tag with this value.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:DescribeEditor",
"elasticmapreduce:StartEditor",
"elasticmapreduce:StopEditor",
"elasticmapreduce:DeleteEditor",
"elasticmapreduce:OpenEditorInConsole"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/creatorUserId": "${aws:userId}"
}
},
"Sid": "AllowELASTICMAPREDUCEDescribeeditor"
}
]
}
```
**Example –Require notebook tagging when a notebook is created**
In this example, the `RequestTag` context key is used. The `CreateEditor` action is allowed only if the user does not change or delete the `creatorUserID` tag is added by default. The variable \$1\$1aws:userId\$1, specifies the currently active user's User ID, which is the default value of the tag.
The policy statement can be used to help ensure that users do not remove the `createUserId` tag or change its value.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:CreateEditor"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:RequestTag/creatorUserId": "${aws:userid}"
}
},
"Sid": "AllowELASTICMAPREDUCECreateeditor"
}
]
}
```
This example requires that the user create the cluster with a tag having the key string `dept` and a value set to one of the following: `datascience`, `analytics`, `operations`.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:CreateEditor"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:RequestTag/dept": [
"datascience",
"analytics",
"operations"
]
}
},
"Sid": "AllowELASTICMAPREDUCECreateeditor"
}
]
}
```
**Example –Limit notebook creation to tagged clusters, and require notebook tags**
This example allows notebook creation only if the notebook is created with a tag that has the key string `owner` set to one of the specified values. In addition, the notebook can be created only if the cluster has a tag with the key string `department` set to one of the specified values.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:CreateEditor"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:RequestTag/owner": [
"owner1",
"owner2",
"owner3"
],
"elasticmapreduce:ResourceTag/department": [
"dep1",
"dep3"
]
}
},
"Sid": "AllowELASTICMAPREDUCECreateeditor"
}
]
}
```
**Example –Limit the ability to start a notebook based on tags**
This example limits the ability to start notebooks only to those notebooks that have a tag with the key string `owner` set to one of the specified values. Because the `Resource` element is used to specify only the `editor`, the condition does not apply to the cluster, and it does not need to be tagged.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:StartEditor"
],
"Effect": "Allow",
"Resource": [
"arn:aws:elasticmapreduce:*:123456789012:editor/*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/owner": [
"owner1",
"owner2"
]
}
},
"Sid": "AllowELASTICMAPREDUCEStarteditor"
}
]
}
```
This example is similar to one above. However, the limit only applies to tagged clusters, not notebooks.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:StartEditor"
],
"Effect": "Allow",
"Resource": [
"arn:aws:elasticmapreduce:*:123456789012:cluster/*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/department": [
"dep1",
"dep3"
]
}
},
"Sid": "AllowELASTICMAPREDUCEStarteditor"
}
]
}
```
This example uses a different set of notebook and cluster tags. It allows a notebook to be started only if:
+ The notebook has a tag with the key string `owner` set to any of the specified values
—and—
+ The cluster has a tag with the key string `department` set to any of the specified values
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:StartEditor"
],
"Effect": "Allow",
"Resource": [
"arn:aws:elasticmapreduce:*:123456789012:editor/*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/owner": [
"user1",
"user2"
]
}
},
"Sid": "AllowELASTICMAPREDUCEStarteditorByOwner"
},
{
"Action": [
"elasticmapreduce:StartEditor"
],
"Effect": "Allow",
"Resource": [
"arn:aws:elasticmapreduce:*:123456789012:cluster/*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/department": [
"datascience",
"analytics"
]
}
},
"Sid": "AllowELASTICMAPREDUCEStarteditorByDepartment"
}
]
}
```
**Example –Limit the ability to open the notebook editor based on tags**
This example allows the notebook editor to be opened only if:
+ The notebook has a tag with the key string `owner` set to any of the specified values.
—and—
+ The cluster has a tag with the key string `department` set to any of the specified values.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:OpenEditorInConsole"
],
"Effect": "Allow",
"Resource": [
"arn:aws:elasticmapreduce:*:123456789012:editor/*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/owner": [
"user1",
"user2"
]
}
},
"Sid": "AllowELASTICMAPREDUCEOpeneditorconsoleByOwner"
},
{
"Action": [
"elasticmapreduce:OpenEditorInConsole"
],
"Effect": "Allow",
"Resource": [
"arn:aws:elasticmapreduce:*:123456789012:cluster/*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/department": [
"datascience",
"analytics"
]
}
},
"Sid": "AllowELASTICMAPREDUCEOpeneditorconsoleByDepartment"
}
]
}
```
# Denying the ModifyInstanceGroup action in Amazon EMR
The [ModifyInstanceGroups](https://docs.aws.amazon.com/emr/latest/APIReference/API_ModifyInstanceGroups.html) action in Amazon EMR does not require that you provide a cluster ID with the action. Instead, you can specify only an instance group ID. For this reason, an apparently simple deny policy for this action based on cluster ID or a cluster tag may not have the intended effect. Consider the following example policy.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Sid": "AllowELASTICMAPREDUCEModifyinstancegroups"
},
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Effect": "Deny",
"Resource": [
"arn:aws:elasticmapreduce:us-east-1:123456789012:cluster/j-12345ABCDEFG67"
],
"Sid": "DenyELASTICMAPREDUCEModifyinstancegroups"
}
]
}
```
------
If a user with this policy attached performs a `ModifyInstanceGroup` action and specifies only the instance group ID, the policy does not apply. Because the action is allowed on all other resources, the action is successful.
A solution to this issue is to attach a policy statement to the identity that uses a [NotResource](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_notresource.html) element to deny any `ModifyInstanceGroup` action issued without a cluster ID. The following example policy adds such a deny statement so that any `ModifyInstanceGroups` request fails unless a cluster ID is specified. Because an identity must specify a cluster ID with the action, deny statements based on cluster ID are therefore effective.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Sid": "AllowELASTICMAPREDUCEModifyinstancegroups"
},
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Effect": "Deny",
"Resource": [
"arn:aws:elasticmapreduce:us-east-1:123456789012:cluster/j-12345ABCDEFG67"
],
"Sid": "DenyELASTICMAPREDUCEModifyinstancegroupsSpecificCluster"
},
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Effect": "Deny",
"NotResource": "arn:*:elasticmapreduce:*:*:cluster/*",
"Sid": "DenyELASTICMAPREDUCEModifyinstancegroupsNonCluster"
}
]
}
```
------
A similar issue exists when you want to deny the `ModifyInstanceGroups` action based on the value associated with a cluster tag. The solution is similar. In addition to a deny statement that specifies the tag value, you can add a policy statement that denies the `ModifyInstanceGroup` action if the tag that you specify is not present, regardless of value.
The following example demonstrates a policy that, when attached to an identity, denies the identity the `ModifyInstanceGroups` action any cluster with the tag `department` set to `dev`. This statement is only effective because of the deny statement that uses the `StringNotLike` condition to deny the action unless the `department` tag is present.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Sid": "AllowELASTICMAPREDUCEModifyinstancegroups"
},
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/department": "dev"
}
},
"Effect": "Deny",
"Resource": [
"*"
],
"Sid": "DenyELASTICMAPREDUCEModifyinstancegroupsDevDepartment"
},
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Condition": {
"StringNotLike": {
"aws:ResourceTag/department": "?*"
}
},
"Effect": "Deny",
"Resource": [
"*"
],
"Sid": "DenyELASTICMAPREDUCEModifyinstancegroupsNoDepartmentTag"
}
]
}
```
------
# Troubleshooting Amazon EMR identity and access
Use the following information to help you diagnose and fix common issues that you might encounter when working with Amazon EMR and IAM.
**Topics**
+ [I am not authorized to perform an action in Amazon EMR](#security_iam_troubleshoot-no-permissions)
+ [I am not authorized to perform iam:PassRole](#security_iam_troubleshoot-passrole)
+ [I want to allow people outside of my AWS account to access my Amazon EMR resources](#security_iam_troubleshoot-cross-account-access)
## I am not authorized to perform an action in Amazon EMR
If the AWS Management Console tells you that you're not authorized to perform an action, then you must contact your administrator for assistance. Your administrator is the person that provided you with your user name and password.
The following example error occurs when the `mateojackson` user tries to use the console to view details about a fictional `my-example-widget` resource but does not have the fictional `EMR:GetWidget` permissions.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: EMR:GetWidget on resource: my-example-widget
```
In this case, Mateo asks his administrator to update his policies to allow him to access the `my-example-widget` resource using the `EMR:GetWidget` action.
## I am not authorized to perform iam:PassRole
If you receive an error that you're not authorized to perform the `iam:PassRole` action, your policies must be updated to allow you to pass a role to Amazon EMR.
Some AWS services allow you to pass an existing role to that service instead of creating a new service role or service-linked role. To do this, you must have permissions to pass the role to the service.
The following example error occurs when an IAM user named `marymajor` tries to use the console to perform an action in Amazon EMR. However, the action requires the service to have permissions that are granted by a service role. Mary does not have permissions to pass the role to the service.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
In this case, Mary's policies must be updated to allow her to perform the `iam:PassRole` action.
If you need help, contact your AWS administrator. Your administrator is the person who provided you with your sign-in credentials.
## I want to allow people outside of my AWS account to access my Amazon EMR resources
You can create a role that users in other accounts or people outside of your organization can use to access your resources. You can specify who is trusted to assume the role. For services that support resource-based policies or access control lists (ACLs), you can use those policies to grant people access to your resources.
To learn more, consult the following:
+ To learn whether Amazon EMR supports these features, see [How Amazon EMR works with IAM](security_iam_service-with-iam.md).
+ To learn how to provide access to your resources across AWS accounts that you own, see [Providing access to an IAM user in another AWS account that you own](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) in the *IAM User Guide*.
+ To learn how to provide access to your resources to third-party AWS accounts, see [Providing access to AWS accounts owned by third parties](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) in the *IAM User Guide*.
+ To learn how to provide access through identity federation, see [Providing access to externally authenticated users (identity federation)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) in the *IAM User Guide*.
+ To learn the difference between using roles and resource-based policies for cross-account access, see [Cross account resource access in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*.