# AWS Identity and Access Management for Amazon EMR AWS Identity and Access Management (IAM) is an AWS service that helps an administrator securely control access to AWS resources. IAM administrators control who can be *authenticated* (signed in) and *authorized* (have permissions) to use Amazon EMR resources. IAM is an AWS service that you can use with no additional charge. **Topics** + [Audience](#security_iam_audience) + [Authenticating with identities](#security_iam_authentication) + [Managing access using policies](#security_iam_access-manage) + [How Amazon EMR works with IAM](security_iam_service-with-iam.md) + [Runtime roles for Amazon EMR steps](emr-steps-runtime-roles.md) + [Configure IAM service roles for Amazon EMR permissions to AWS services and resources](emr-iam-roles.md) + [Amazon EMR identity-based policy examples](security_iam_id-based-policy-examples.md) ## Audience How you use AWS Identity and Access Management (IAM) differs based on your role: + **Service user** - request permissions from your administrator if you cannot access features (see [Troubleshooting Amazon EMR identity and access](security_iam_troubleshoot.md)) + **Service administrator** - determine user access and submit permission requests (see [How Amazon EMR works with IAM](security_iam_service-with-iam.md)) + **IAM administrator** - write policies to manage access (see [Amazon EMR identity-based policy examples](security_iam_id-based-policy-examples.md)) ## Authenticating with identities Authentication is how you sign in to AWS using your identity credentials. You must be authenticated as the AWS account root user, an IAM user, or by assuming an IAM role. You can sign in as a federated identity using credentials from an identity source like AWS IAM Identity Center (IAM Identity Center), single sign-on authentication, or Google/Facebook credentials. For more information about signing in, see [How to sign in to your AWS account](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*. For programmatic access, AWS provides an SDK and CLI to cryptographically sign requests. For more information, see [AWS Signature Version 4 for API requests](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) in the *IAM User Guide*. ### AWS account root user When you create an AWS account, you begin with one sign-in identity called the AWS account *root user* that has complete access to all AWS services and resources. We strongly recommend that you don't use the root user for everyday tasks. For tasks that require root user credentials, see [Tasks that require root user credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) in the *IAM User Guide*. ### Federated identity As a best practice, require human users to use federation with an identity provider to access AWS services using temporary credentials. A *federated identity* is a user from your enterprise directory, web identity provider, or Directory Service that accesses AWS services using credentials from an identity source. Federated identities assume roles that provide temporary credentials. For centralized access management, we recommend AWS IAM Identity Center. For more information, see [What is IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) in the *AWS IAM Identity Center User Guide*. ### IAM users and groups An *[IAM user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* is an identity with specific permissions for a single person or application. We recommend using temporary credentials instead of IAM users with long-term credentials. For more information, see [Require human users to use federation with an identity provider to access AWS using temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) in the *IAM User Guide*. An [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) specifies a collection of IAM users and makes permissions easier to manage for large sets of users. For more information, see [Use cases for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) in the *IAM User Guide*. ### IAM roles An *[IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* is an identity with specific permissions that provides temporary credentials. You can assume a role by [switching from a user to an IAM role (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) or by calling an AWS CLI or AWS API operation. For more information, see [Methods to assume a role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) in the *IAM User Guide*. IAM roles are useful for federated user access, temporary IAM user permissions, cross-account access, cross-service access, and applications running on Amazon EC2. For more information, 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*. ## Managing access using policies You control access in AWS by creating policies and attaching them to AWS identities or resources. A policy defines permissions when associated with an identity or resource. AWS evaluates these policies when a principal makes a request. Most policies are stored in AWS as JSON documents. For more information about JSON policy documents, see [Overview of JSON policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) in the *IAM User Guide*. Using policies, administrators specify who has access to what by defining which **principal** can perform **actions** on what **resources**, and under what **conditions**. By default, users and roles have no permissions. An IAM administrator creates IAM policies and adds them to roles, which users can then assume. IAM policies define permissions regardless of the method used to perform the operation. ### Identity-based policies Identity-based policies are JSON permissions policy documents that you attach to an identity (user, group, or role). These policies control what actions identities can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Define custom IAM permissions with customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*. Identity-based policies can be *inline policies* (embedded directly into a single identity) or *managed policies* (standalone policies attached to multiple identities). To learn how to choose between managed and inline policies, see [Choose between managed policies and inline policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) in the *IAM User Guide*. ### Resource-based policies Resource-based policies are JSON policy documents that you attach to a resource. Examples include IAM *role trust policies* and Amazon S3 *bucket policies*. In services that support resource-based policies, service administrators can use them to control access to a specific resource. You must [specify a principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) in a resource-based policy. Resource-based policies are inline policies that are located in that service. You can't use AWS managed policies from IAM in a resource-based policy. ### Other policy types AWS supports additional policy types that can set the maximum permissions granted by more common policy types: + **Permissions boundaries** – Set the maximum permissions that an identity-based policy can grant to an IAM entity. For more information, see [Permissions boundaries for IAM entities](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) in the *IAM User Guide*. + **Service control policies (SCPs)** – Specify the maximum permissions for an organization or organizational unit in AWS Organizations. For more information, see [Service control policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) in the *AWS Organizations User Guide*. + **Resource control policies (RCPs)** – Set the maximum available permissions for resources in your accounts. For more information, see [Resource control policies (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) in the *AWS Organizations User Guide*. + **Session policies** – Advanced policies passed as a parameter when creating a temporary session for a role or federated user. For more information, see [Session policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) in the *IAM User Guide*. ### Multiple policy types When multiple types of policies apply to a request, the resulting permissions are more complicated to understand. To learn how AWS determines whether to allow a request when multiple policy types are involved, see [Policy evaluation logic](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) in the *IAM User Guide*. # How Amazon EMR works with IAM Before you use IAM to manage access to Amazon EMR, learn what IAM features are available to use with Amazon EMR. **IAM features you can use with Amazon EMR** | IAM feature | Amazon EMR support | | --- | --- | | [Identity-based policies](#security_iam_service-with-iam-id-based-policies) | Yes | | [Resource-based policies](#security_iam_service-with-iam-resource-based-policies) | Yes | | [Policy actions](#security_iam_service-with-iam-id-based-policies-actions) | Yes | | [Policy resources](#security_iam_service-with-iam-id-based-policies-resources) | Yes | | [Policy condition keys](#security_iam_service-with-iam-id-based-policies-conditionkeys) | Yes | | [ACLs](#security_iam_service-with-iam-acls) | No | | [ABAC (tags in policies)](#security_iam_service-with-iam-tags) | Yes | | [Temporary credentials](#security_iam_service-with-iam-roles-tempcreds) | Yes | | [Principal permissions](#security_iam_service-with-iam-principal-permissions) | Yes | | [Service roles](#security_iam_service-with-iam-roles-service) | No | | [Service-linked roles](#security_iam_service-with-iam-roles-service-linked) | Yes | To get a high-level view of how Amazon EMR and other AWS services work with most IAM features, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*. ## Identity-based policies for Amazon EMR **Supports identity-based policies:** Yes Identity-based policies are JSON permissions policy documents that you can attach to an identity, such as an IAM user, group of users, or role. These policies control what actions users and roles can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Define custom IAM permissions with customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*. With IAM identity-based policies, you can specify allowed or denied actions and resources as well as the conditions under which actions are allowed or denied. To learn about all of the elements that you can use in a JSON policy, see [IAM JSON policy elements reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) in the *IAM User Guide*. ### Identity-based policy examples for Amazon EMR To view examples of Amazon EMR identity-based policies, see [Amazon EMR identity-based policy examples](security_iam_id-based-policy-examples.md). ## Resource-based policies within Amazon EMR **Supports resource-based policies:** Yes Resource-based policies are JSON policy documents that you attach to a resource. Examples of resource-based policies are IAM *role trust policies* and Amazon S3 *bucket policies*. In services that support resource-based policies, service administrators can use them to control access to a specific resource. For the resource where the policy is attached, the policy defines what actions a specified principal can perform on that resource and under what conditions. You must [specify a principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) in a resource-based policy. Principals can include accounts, users, roles, federated users, or AWS services. To enable cross-account access, you can specify an entire account or IAM entities in another account as the principal in a resource-based policy. For more information, 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*. ## Policy actions for Amazon EMR **Supports policy actions:** Yes Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**. The `Action` element of a JSON policy describes the actions that you can use to allow or deny access in a policy. Include actions in a policy to grant permissions to perform the associated operation. To see a list of Amazon EMR actions, see [Actions, resources, and condition keys for Amazon EMR](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonemroneksemrcontainers.html) in the *Service Authorization Reference*. Policy actions in Amazon EMR use the following prefix before the action: ``` EMR ``` To specify multiple actions in a single statement, separate them with commas. ``` "Action": [ "EMR:action1", "EMR:action2" ] ``` To view examples of Amazon EMR identity-based policies, see [Amazon EMR identity-based policy examples](security_iam_id-based-policy-examples.md). ## Policy resources for Amazon EMR **Supports policy resources:** Yes Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**. The `Resource` JSON policy element specifies the object or objects to which the action applies. As a best practice, specify a resource using its [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). For actions that don't support resource-level permissions, use a wildcard (\$1) to indicate that the statement applies to all resources. ``` "Resource": "*" ``` To see a list of Amazon EMR resource types and their ARNs, see [Resources Defined by Amazon EMR](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticmapreduce.html#amazonelasticmapreduce-resources-for-iam-policies) in the *Service Authorization Reference*. To learn which actions you can specify the ARN of each resource, see [Actions, resources, and condition keys for Amazon EMR](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonemroneksemrcontainers.html). To view examples of Amazon EMR identity-based policies, see [Amazon EMR identity-based policy examples](security_iam_id-based-policy-examples.md). ## Policy condition keys for Amazon EMR **Supports service-specific policy condition keys:** Yes Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**. The `Condition` element specifies when statements execute based on defined criteria. You can create conditional expressions that use [condition operators](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), such as equals or less than, to match the condition in the policy with values in the request. To see all AWS global condition keys, see [AWS global condition context keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) in the *IAM User Guide*. To see a list of Amazon EMR condition keys and to learn which actions and resources you can use a condition key, see [Actions, resources, and condition keys for Amazon EMR](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonemroneksemrcontainers.html) in the *Service Authorization Reference*. To view examples of Amazon EMR identity-based policies, see [Amazon EMR identity-based policy examples](security_iam_id-based-policy-examples.md). ## Access control lists (ACLs) in Amazon EMR **Supports ACLs:** No Access control lists (ACLs) control which principals (account members, users, or roles) have permissions to access a resource. ACLs are similar to resource-based policies, although they do not use the JSON policy document format. ## Attribute-based access control (ABAC) with Amazon EMR | | | | --- |--- | | Supports ABAC (tags in policies) | Yes | Attribute-based access control (ABAC) is an authorization strategy that defines permissions based on attributes called tags. You can attach tags to IAM entities and AWS resources, then design ABAC policies to allow operations when the principal's tag matches the tag on the resource. To control access based on tags, you provide tag information in the [condition element](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) of a policy using the `aws:ResourceTag/key-name`, `aws:RequestTag/key-name`, or `aws:TagKeys` condition keys. If a service supports all three condition keys for every resource type, then the value is **Yes** for the service. If a service supports all three condition keys for only some resource types, then the value is **Partial**. For more information about ABAC, see [Define permissions with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. To view a tutorial with steps for setting up ABAC, see [Use attribute-based access control (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) in the *IAM User Guide*. ## Using Temporary credentials with Amazon EMR **Supports temporary credentials:** Yes Temporary credentials provide short-term access to AWS resources and are automatically created when you use federation or switch roles. AWS recommends that you dynamically generate temporary credentials instead of using long-term access keys. For more information, see [Temporary security credentials in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) and [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*. ## Cross-service principal permissions for Amazon EMR **Supports forward access sessions (FAS):** Yes Forward access sessions (FAS) use the permissions of the principal calling an AWS service, combined with the requesting AWS service to make requests to downstream services. For policy details when making FAS requests, see [Forward access sessions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html). ## Service roles for Amazon EMR | | | | --- |--- | | Supports service roles | No | ## Service-linked roles for Amazon EMR | | | | --- |--- | | Supports service-linked roles | Yes | For details about creating or managing service-linked roles, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Find a service in the table that includes a `Yes` in the **Service-linked role** column. Choose the **Yes** link to view the service-linked role documentation for that service. ## Use cluster and Notebook tags with IAM policies for access control Permission for Amazon EMR actions associated with EMR Notebooks and EMR clusters can be fine-tuned using tag-based access control with identity-based IAM policies. You can use *condition keys* within a `Condition` element (also called a `Condition` block) to allow certain actions only when a notebook, cluster, or both has a certain tag key or key-value combination. You can also limit the `CreateEditor` action (which creates an EMR notebook) and the `RunJobFlow` action (which creates a cluster) so that a request for a tag must be submitted when the resource is created. In Amazon EMR, the condition keys that can be used in a `Condition` element apply only to those Amazon EMR API actions where `ClusterID` or `NotebookID` is a required request parameter. For example, the [ModifyInstanceGroups](https://docs.aws.amazon.com/ElasticMapReduce/latest/API/API_ModifyInstanceGroups.html) action does not support context keys because `ClusterID` is an optional parameter. When you create an EMR notebook, a default tag is applied with a key string of `creatorUserId` set to the value of the IAM user ID who created the notebook. This is useful for limiting allowed actions for the notebook only to the creator. The following condition keys are available in Amazon EMR: + Use the `elasticmapreduce:ResourceTag/TagKeyString` condition context key to allow or deny user actions on clusters or notebooks with tags that have the `TagKeyString` that you specify. If an action passes both `ClusterID` and `NotebookID`, the condition applies to both the cluster and the notebook. This means that both resources must have the tag key string or key-value combination that you specify. You can use the `Resource` element to limit the statement so that it applies only to clusters or notebooks as required. For more information, see [Amazon EMR identity-based policy examples](security_iam_id-based-policy-examples.md). + Use the `elasticmapreduce:RequestTag/TagKeyString` condition context key to require a specific tag with actions/API calls. For example, you can use this condition context key along with the `CreateEditor` action to require that a key with `TagKeyString` is applied to a notebook when it is created. ## Examples To see a list of Amazon EMR actions, see [Actions Defined by Amazon EMR](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonelasticmapreduce.html#amazonelasticmapreduce-actions-as-permissions) in the *IAM User Guide*. # Runtime roles for Amazon EMR steps A *runtime role* is an AWS Identity and Access Management (IAM) role that you can specify when you submit a job or query to an Amazon EMR cluster. The job or query that you submit to your Amazon EMR cluster uses the runtime role to access AWS resources, such as objects in Amazon S3. You can specify runtime roles with Amazon EMR for Spark and Hive jobs. You can also specify runtime roles when you connect to Amazon EMR clusters in Amazon SageMaker AI and when you attach an Amazon EMR Studio Workspace to an EMR cluster. For more information, see [Connect to an Amazon EMR cluster from SageMaker AI Studio](https://docs.aws.amazon.com/sagemaker/latest/dg/connect-emr-clusters.html) and [Run an EMR Studio Workspace with a runtime role](emr-studio-runtime.md). Previously, Amazon EMR clusters ran Amazon EMR jobs or queries with permissions based on the IAM policy attached to the instance profile that you used to launch the cluster. This meant that the policies had to contain the union of all the permissions for all jobs and queries that ran on an Amazon EMR cluster. With runtime roles, you can now manage access control for each job or query individually, instead of sharing the Amazon EMR instance profile of the cluster. On Amazon EMR clusters with runtime roles, you can also apply AWS Lake Formation based access control to Spark, Hive, and Presto jobs and queries against your data lakes. To learn more on how to integrate with AWS Lake Formation, see [Integrate Amazon EMR with AWS Lake Formation](emr-lake-formation.md). **Note** When you specify a runtime role for an Amazon EMR step, the jobs or queries that you submit can only access AWS resources that the policies attached to the runtime role allow. These jobs and queries can't access the Instance Metadata Service on the EC2 instances of the cluster or use the EC2 instance profile of the cluster to access any AWS resources. ## Prerequisites for launching an Amazon EMR cluster with a runtime role **Topics** + [Step 1: Set up security configurations in Amazon EMR](#configure-security) + [Step 2: Set up an EC2 instance profile for the Amazon EMR cluster](#configure-ec2-profile) + [Step 3: Set up a trust policy](#configure-trust-policy) ### Step 1: Set up security configurations in Amazon EMR Use the following JSON structure to create a security configuration on the AWS Command Line Interface (AWS CLI), and set `EnableApplicationScopedIAMRole` to `true`. For more information about security configurations, see [Use security configurations to set up Amazon EMR cluster security](emr-security-configurations.md). ``` { "AuthorizationConfiguration":{ "IAMConfiguration":{ "EnableApplicationScopedIAMRole":true } } } ``` We recommend that you always enable the in-transit encryption options in the security configuration, so that data transferred over the internet is encrypted, rather than in plain text. You can skip these options if you don’t want to connect to Amazon EMR clusters with runtime roles from SageMaker Runtime Studio or EMR Studio. To configure data encryption, see [Configure data encryption](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-create-security-configuration.html#emr-security-configuration-encryption). Alternatively, you can create a security configuration with custom settings with the [AWS Management Console](https://console.aws.amazon.com/emr/home#/securityConfigs). ### Step 2: Set up an EC2 instance profile for the Amazon EMR cluster Amazon EMR clusters use the Amazon EC2 instance profile role to assume the runtime roles. To use runtime roles with Amazon EMR steps, add the following policies to the IAM role that you plan to use as the instance profile role. To add policies to an IAM role or edit an existing inline or managed policy, see [Adding and removing IAM identity permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowRuntimeRoleUsage", "Effect": "Allow", "Action": [ "sts:AssumeRole", "sts:TagSession" ], "Resource": [ "arn:aws:iam::123456789012:role/EMRRuntimeRole" ] } ] } ``` ------ ### Step 3: Set up a trust policy For each IAM role that you plan to use as a runtime role, set the following trust policy, replacing `EMR_EC2_DefaultRole` with your instance profile role. To modify the trust policy of an IAM role, see [Modifying a role trust policy](https://docs.aws.amazon.com//IAM/latest/UserGuide/roles-managingrole-editing-console.html). ``` { "Sid":"AllowAssumeRole", "Effect":"Allow", "Principal":{ "AWS":"arn:aws:iam:::role/EMR_EC2_DefaultRole" }, "Action":[ "sts:AssumeRole", "sts:TagSession" ] } ``` ## Launch an Amazon EMR cluster with role-based access control After you set up your configurations, you can launch an Amazon EMR cluster with the security configuration from [Step 1: Set up security configurations in Amazon EMR](#configure-security). To use runtime roles with Amazon EMR steps, use release label `emr-6.7.0` or later, and select Hive, Spark, or both as your cluster application. CloudWatchAgent is supported on Runtime Role Clusters for EMR 7.6 and above. To connect from SageMaker AI Studio, use release `emr-6.9.0` or later, and select Livy, Spark, Hive, or Presto as your cluster application. For instructions on how to launch your cluster, see [Specify a security configuration for an Amazon EMR cluster](emr-specify-security-configuration.md). ### Submit Spark jobs using Amazon EMR steps The following is an example of how to run the HdfsTest example included with Apache Spark. This API call only succeeds if the provided Amazon EMR runtime role can access the `S3_LOCATION`. ``` RUNTIME_ROLE_ARN= S3_LOCATION= REGION= CLUSTER_ID= aws emr add-steps --cluster-id $CLUSTER_ID \ --steps '[{ "Name": "Spark Example", "ActionOnFailure": "CONTINUE", "Jar":"command-runner.jar","Args" : ["spark-example","HdfsTest", "$S3_LOCATION"] }]' \ --execution-role-arn $RUNTIME_ROLE_ARN \ --region $REGION ``` **Note** We recommend that you turn off SSH access to the Amazon EMR cluster and only allow the Amazon EMR `AddJobFlowSteps` API to access to the cluster. ### Submit Hive jobs using Amazon EMR steps The following example uses Apache Hive with Amazon EMR steps to submit a job to run the `QUERY_FILE.hql` file. This query only succeeds if the provided runtime role can access the Amazon S3 path of the query file. ``` RUNTIME_ROLE_ARN= REGION= CLUSTER_ID= aws emr add-steps --cluster-id $CLUSTER_ID \ --steps '[{ "Name": "Run hive query using command-runner.jar - simple select","ActionOnFailure":"CONTINUE", "Jar": "command-runner.jar","Args" :["hive - f","s3://DOC_EXAMPLE_BUCKET/QUERY_FILE.hql"] }]' \ --execution-role-arn $RUNTIME_ROLE_ARN \ --region $REGION ``` ### Connect to Amazon EMR clusters with runtime roles from a SageMaker AI Studio notebook You can apply Amazon EMR runtime roles to queries that you run in Amazon EMR clusters from SageMaker AI Studio. To do so, go through the following steps. 1. Follow the instructions in [Launch Amazon SageMaker AI Studio]() to create an SageMaker AI Studio. 1. In the SageMaker AI Studio UI, start a notebook with supported kernels. For example, start a SparkMagic image with a PySpark kernel. 1. Choose an Amazon EMR cluster in SageMaker AI Studio, and then choose **Connect**. 1. Choose a runtime role, and then choose **Connect**. This will create an SageMaker AI notebook cell with magic commands to connect to your Amazon EMR cluster with the chosen Amazon EMR runtime role. In the notebook cell, you can enter and run queries with runtime role and Lake Formation based access control. For a more detailed example, see [Apply fine-grained data access controls with AWS Lake Formation and Amazon EMR from Amazon SageMaker AI Studio](https://aws.amazon.com/blogs/machine-learning/apply-fine-grained-data-access-controls-with-aws-lake-formation-and-amazon-emr-from-amazon-sagemaker-studio). ### Control access to the Amazon EMR runtime role You can control access to the runtime role with the condition key `elasticmapreduce:ExecutionRoleArn`. The following policy allows an IAM principal to use an IAM role named `Caller`, or any IAM role that begins with the string `CallerTeamRole`, as the runtime role. **Important** You must create a condition based on the `elasticmapreduce:ExecutionRoleArn` context key when you grant a caller access to call the `AddJobFlowSteps` or `GetClusterSessionCredentials` APIs, as the following example shows. ``` { "Sid":"AddStepsWithSpecificExecRoleArn", "Effect":"Allow", "Action":[ "elasticmapreduce:AddJobFlowSteps" ], "Resource":"*", "Condition":{ "StringEquals":{ "elasticmapreduce:ExecutionRoleArn":[ "arn:aws:iam:::role/Caller" ] }, "StringLike":{ "elasticmapreduce:ExecutionRoleArn":[ "arn:aws:iam:::role/CallerTeamRole*" ] } } } ``` ### Establish trust between runtime roles and Amazon EMR clusters Amazon EMR generates a unique identifier `ExternalId` for each security configuration with activated runtime role authorization. This authorization allows every user to own a set of runtime roles to use on clusters that belong to them. For example, in an enterprise, every department can use their external ID to update the trust policy on their own set of runtime roles. You can find the external ID with the Amazon EMR `DescribeSecurityConfiguration` API, as shown in the following example. ``` aws emr describe-security-configuration --name 'iamconfig-with-lf'{"Name": "iamconfig-with-lf", "SecurityConfiguration": "{\"AuthorizationConfiguration\":{\"IAMConfiguration\":{\"EnableApplicationScopedIAMRole\ ":true,\"ApplicationScopedIAMRoleConfiguration\":{\"PropagateSourceIdentity\":true,\"Exter nalId\":\"FXH5TSACFDWUCDSR3YQE2O7ETPUSM4OBCGLYWODSCUZDNZ4Y\"}},\"Lake FormationConfiguration\":{\"AuthorizedSessionTagValue\":\"Amazon EMR\"}}}", "CreationDateTime": "2022-06-03T12:52:35.308000-07:00" } ``` For information about how to use an external ID, see [How to use an external ID when granting access to your AWS resources to a third party](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html). ### Audit To monitor and control actions that end users take with IAM roles, you can turn on the source identity feature. To learn more about source identity, see [Monitor and control actions taken with assumed roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_monitor). To track source identity, set `ApplicationScopedIAMRoleConfiguration/PropagateSourceIdentity` to `true` in your security configuration, as follows. ``` { "AuthorizationConfiguration":{ "IAMConfiguration":{ "EnableApplicationScopedIAMRole":true, "ApplicationScopedIAMRoleConfiguration":{ "PropagateSourceIdentity":true } } } } ``` When you set `PropagateSourceIdentity` to `true`, Amazon EMR applies the source identity from the calling credentials to a job or query session that you create with the runtime role. If no source identity is present in the calling credentials, Amazon EMR doesn't set the source identity. To use this property, provide `sts:SetSourceIdentity` permissions to your instance profile, as follows. ``` { // PropagateSourceIdentity statement "Sid":"PropagateSourceIdentity", "Effect":"Allow", "Action":"sts:SetSourceIdentity", "Resource":[ ], "Condition":{ "StringEquals":{ "sts:SourceIdentity": } } } ``` You must also add the `AllowSetSourceIdentity` statement to the trust policy of your runtime roles. ``` { // AllowSetSourceIdentity statement "Sid":"AllowSetSourceIdentity", "Effect":"Allow", "Principal":{ "AWS":"arn:aws:iam:::role/EMR_EC2_DefaultRole" }, "Action":[ "sts:SetSourceIdentity", "sts:AssumeRole" ], "Condition":{ "StringEquals":{ "sts:SourceIdentity": } } } ``` ## Additional considerations **Note** With Amazon EMR release `emr-6.9.0`, you might experience intermittent failures when you connect to Amazon EMR clusters from SageMaker AI Studio. To address this issue, you can install the patch with a bootstrap action when you launch the cluster. For patch details, see [Amazon EMR release 6.9.0 known issues](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-690-release.html#emr-690-relnotes). Additionally, consider the following when you configure runtime roles for Amazon EMR. + Amazon EMR supports runtime roles in all commercial AWS Regions. + Amazon EMR steps support Apache Spark and Apache Hive jobs with runtime roles when you use release `emr-6.7.0` or later. + SageMaker AI Studio supports Spark, Hive, and Presto queries with runtime roles when you use release `emr-6.9.0` or later. + The following notebook kernels in SageMaker AI support runtime roles: + DataScience – Python 3 kernel + DataScience 2.0 – Python 3 kernel + DataScience 3.0 – Python 3 kernel + SparkAnalytics 1.0 – SparkMagic and PySpark kernels + SparkAnalytics 2.0 – SparkMagic and PySpark kernels + SparkMagic – PySpark kernel + Amazon EMR supports steps that use `RunJobFlow` only at the time of cluster creation. This API doesn't support runtime roles. + Amazon EMR doesn't support runtime roles on clusters that you configure to be highly-available. + Starting with Amazon EMR release 7.5.0 and higher, runtime roles support viewing Spark and YARN User Interfaces (UIs), such as the following: Spark Live UI, Spark History Server, YARN NodeManager, and YARN ResourceManager. When you navigate to these UIs, there is a username and password prompt. Usernames and passwords can be generated through use of the EMR GetClusterSessionCredentials API. For more information regarding usage details for the API, see [GetClusterSessionCredentials](https://docs.aws.amazon.com/emr/latest/APIReference/API_GetClusterSessionCredentials.html). An example of how to use the EMR GetClusterSessionCredentials API is the following: ``` aws emr get-cluster-session-credentials --cluster-id --execution-role-arn ``` + You must escape your Bash command arguments when running commands with the `command-runner.jar` JAR file: ``` aws emr add-steps --cluster-id --steps '[{"Name":"sample-step","ActionOnFailure":"CONTINUE","Jar":"command-runner.jar","Properties":"","Args":["bash","-c","\"aws s3 ls\""],"Type":"CUSTOM_JAR"}]' --execution-role-arn ``` Additionally, you must escape your Bash command arguments when running commands with the script runner. The following is a sample that shows setting Spark properties, with included escape characters: ``` "\"--conf spark.sql.autoBroadcastJoinThreshold=-1\"" ``` + Runtime roles don't provide support for controlling access to on-cluster resources, such as HDFS and HMS. + Runtime roles don't provide support for docker/containers. # Configure IAM service roles for Amazon EMR permissions to AWS services and resources Amazon EMR and applications such as Hadoop and Spark need permissions to access other AWS resources and perform actions when they run. Each cluster in Amazon EMR must have a *service role* and a role for the Amazon EC2 *instance profile*. For more information, see [IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) and [Using instance profiles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html) in the *IAM User Guide*. The IAM policies attached to these roles provide permissions for the cluster to interoperate with other AWS services on behalf of a user. An additional role, the Auto Scaling role, is required if your cluster uses automatic scaling in Amazon EMR. The AWS service role for EMR Notebooks is required if you use EMR Notebooks. Amazon EMR provides default roles and default managed policies that determine permissions for each role. Managed policies are created and maintained by AWS, so they are updated automatically if service requirements change. See [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies.html) in the *IAM User Guide*. If you are creating a cluster or notebook for the first time in an account, roles for Amazon EMR do not yet exist. After you create them, you can view the roles, the policies attached to them, and the permissions allowed or denied by the policies in the IAM console ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)). You can specify default roles for Amazon EMR to create and use, you can create your own roles and specify them individually when you create a cluster to customize permissions, and you can specify default roles to be used when you create a cluster using the AWS CLI. For more information, see [Customize IAM roles with Amazon EMR](emr-iam-roles-custom.md). ## Modifying identity-based policies for permissions to pass service roles for Amazon EMR 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. ## Service role summary The following table lists the IAM service roles associated with Amazon EMR for quick reference. | Function | Default role | Description | Default managed policy | | --- | --- | --- | --- | | [Service role for Amazon EMR (EMR role)](emr-iam-role.md) | `EMR_DefaultRole_V2` | 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. | `AmazonEMRServicePolicy_v2` A service-linked role is required to request Spot Instances. If this role doesn't exist, the Amazon EMR service role must have permission to create it or a permission error occurs. If you plan to request Spot Instances, you must update this policy to include a statement that allows the creation of this service-linked role. For more information, see [Service role for Amazon EMR (EMR role)](emr-iam-role.md) and [Service-linked role for Spot Instance requests](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html#service-linked-roles-spot-instance-requests) in the *Amazon EC2 User Guide*. | | [Service role for cluster EC2 instances (EC2 instance profile)](emr-iam-role-for-ec2.md) | `EMR_EC2_DefaultRole` | Application processes that run on top of the Hadoop ecosystem on cluster instances use this role when they call other AWS services. For accessing data in Amazon S3 using EMRFS, you can specify different roles to be assumed based on the location of data in Amazon S3. For example, multiple teams can access a single Amazon S3 data "storage account." For more information, see [Configure IAM roles for EMRFS requests to Amazon S3](emr-emrfs-iam-roles.md). This role is required for all clusters. | `AmazonElasticMapReduceforEC2Role`. For more information, see [Service role for cluster EC2 instances (EC2 instance profile)](emr-iam-role-for-ec2.md). | | [Service role for automatic scaling in Amazon EMR (Auto Scaling role)](emr-iam-role-automatic-scaling.md) | `EMR_AutoScaling_DefaultRole` | Allows additional actions for dynamically scaling environments. Required only for clusters that use automatic scaling in Amazon EMR. For more information, see [Using automatic scaling with a custom policy for instance groups in Amazon EMR](emr-automatic-scaling.md). | `AmazonElasticMapReduceforAutoScalingRole`. For more information, see [Service role for automatic scaling in Amazon EMR (Auto Scaling role)](emr-iam-role-automatic-scaling.md). | | [Service role for EMR Notebooks](emr-managed-notebooks-service-role.md) | `EMR_Notebooks_DefaultRole` | Provides permissions that an EMR notebook needs to access other AWS resources and perform actions. Required only if EMR Notebooks is used. | `AmazonElasticMapReduceEditorsRole`. For more information, see [Service role for EMR Notebooks](emr-managed-notebooks-service-role.md). `S3FullAccessPolicy` is also attached by default. Following is the contents of this policy. JSON **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:*" ], "Resource": [ "*" ], "Sid": "AllowS3" } ] } ``` | | [Service-Linked Role](using-service-linked-roles.md) | `AWSServiceRoleForEMRCleanup` | Amazon EMR automatically creates a service-linked role. If the service for Amazon EMR has lost the ability to clean up Amazon EC2 resources, Amazon EMR can use this role to clean up. If a cluster uses Spot Instances, the permissions policy attached to the [Service role for Amazon EMR (EMR role)](emr-iam-role.md) must allow the creation of a service-linked role. For more information, see [Using service-linked roles for Amazon EMR](using-service-linked-roles.md). | `AmazonEMRCleanupPolicy` | **Topics** + [Modifying identity-based policies for permissions to pass service roles for Amazon EMR](#emr-iam-roles-passrole) + [Service role summary](#emr-iam-roles-summary) + [IAM service roles used by Amazon EMR](emr-iam-service-roles.md) + [Customize IAM roles with Amazon EMR](emr-iam-roles-custom.md) + [Configure IAM roles for EMRFS requests to Amazon S3](emr-emrfs-iam-roles.md) + [Use resource-based policies for Amazon EMR access to AWS Glue Data Catalog](emr-iam-roles-glue.md) + [Use IAM roles with applications that call AWS services directly](emr-iam-roles-calling.md) + [Allow users and groups to create and modify roles](emr-iam-roles-create-permissions.md) # IAM service roles used by Amazon EMR Amazon EMR uses IAM service roles to perform actions on your behalf when provisioning cluster resources, running applications, dynamically scaling resources, and creating and running EMR Notebooks. Amazon EMR uses the following roles when interacting with other AWS services. Each role has a unique function within Amazon EMR. The topics in this section describe the role function and provide the default roles and permissions policy for each role. If you have application code on your cluster that calls AWS services directly, you may need to use the SDK to specify roles. For more information, see [Use IAM roles with applications that call AWS services directly](emr-iam-roles-calling.md). **Topics** + [Service role for Amazon EMR (EMR role)](emr-iam-role.md) + [Service role for cluster EC2 instances (EC2 instance profile)](emr-iam-role-for-ec2.md) + [Service role for automatic scaling in Amazon EMR (Auto Scaling role)](emr-iam-role-automatic-scaling.md) + [Service role for EMR Notebooks](emr-managed-notebooks-service-role.md) + [Using service-linked roles for Amazon EMR](using-service-linked-roles.md) # Service role for Amazon EMR (EMR role) The Amazon EMR role defines the allowable actions for Amazon EMR when it provisions resources and performs service-level tasks that aren't performed in the context of an Amazon EC2 instance running within a cluster. For example, the service role is used to provision EC2 instances when a cluster launches. + The default role name is `EMR_DefaultRole_V2`. + The Amazon EMR scoped default managed policy attached to `EMR_DefaultRole_V2` is `AmazonEMRServicePolicy_v2`. This v2 policy replaces the deprecated default managed policy, `AmazonElasticMapReduceRole`. `AmazonEMRServicePolicy_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 those tags. 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. See [Tagging resources to use managed policies](emr-managed-iam-policies.md#manually-tagged-resources). **Important** Amazon EMR uses this Amazon EMR service role and the `AWSServiceRoleForEMRCleanup` role to clean up cluster resources in your account that you no longer use, such as Amazon EC2 instances. You must include actions for the role policies to delete or terminate the resources. Otherwise, Amazon EMR can’t perform these cleanup actions, and you might incur costs for unused resources that remain on the cluster. The following shows the contents of the current `AmazonEMRServicePolicy_v2` policy. You can also see the current content of the [https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRServicePolicy_v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRServicePolicy_v2) managed policy on the IAM console. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "CreateInTaggedNetwork", "Effect": "Allow", "Action": [ "ec2:CreateNetworkInterface", "ec2:RunInstances", "ec2:CreateFleet", "ec2:CreateLaunchTemplate", "ec2:CreateLaunchTemplateVersion" ], "Resource": [ "arn:aws:ec2:*:*:subnet/*", "arn:aws:ec2:*:*:security-group/*" ], "Condition": { "StringEquals": { "aws:ResourceTag/for-use-with-amazon-emr-managed-policies": "true" } } }, { "Sid": "CreateWithEMRTaggedLaunchTemplate", "Effect": "Allow", "Action": [ "ec2:CreateFleet", "ec2:RunInstances", "ec2:CreateLaunchTemplateVersion" ], "Resource": [ "arn:aws:ec2:*:*:launch-template/*" ], "Condition": { "StringEquals": { "aws:ResourceTag/for-use-with-amazon-emr-managed-policies": "true" } } }, { "Sid": "CreateEMRTaggedLaunchTemplate", "Effect": "Allow", "Action": [ "ec2:CreateLaunchTemplate" ], "Resource": [ "arn:aws:ec2:*:*:launch-template/*" ], "Condition": { "StringEquals": { "aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true" } } }, { "Sid": "CreateEMRTaggedInstancesAndVolumes", "Effect": "Allow", "Action": [ "ec2:RunInstances", "ec2:CreateFleet" ], "Resource": [ "arn:aws:ec2:*:*:instance/*", "arn:aws:ec2:*:*:volume/*" ], "Condition": { "StringEquals": { "aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true" } } }, { "Sid": "ResourcesToLaunchEC2", "Effect": "Allow", "Action": [ "ec2:RunInstances", "ec2:CreateFleet", "ec2:CreateLaunchTemplate", "ec2:CreateLaunchTemplateVersion" ], "Resource": [ "arn:aws:ec2:*:*:network-interface/*", "arn:aws:ec2:*::image/ami-*", "arn:aws:ec2:*:*:key-pair/*", "arn:aws:ec2:*:*:capacity-reservation/*", "arn:aws:ec2:*:*:placement-group/pg-*", "arn:aws:ec2:*:*:fleet/*", "arn:aws:ec2:*:*:dedicated-host/*", "arn:aws:resource-groups:*:*:group/*" ] }, { "Sid": "ManageEMRTaggedResources", "Effect": "Allow", "Action": [ "ec2:CreateLaunchTemplateVersion", "ec2:DeleteLaunchTemplate", "ec2:DeleteNetworkInterface", "ec2:ModifyInstanceAttribute", "ec2:TerminateInstances" ], "Resource": [ "*" ], "Condition": { "StringEquals": { "aws:ResourceTag/for-use-with-amazon-emr-managed-policies": "true" } } }, { "Sid": "ManageTagsOnEMRTaggedResources", "Effect": "Allow", "Action": [ "ec2:CreateTags", "ec2:DeleteTags" ], "Resource": [ "arn:aws:ec2:*:*:instance/*", "arn:aws:ec2:*:*:volume/*", "arn:aws:ec2:*:*:network-interface/*", "arn:aws:ec2:*:*:launch-template/*" ], "Condition": { "StringEquals": { "aws:ResourceTag/for-use-with-amazon-emr-managed-policies": "true" } } }, { "Sid": "CreateNetworkInterfaceNeededForPrivateSubnet", "Effect": "Allow", "Action": [ "ec2:CreateNetworkInterface" ], "Resource": [ "arn:aws:ec2:*:*:network-interface/*" ], "Condition": { "StringEquals": { "aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true" } } }, { "Sid": "TagOnCreateTaggedEMRResources", "Effect": "Allow", "Action": [ "ec2:CreateTags" ], "Resource": [ "arn:aws:ec2:*:*:network-interface/*", "arn:aws:ec2:*:*:instance/*", "arn:aws:ec2:*:*:volume/*", "arn:aws:ec2:*:*:launch-template/*" ], "Condition": { "StringEquals": { "ec2:CreateAction": [ "RunInstances", "CreateFleet", "CreateLaunchTemplate", "CreateNetworkInterface" ] } } }, { "Sid": "TagPlacementGroups", "Effect": "Allow", "Action": [ "ec2:CreateTags", "ec2:DeleteTags" ], "Resource": [ "arn:aws:ec2:*:*:placement-group/pg-*" ] }, { "Sid": "ListActionsForEC2Resources", "Effect": "Allow", "Action": [ "ec2:DescribeAccountAttributes", "ec2:DescribeCapacityReservations", "ec2:DescribeDhcpOptions", "ec2:DescribeImages", "ec2:DescribeInstances", "ec2:DescribeInstanceTypeOfferings", "ec2:DescribeLaunchTemplates", "ec2:DescribeNetworkAcls", "ec2:DescribeNetworkInterfaces", "ec2:DescribePlacementGroups", "ec2:DescribeRouteTables", "ec2:DescribeSecurityGroups", "ec2:DescribeSubnets", "ec2:DescribeVolumes", "ec2:DescribeVolumeStatus", "ec2:DescribeVpcAttribute", "ec2:DescribeVpcEndpoints", "ec2:DescribeVpcs" ], "Resource": [ "*" ] }, { "Sid": "CreateDefaultSecurityGroupWithEMRTags", "Effect": "Allow", "Action": [ "ec2:CreateSecurityGroup" ], "Resource": [ "arn:aws:ec2:*:*:security-group/*" ], "Condition": { "StringEquals": { "aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true" } } }, { "Sid": "CreateDefaultSecurityGroupInVPCWithEMRTags", "Effect": "Allow", "Action": [ "ec2:CreateSecurityGroup" ], "Resource": [ "arn:aws:ec2:*:*:vpc/*" ], "Condition": { "StringEquals": { "aws:ResourceTag/for-use-with-amazon-emr-managed-policies": "true" } } }, { "Sid": "TagOnCreateDefaultSecurityGroupWithEMRTags", "Effect": "Allow", "Action": [ "ec2:CreateTags" ], "Resource": [ "arn:aws:ec2:*:*:security-group/*" ], "Condition": { "StringEquals": { "aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true", "ec2:CreateAction": "CreateSecurityGroup" } } }, { "Sid": "ManageSecurityGroups", "Effect": "Allow", "Action": [ "ec2:AuthorizeSecurityGroupEgress", "ec2:AuthorizeSecurityGroupIngress", "ec2:RevokeSecurityGroupEgress", "ec2:RevokeSecurityGroupIngress" ], "Resource": [ "*" ], "Condition": { "StringEquals": { "aws:ResourceTag/for-use-with-amazon-emr-managed-policies": "true" } } }, { "Sid": "CreateEMRPlacementGroups", "Effect": "Allow", "Action": [ "ec2:CreatePlacementGroup" ], "Resource": [ "arn:aws:ec2:*:*:placement-group/pg-*" ] }, { "Sid": "DeletePlacementGroups", "Effect": "Allow", "Action": [ "ec2:DeletePlacementGroup" ], "Resource": [ "*" ] }, { "Sid": "AutoScaling", "Effect": "Allow", "Action": [ "application-autoscaling:DeleteScalingPolicy", "application-autoscaling:DeregisterScalableTarget", "application-autoscaling:DescribeScalableTargets", "application-autoscaling:DescribeScalingPolicies", "application-autoscaling:PutScalingPolicy", "application-autoscaling:RegisterScalableTarget" ], "Resource": [ "*" ] }, { "Sid": "ResourceGroupsForCapacityReservations", "Effect": "Allow", "Action": [ "resource-groups:ListGroupResources" ], "Resource": [ "*" ] }, { "Sid": "AutoScalingCloudWatch", "Effect": "Allow", "Action": [ "cloudwatch:PutMetricAlarm", "cloudwatch:DeleteAlarms", "cloudwatch:DescribeAlarms" ], "Resource": [ "arn:aws:cloudwatch:*:*:alarm:*_EMR_Auto_Scaling" ] }, { "Sid": "PassRoleForAutoScaling", "Effect": "Allow", "Action": [ "iam:PassRole" ], "Resource": [ "arn:aws:iam::*:role/EMR_AutoScaling_DefaultRole" ], "Condition": { "StringLike": { "iam:PassedToService": "application-autoscaling.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": "CreateAndModifyEmrServiceVPCEndpoint", "Effect": "Allow", "Action": [ "ec2:ModifyVpcEndpoint", "ec2:CreateVpcEndpoint" ], "Resource": [ "arn:aws:ec2:*:*:vpc-endpoint/*", "arn:aws:ec2:*:*:subnet/*", "arn:aws:ec2:*:*:security-group/*", "arn:aws:ec2:*:*:vpc/*" ], "Condition": { "StringEquals": { "aws:ResourceTag/for-use-with-amazon-emr-managed-policies": "true" } } }, { "Sid": "CreateEmrServiceVPCEndpoint", "Effect": "Allow", "Action": [ "ec2:CreateVpcEndpoint" ], "Resource": [ "arn:aws:ec2:*:*:vpc-endpoint/*" ], "Condition": { "StringEquals": { "aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true", "aws:RequestTag/Name": "emr-service-vpce" } } }, { "Sid": "TagEmrServiceVPCEndpoint", "Effect": "Allow", "Action": [ "ec2:CreateTags" ], "Resource": [ "arn:aws:ec2:*:*:vpc-endpoint/*" ], "Condition": { "StringEquals": { "ec2:CreateAction": "CreateVpcEndpoint", "aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true", "aws:RequestTag/Name": "emr-service-vpce" } } } ] } ``` ------ Your service role should use the following trust policy. **Important** The following trust policy includes the [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) and [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) global condition keys, which limit the permissions that you give Amazon EMR to particular resources in your account. Using them can protect you against [the confused deputy problem](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowSTSAssumerole", "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Resource": "arn:aws:iam::123456789012:role/EMRServiceRole", "Condition": { "StringEquals": { "aws:SourceAccount": "123456789012" }, "ArnLike": { "aws:SourceArn": "arn:aws:elasticmapreduce:*:123456789012:*" } } } ] } ``` ------ # Service role for cluster EC2 instances (EC2 instance profile) The service role for cluster EC2 instances (also called the EC2 instance profile for Amazon EMR) is a special type of service role that is assigned to every EC2 instance in an Amazon EMR cluster when the instance launches. Application processes that run on top of the Hadoop ecosystem assume this role for permissions to interact with other AWS services. For more information about service roles for EC2 instances, see [Using an IAM role to grant permissions to applications running on Amazon EC2 instances](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) in the *IAM User Guide*. **Important** The default service role for cluster EC2 instances and its associated AWS default managed policy, `AmazonElasticMapReduceforEC2Role` are on the path to deprecation, with no replacement AWS managed policies provided. You'll need to create and specify an instance profile to replace the deprecated role and default policy. ## Default role and managed policy + The default role name is `EMR_EC2_DefaultRole`. + The `EMR_EC2_DefaultRole` default managed policy, `AmazonElasticMapReduceforEC2Role`, is nearing end of support. Instead of using a default managed policy for the EC2 instance profile, apply resource-based policies to S3 buckets and other resources that Amazon EMR needs, or use your own customer-managed policy with an IAM role as an instance profile. For more information, see [Creating a service role for cluster EC2 instances with least-privilege permissions](#emr-ec2-role-least-privilege). The following shows the contents of version 3 of `AmazonElasticMapReduceforEC2Role`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Resource": [ "*" ], "Action": [ "cloudwatch:*", "dynamodb:*", "ec2:Describe*", "elasticmapreduce:Describe*", "elasticmapreduce:ListBootstrapActions", "elasticmapreduce:ListClusters", "elasticmapreduce:ListInstanceGroups", "elasticmapreduce:ListInstances", "elasticmapreduce:ListSteps", "kinesis:CreateStream", "kinesis:DeleteStream", "kinesis:DescribeStream", "kinesis:GetRecords", "kinesis:GetShardIterator", "kinesis:MergeShards", "kinesis:PutRecord", "kinesis:SplitShard", "rds:Describe*", "s3:*", "sdb:*", "sns:*", "sqs:*", "glue:CreateDatabase", "glue:UpdateDatabase", "glue:DeleteDatabase", "glue:GetDatabase", "glue:GetDatabases", "glue:CreateTable", "glue:UpdateTable", "glue:DeleteTable", "glue:GetTable", "glue:GetTables", "glue:GetTableVersions", "glue:CreatePartition", "glue:BatchCreatePartition", "glue:UpdatePartition", "glue:DeletePartition", "glue:BatchDeletePartition", "glue:GetPartition", "glue:GetPartitions", "glue:BatchGetPartition", "glue:CreateUserDefinedFunction", "glue:UpdateUserDefinedFunction", "glue:DeleteUserDefinedFunction", "glue:GetUserDefinedFunction", "glue:GetUserDefinedFunctions" ], "Sid": "AllowCLOUDWATCH" } ] } ``` ------ Your service role should use the following trust policy. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowSTSAssumerole", "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Resource": "arn:aws:iam::123456789012:role/EMR_EC2_DefaultRole" } ] } ``` ------ ## Creating a service role for cluster EC2 instances with least-privilege permissions As a best practice, we strongly recommend that you create a service role for cluster EC2 instances and permissions policy that has the minimum permissions to other AWS services required by your application. The default managed policy, `AmazonElasticMapReduceforEC2Role`, provides permissions that make it easy to launch an initial cluster. However, `AmazonElasticMapReduceforEC2Role` is on the path to deprecation and Amazon EMR will not provide a replacement AWS managed default policy for the deprecated role. To launch an initial cluster, you need to provide a customer managed resource-based or ID-based policy. The following policy statements provide examples of the permissions required for different features of Amazon EMR. We recommend that you use these permissions to create a permissions policy that restricts access to only those features and resources that your cluster requires. All example policy statements use the *us-west-2* Region and the fictional AWS account ID *123456789012*. Replace these as appropriate for your cluster. For more information about creating and specifying custom roles, see [Customize IAM roles with Amazon EMR](emr-iam-roles-custom.md). **Note** If you create a custom EMR role for EC2, follow the basic work flow, which automatically creates an instance profile of the same name. Amazon EC2 allows you to create instance profiles and roles with different names, but Amazon EMR does not support this configuration, and it results in an "invalid instance profile" error when you create the cluster. ### Reading and writing data to Amazon S3 using EMRFS When an application running on an Amazon EMR cluster references data using the `s3://mydata` format, Amazon EMR uses the EC2 instance profile to make the request. Clusters typically read and write data to Amazon S3 in this way, and Amazon EMR uses the permissions attached to the service role for cluster EC2 instances by default. For more information, see [Configure IAM roles for EMRFS requests to Amazon S3](emr-emrfs-iam-roles.md). Because IAM roles for EMRFS will fall back to the permissions attached to the service role for cluster EC2 instances, as a best practice, we recommend that you use IAM roles for EMRFS, and limit the EMRFS and Amazon S3 permissions attached to the service role for cluster EC2 instances. The sample statement below demonstrates the permissions that EMRFS requires to make requests to Amazon S3. + *my-data-bucket-in-s3-for-emrfs-reads-and-writes* specifies the bucket in Amazon S3 where the cluster reads and writes data and all sub-folders using */\$1*. Add only those buckets and folders that your application requires. + The policy statement that allows `dynamodb` actions is required only if EMRFS consistent view is enabled. *EmrFSMetadata* specifies the default folder for EMRFS consistent view. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:AbortMultipartUpload", "s3:CreateBucket", "s3:DeleteObject", "s3:GetBucketVersioning", "s3:GetObject", "s3:GetObjectTagging", "s3:GetObjectVersion", "s3:ListBucket", "s3:ListBucketMultipartUploads", "s3:ListBucketVersions", "s3:ListMultipartUploadParts", "s3:PutBucketVersioning", "s3:PutObject", "s3:PutObjectTagging" ], "Resource": [ "arn:aws:s3:::my-data-bucket-in-s3-for-emrfs-reads-and-writes", "arn:aws:s3:::my-data-bucket-in-s3-for-emrfs-reads-and-writes/*" ], "Sid": "AllowS3Abortmultipartupload" }, { "Effect": "Allow", "Action": [ "dynamodb:CreateTable", "dynamodb:BatchGetItem", "dynamodb:BatchWriteItem", "dynamodb:PutItem", "dynamodb:DescribeTable", "dynamodb:DeleteItem", "dynamodb:GetItem", "dynamodb:Scan", "dynamodb:Query", "dynamodb:UpdateItem", "dynamodb:DeleteTable", "dynamodb:UpdateTable" ], "Resource": [ "arn:aws:dynamodb:*:123456789012:table/EmrFSMetadata" ], "Sid": "AllowDYNAMODBCreatetable" }, { "Effect": "Allow", "Action": [ "cloudwatch:PutMetricData", "dynamodb:ListTables", "s3:ListBucket" ], "Resource": [ "*" ], "Sid": "AllowCLOUDWATCHPutmetricdata" }, { "Effect": "Allow", "Action": [ "sqs:GetQueueUrl", "sqs:ReceiveMessage", "sqs:DeleteQueue", "sqs:SendMessage", "sqs:CreateQueue" ], "Resource": [ "arn:aws:sqs:*:123456789012:EMRFS-Inconsistency-*" ], "Sid": "AllowSQSGetqueueurl" } ] } ``` ------ ### Archiving log files to Amazon S3 The following policy statement allows the Amazon EMR cluster to archive log files to the Amazon S3 location specified. In the example below, when the cluster was created, *s3://MyLoggingBucket/MyEMRClusterLogs* was specified using the **Log folder S3 location** in the console, using the `--log-uri` option from the AWS CLI, or using the `LogUri` parameter in the `RunJobFlow` command. For more information, see [Archive log files to Amazon S3](emr-plan-debugging.md#emr-plan-debugging-logs-archive). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": [ "arn:aws:s3:::MyLoggingBucket/MyEMRClusterLogs/*" ], "Sid": "AllowS3Putobject" } ] } ``` ------ ### Using the AWS Glue Data Catalog The following policy statement allows actions that are required if you use the AWS Glue Data Catalog as the metastore for applications. For more information, see [Using the AWS Glue Data Catalog as the metastore for Spark SQL](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-glue.html), [Using the AWS Glue Data Catalog as the metastore for Hive](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive-metastore-glue.html), and [Using Presto with the AWS Glue Data Catalog](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-presto-glue.html) in the *Amazon EMR Release Guide*. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:CreateDatabase", "glue:UpdateDatabase", "glue:DeleteDatabase", "glue:GetDatabase", "glue:GetDatabases", "glue:CreateTable", "glue:UpdateTable", "glue:DeleteTable", "glue:GetTable", "glue:GetTables", "glue:GetTableVersions", "glue:CreatePartition", "glue:BatchCreatePartition", "glue:UpdatePartition", "glue:DeletePartition", "glue:BatchDeletePartition", "glue:GetPartition", "glue:GetPartitions", "glue:BatchGetPartition", "glue:CreateUserDefinedFunction", "glue:UpdateUserDefinedFunction", "glue:DeleteUserDefinedFunction", "glue:GetUserDefinedFunction", "glue:GetUserDefinedFunctions" ], "Resource": [ "*" ], "Sid": "AllowGLUECreatedatabase" } ] } ``` ------ # Service role for automatic scaling in Amazon EMR (Auto Scaling role) The Auto Scaling role for Amazon EMR performs a similar function as the service role, but allows additional actions for dynamically scaling environments. + The default role name is `EMR_AutoScaling_DefaultRole`. + The default managed policy attached to `EMR_AutoScaling_DefaultRole` is `AmazonElasticMapReduceforAutoScalingRole`. The contents of version 1 of `AmazonElasticMapReduceforAutoScalingRole` are shown below. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "cloudwatch:DescribeAlarms", "elasticmapreduce:ListInstanceGroups", "elasticmapreduce:ModifyInstanceGroups" ], "Effect": "Allow", "Resource": [ "*" ], "Sid": "AllowCLOUDWATCHDescribealarms" } ] } ``` ------ Your service role should use the following trust policy. **Important** The following trust policy includes the [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) and [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) global condition keys, which limit the permissions that you give Amazon EMR to particular resources in your account. Using them can protect you against [the confused deputy problem](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Resource": "arn:aws:iam::123456789012:role/ApplicationAutoScalingEMRRole", "Condition": { "StringEquals": { "aws:SourceAccount": "123456789012" }, "ArnLike": { "aws:SourceArn": "arn:aws:application-autoscaling:*:123456789012:scalable-target/*" } }, "Sid": "AllowSTSAssumerole" } ] } ``` ------ # Service role for EMR Notebooks Each EMR notebook needs permissions to access other AWS resources and perform actions. The IAM policies attached to this service role provide permissions for the notebook to interoperate with other AWS services. When you create a notebook using the AWS Management Console, you specify an *AWS service role*. You can use the default role, `EMR_Notebooks_DefaultRole`, or specify a role that you create. If a notebook has not been created before, you can choose to create the default role. + The default role name is `EMR_Notebooks_DefaultRole`. + The default managed policies attached to `EMR_Notebooks_DefaultRole` are `AmazonElasticMapReduceEditorsRole` and `S3FullAccessPolicy`. Your service role should use the following trust policy. **Important** The following trust policy includes the [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) and [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) global condition keys, which limit the permissions that you give Amazon EMR to particular resources in your account. Using them can protect you against [the confused deputy problem](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Resource": "arn:aws:iam::123456789012:role/EMRServiceRole", "Condition": { "StringEquals": { "aws:SourceAccount": "123456789012" }, "ArnLike": { "aws:SourceArn": "arn:aws:elasticmapreduce:*:123456789012:*" } }, "Sid": "AllowSTSAssumerole" } ] } ``` ------ The contents of version 1 of `AmazonElasticMapReduceEditorsRole` are as follows. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:AuthorizeSecurityGroupEgress", "ec2:AuthorizeSecurityGroupIngress", "ec2:CreateSecurityGroup", "ec2:DescribeSecurityGroups", "ec2:RevokeSecurityGroupEgress", "ec2:CreateNetworkInterface", "ec2:CreateNetworkInterfacePermission", "ec2:DeleteNetworkInterface", "ec2:DeleteNetworkInterfacePermission", "ec2:DescribeNetworkInterfaces", "ec2:ModifyNetworkInterfaceAttribute", "ec2:DescribeTags", "ec2:DescribeInstances", "ec2:DescribeSubnets", "ec2:DescribeVpcs", "elasticmapreduce:ListInstances", "elasticmapreduce:DescribeCluster", "elasticmapreduce:ListSteps" ], "Resource": [ "*" ], "Sid": "AllowEC2Authorizesecuritygroupegress" }, { "Effect": "Allow", "Action": [ "ec2:CreateTags" ], "Resource": [ "arn:aws:ec2:*:*:network-interface/*" ], "Condition": { "ForAllValues:StringEquals": { "aws:TagKeys": [ "aws:elasticmapreduce:editor-id", "aws:elasticmapreduce:job-flow-id" ] } }, "Sid": "AllowEC2Createtags" } ] } ``` ------ Following is the contents of the `S3FullAccessPolicy`. The `S3FullAccessPolicy` allows your service role for EMR Notebooks to perform all Amazon S3 actions on objects in your AWS account. When you create a custom service role for EMR Notebooks, you must give your service role Amazon S3 permissions. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:*" ], "Resource": [ "*" ], "Sid": "AllowS3" } ] } ``` ------ You can scope down read and write access for your service role to the Amazon S3 location where you want to save your notebook files. Use the following minimum set of Amazon S3 permissions. ``` "s3:PutObject", "s3:GetObject", "s3:GetEncryptionConfiguration", "s3:ListBucket", "s3:DeleteObject" ``` If your Amazon S3 bucket is encrypted, you must include the following permissions for AWS Key Management Service. ``` "kms:Decrypt", "kms:GenerateDataKey", "kms:ReEncryptFrom", "kms:ReEncryptTo", "kms:DescribeKey" ``` When you link Git repositories to your notebook and need to create a secret for the repository, you must add the `secretsmanager:GetSecretValue` permission in the IAM policy attached to the service role for Amazon EMR notebooks. An example policy is demonstrated below: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue" ], "Resource": [ "*" ] } ] } ``` ------ ## EMR Notebooks service role permissions This table lists the actions that EMR Notebooks takes using the service role, along with the permissions that are needed for each action. **** | Action | Permissions | | --- | --- | | Establish a secure network channel between a notebook and an Amazon EMR cluster, and perform necessary cleanup actions. | 
"ec2:CreateNetworkInterface", 
"ec2:CreateNetworkInterfacePermission", 
"ec2:DeleteNetworkInterface", 
"ec2:DeleteNetworkInterfacePermission", 
"ec2:DescribeNetworkInterfaces", 
"ec2:ModifyNetworkInterfaceAttribute", 
"ec2:AuthorizeSecurityGroupEgress", 
"ec2:AuthorizeSecurityGroupIngress", 
"ec2:CreateSecurityGroup",
"ec2:DescribeSecurityGroups", 
"ec2:RevokeSecurityGroupEgress",
"ec2:DescribeTags",
"ec2:DescribeInstances",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"elasticmapreduce:ListInstances", 
"elasticmapreduce:DescribeCluster", 
"elasticmapreduce:ListSteps"
| | Use Git credentials stored in AWS Secrets Manager to link Git repositories to a notebook. | 
"secretsmanager:GetSecretValue"
| | Apply AWS tags to the network interface and default security groups that EMR Notebooks creates while setting up the secure network channel. For more information, see [Tagging AWS resources](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html). | 
"ec2:CreateTags"
| | Access or upload notebook files and metadata to Amazon S3. | 
"s3:PutObject",
"s3:GetObject",
"s3:GetEncryptionConfiguration",
"s3:ListBucket",
"s3:DeleteObject"
The following permissions are only required if you use an encrypted Amazon S3 bucket. 
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:ReEncryptFrom",
"kms:ReEncryptTo",
"kms:DescribeKey"
| ## EMR Notebooks updates to AWS managed policies View details about updates to AWS managed policies for EMR Notebooks since March 1, 2021. | Change | Description | Date | | --- | --- | --- | | AmazonElasticMapReduceEditorsRole - Added permissions | EMR Notebooks added `ec2:describeVPCs` and `elastmicmapreduce:ListSteps` permissions to `AmazonElasticMapReduceEditorsRole`. | Feb 8, 2023 | | EMR Notebooks started tracking changes | EMR Notebooks started tracking changes for its AWS managed policies. | Feb 8, 2023 | # Using service-linked roles for Amazon EMR Amazon EMR uses AWS Identity and Access Management (IAM) [service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to Amazon EMR. Service-linked roles are predefined by Amazon EMR and include all the permissions that the service requires to call other AWS services on your behalf. **Topics** + [Using service-linked roles for Amazon EMR for cleanup](using-service-linked-roles-cleanup.md) + [Using service-linked roles with Amazon EMR for write-ahead logging](using-service-linked-roles-wal.md) For information about other services that support service-linked roles, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) and look for the services that have **Yes** in the **Service-linked roles** column. Choose a **Yes** with a link to view the service-linked role documentation for that service. # Using service-linked roles for Amazon EMR for cleanup Amazon EMR uses AWS Identity and Access Management (IAM) [service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to Amazon EMR. Service-linked roles are predefined by Amazon EMR and include all the permissions that the service requires to call other AWS services on your behalf. Service-linked roles work together with the Amazon EMR service role and Amazon EC2 instance profile for Amazon EMR. For more information about the service role and instance profile, see [Configure IAM service roles for Amazon EMR permissions to AWS services and resources](emr-iam-roles.md). A service-linked role makes setting up Amazon EMR easier because you don’t have to manually add the necessary permissions. Amazon EMR defines the permissions of its service-linked roles, and unless defined otherwise, only Amazon EMR can assume its roles. The defined permissions include the trust policy and the permissions policy, and that permissions policy cannot be attached to any other IAM entity. You can delete this service-linked role for Amazon EMR only after you delete any related resources and terminate all EMR clusters in the account. This protects your Amazon EMR resources so that you can't inadvertently remove permission to access the resources. ## Using service-linked roles for cleanup Amazon EMR uses the service-based **AWSServiceRoleForEMRCleanup** role to grant Amazon EMR permission to terminate and delete Amazon EC2 resources on your behalf if the Amazon EMR service-linked role loses that capability. Amazon EMR creates the service-linked role automatically during cluster creation if it doesn't already exist. The AWSServiceRoleForEMRCleanup service-linked role trusts the following services to assume the role: + `elasticmapreduce.amazonaws.com` The AWSServiceRoleForEMRCleanup service-linked role permissions policy allows Amazon EMR to complete the following actions on the specified resources: + Action: `DescribeInstances` on `ec2` + Action: `DescribeLaunchTemplates` on `ec2` + Action: `DeleteLaunchTemplate` on `ec2` + Action: `DescribeSpotInstanceRequests` on `ec2` + Action: `ModifyInstanceAttribute` on `ec2` + Action: `TerminateInstances` on `ec2` + Action: `CancelSpotInstanceRequests` on `ec2` + Action: `DeleteNetworkInterface` on `ec2` + Action: `DescribeInstanceAttribute` on `ec2` + Action: `DescribeVolumeStatus` on `ec2` + Action: `DescribeVolumes` on `ec2` + Action: `DetachVolume` on `ec2` + Action: `DeleteVolume` on `ec2` + Action: `DescribePlacementGroups` on `ec2` + Action: `DeletePlacementGroup` on `ec2` You must configure permissions to allow an IAM entity (such as a user, group, or role) to create, edit, or delete a service-linked role. ## Creating a service-linked role for Amazon EMR You don't need to manually create the AWSServiceRoleForEMRCleanup role. When you launch a cluster, either for the first time or when the AWSServiceRoleForEMRCleanup service-linked role is not present, Amazon EMR creates the AWSServiceRoleForEMRCleanup service-linked role for you. You must have permissions to create a service-linked role. For an example statement that adds this capability to the permissions policy of an IAM entity (such as a user, group, or role): Add the following statement to the permissions policy for the IAM entity that needs to create the service-linked role. ``` { "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" ] } } } ``` **Important** If you used Amazon EMR before October 24, 2017, when service-linked roles weren't supported, then Amazon EMR created the AWSServiceRoleForEMRCleanup service-linked role in your account. For more information, see [A new role appeared in my IAM account](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared). ## Editing a service-linked role for Amazon EMR Amazon EMR doesn't allow you to edit the AWSServiceRoleForEMRCleanup service-linked role. After you create a service-linked role, you can't change the name of the service-linked role because various entities might reference the service-linked role. However, you can edit the description of the service-linked role using IAM. ### Editing a service-linked role description (IAM console) You can use the IAM console to edit the description of a service-linked role. **To edit the description of a service-linked role (console)** 1. In the navigation pane of the IAM console, choose **Roles**. 1. Choose the name of the role to modify. 1. To the right of the **Role description**, choose **Edit**. 1. Enter a new description in the box and choose **Save changes**. ### Editing a service-linked role description (IAM CLI) You can use IAM commands from the AWS Command Line Interface to edit the description of a service-linked role. **To change the description of a service-linked role (CLI)** 1. (Optional) To view the current description for a role, use the following commands: ``` $ aws iam get-role --role-name role-name ``` Use the role name, not the ARN, to refer to roles with the CLI commands. For example, if a role has the following ARN: `arn:aws:iam::123456789012:role/myrole`, you refer to the role as **myrole**. 1. To update a service-linked role's description, use one of the following commands: ``` $ aws iam update-role-description --role-name role-name --description description ``` ### Editing a service-linked role description (IAM API) You can use the IAM API to edit the description of a service-linked role. **To change the description of a service-linked role (API)** 1. (Optional) To view the current description for a role, use the following command: IAM API: [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) 1. To update a role's description, use the following command: IAM API: [UpdateRoleDescription](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html) ## Deleting a service-linked role for Amazon EMR If you no longer need to use a feature or service that requires a service-linked role, we recommend that you delete that service-linked role. That way, you don't have an unused entity that is not being actively monitored or maintained. However, you must clean up your service-linked role before you can delete it. ### Cleaning up a service-linked role Before you can use IAM to delete a service-linked role, you must first confirm that the service-linked role has no active sessions and remove any resources used by the service-linked role. **To check whether the service-linked role has an active session in the IAM console** 1. Open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. In the navigation pane, choose **Roles**. Select the name (not the check box) of the AWSServiceRoleForEMRCleanup service-linked role. 1. On the **Summary** page for the selected service-linked role, choose **Access Advisor**. 1. On the **Access Advisor** tab, review the recent activity for the service-linked role. **Note** If you are unsure whether Amazon EMR is using the AWSServiceRoleForEMRCleanup service-linked role, you can try to delete the service-linked role. If the service is using the service-linked role, then the deletion fails and you can view the Regions where the service-linked role is being used. If the service-linked role is being used, then you must wait for the session to end before you can delete the service-linked role. You cannot revoke the session for a service-linked role. **To remove Amazon EMR resources used by the AWSServiceRoleForEMRCleanup** + Terminate all clusters in your account. For more information, see [Terminate an Amazon EMR cluster in the starting, running, or waiting states](UsingEMR_TerminateJobFlow.md). ### Deleting a service-linked role (IAM console) You can use the IAM console to delete a service-linked role. **To delete a service-linked role (console)** 1. Open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. In the navigation pane, choose **Roles**. Select the check box next to AWSServiceRoleForEMRCleanup, not the name or row itself. 1. For **Role actions** at the top of the page, choose **Delete role**. 1. In the confirmation dialog box, review the service last accessed data, which shows when each of the selected roles last accessed an AWS service. This helps you to confirm whether the role is currently active. To proceed, choose **Yes, Delete**. 1. Watch the IAM console notifications to monitor the progress of the service-linked role deletion. Because the IAM service-linked role deletion is asynchronous, after you submit the service-linked role for deletion, the deletion task can succeed or fail. If the task fails, you can choose **View details** or **View Resources** from the notifications to learn why the deletion failed. If the deletion fails because there are resources in the service that are being used by the role, then the reason for the failure includes a list of resources. ### Deleting a service-linked role (IAM CLI) You can use IAM commands from the AWS Command Line Interface to delete a service-linked role. Because a service-linked role cannot be deleted if it is being used or has associated resources, you must submit a deletion request. If these conditions are not met, that request can be denied. **To delete a service-linked role (CLI)** 1. To check the status of the deletion task, you must capture the `deletion-task-id` from the response. Type the following command to submit a service-linked role deletion request: ``` $ aws iam [delete-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-service-linked-role.html) --role-name AWSServiceRoleForEMRCleanup ``` 1. Type the following command to check the status of the deletion task: ``` $ aws iam [get-service-linked-role-deletion-status](https://docs.aws.amazon.com/cli/latest/reference/iam/get-service-linked-role-deletion-status.html) --deletion-task-id deletion-task-id ``` The status of the deletion task can be `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED`, or `FAILED`. If the deletion fails, the call returns the reason that it failed so that you can troubleshoot. ### Deleting a service-linked role (IAM API) You can use the IAM API to delete a service-linked role. Because a service-linked role cannot be deleted if it is being used or has associated resources, you must submit a deletion request. If these conditions are not met, that request can be denied. **To delete a service-linked role (API)** 1. To submit a deletion request for a service-linked role, call [DeleteServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceLinkedRole.html). In the request, specify the AWSServiceRoleForEMRCleanup role name. To check the status of the deletion task, you must capture the `DeletionTaskId` from the response. 1. To check the status of the deletion, call [GetServiceLinkedRoleDeletionStatus](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetServiceLinkedRoleDeletionStatus.html). In the request, specify the `DeletionTaskId`. The status of the deletion task can be `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED`, or `FAILED`. If the deletion fails, the call returns the reason that it failed so that you can troubleshoot. ## Supported Regions for AWSServiceRoleForEMRCleanup Amazon EMR supports using the AWSServiceRoleForEMRCleanup service-linked role in the following Regions. **** | Region name | Region identity | Support in Amazon EMR | | --- | --- | --- | | US East (N. Virginia) | us-east-1 | Yes | | US East (Ohio) | us-east-2 | Yes | | US West (N. California) | us-west-1 | Yes | | US West (Oregon) | us-west-2 | Yes | | Asia Pacific (Mumbai) | ap-south-1 | Yes | | Asia Pacific (Osaka) | ap-northeast-3 | Yes | | Asia Pacific (Seoul) | ap-northeast-2 | Yes | | Asia Pacific (Singapore) | ap-southeast-1 | Yes | | Asia Pacific (Sydney) | ap-southeast-2 | Yes | | Asia Pacific (Tokyo) | ap-northeast-1 | Yes | | Canada (Central) | ca-central-1 | Yes | | Europe (Frankfurt) | eu-central-1 | Yes | | Europe (Ireland) | eu-west-1 | Yes | | Europe (London) | eu-west-2 | Yes | | Europe (Paris) | eu-west-3 | Yes | | South America (São Paulo) | sa-east-1 | Yes | # Using service-linked roles with Amazon EMR for write-ahead logging Amazon EMR uses AWS Identity and Access Management (IAM) [service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to Amazon EMR. Service-linked roles are predefined by Amazon EMR and include all the permissions that the service requires to call other AWS services on your behalf. Service-linked roles work together with the Amazon EMR service role and Amazon EC2 instance profile for Amazon EMR. For more information about the service role and instance profile, see [Configure IAM service roles for Amazon EMR permissions to AWS services and resources](emr-iam-roles.md). A service-linked role makes setting up Amazon EMR easier because you don’t have to manually add the necessary permissions. Amazon EMR defines the permissions of its service-linked roles, and unless defined otherwise, only Amazon EMR can assume its roles. The defined permissions include the trust policy and the permissions policy, and that permissions policy cannot be attached to any other IAM entity. You can delete this service-linked role for Amazon EMR only after you delete their related resources and terminate all EMR clusters in the account. This protects your Amazon EMR resources so that you can't inadvertently remove permission to access the resources. ## Service-linked role permissions for write-ahead logging (WAL) Amazon EMR uses the service-linked role **AWSServiceRoleForEMRWAL** to retrieve a cluster status. The AWSServiceRoleForEMRWAL service-linked role trusts the following services to assume the role: + `emrwal.amazonaws.com` The [`EMRDescribeClusterPolicyForEMRWAL`](EMRDescribeClusterPolicyForEMRWAL.md) permissions policy for the service-linked role allows Amazon EMR to complete the following actions on the specified resources: + Action: `DescribeCluster` on `*` You must configure permissions to allow an IAM entity (in this case, Amazon EMR WAL) to create, edit, or delete a service-linked role. Add the following statements as needed to the permissions policy for your instance profile: ## CreateServiceLinkedRole **To allow an IAM entity to create the AWSServiceRoleForEMRWAL service-linked role** Add the following statement to the permissions policy for the IAM entity that needs to create the service-linked role: ``` { "Effect": "Allow", "Action": [ "iam:CreateServiceLinkedRole", "iam:PutRolePolicy" ], "Resource": "arn:aws:iam::*:role/aws-service-role/emrwal.amazonaws.com*/AWSServiceRoleForEMRWAL*", "Condition": { "StringLike": { "iam:AWSServiceName": [ "emrwal.amazonaws.com", "elasticmapreduce.amazonaws.com.rproxy.govskope.ca.cn" ] } } } ``` ## UpdateRoleDescription **To allow an IAM entity to edit the description of the AWSServiceRoleForEMRWAL service-linked role** Add the following statement to the permissions policy for the IAM entity that needs to edit the description of a service-linked role: ``` { "Effect": "Allow", "Action": [ "iam:UpdateRoleDescription" ], "Resource": "arn:aws:iam::*:role/aws-service-role/emrwal.amazonaws.com*/AWSServiceRoleForEMRWAL*", "Condition": { "StringLike": { "iam:AWSServiceName": [ "emrwal.amazonaws.com", "elasticmapreduce.amazonaws.com.rproxy.govskope.ca.cn" ] } } } ``` ## DeleteServiceLinkedRole **To allow an IAM entity to delete the AWSServiceRoleForEMRWAL service-linked role** Add the following statement to the permissions policy for the IAM entity that needs to delete a service-linked role: ``` { "Effect": "Allow", "Action": [ "iam:DeleteServiceLinkedRole", "iam:GetServiceLinkedRoleDeletionStatus" ], "Resource": "arn:aws:iam::*:role/aws-service-role/elasticmapreduce.amazonaws.com*/AWSServiceRoleForEMRCleanup*", "Condition": { "StringLike": { "iam:AWSServiceName": [ "emrwal.amazonaws.com", "elasticmapreduce.amazonaws.com.rproxy.govskope.ca.cn" ] } } } ``` ## Creating a service-linked role for Amazon EMR You don't need to manually create the AWSServiceRoleForEMRWAL role. Amazon EMR creates this service-linked role automatically when you create a WAL workspace with the EMRWAL CLI or from AWS CloudFormation, or HBase will create the service-linked role when you configure a workspace for Amazon EMR WAL and the service-linked role doesn't yet exist. You must have permissions to create a service-linked role. For example statements that add this capability to the permissions policy of an IAM entity (such as a user, group, or role), see the prior section, [Service-linked role permissions for write-ahead logging (WAL)](#using-service-linked-roles-permissions-wal). ## Editing a service-linked role for Amazon EMR Amazon EMR doesn't allow you to edit the AWSServiceRoleForEMRWAL service-linked role. After you create a service-linked role, you can't change the name of the service-linked role because various entities might reference the service-linked role. However, you can edit the description of the service-linked role using IAM. ### Editing a service-linked role description (IAM console) You can use the IAM console to edit the description of a service-linked role. **To edit the description of a service-linked role (console)** 1. In the navigation pane of the IAM console, choose **Roles**. 1. Choose the name of the role to modify. 1. To the right of the **Role description**, choose **Edit**. 1. Enter a new description in the box and choose **Save changes**. ### Editing a service-linked role description (IAM CLI) You can use IAM commands from the AWS Command Line Interface to edit the description of a service-linked role. **To change the description of a service-linked role (CLI)** 1. (Optional) To view the current description for a role, use the following commands: ``` $ aws iam get-role --role-name role-name ``` Use the role name, not the ARN, to refer to roles with the CLI commands. For example, if a role has the following ARN: `arn:aws:iam::123456789012:role/myrole`, you refer to the role as **myrole**. 1. To update a service-linked role's description, use one of the following commands: ``` $ aws iam update-role-description --role-name role-name --description description ``` ### Editing a service-linked role description (IAM API) You can use the IAM API to edit the description of a service-linked role. **To change the description of a service-linked role (API)** 1. (Optional) To view the current description for a role, use the following command: IAM API: [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) 1. To update a role's description, use the following command: IAM API: [UpdateRoleDescription](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html) ## Deleting a service-linked role for Amazon EMR If you no longer need to use a feature or service that requires a service-linked role, we recommend that you delete that service-linked role. That way, you don't have an unused entity that is not being actively monitored or maintained. However, you must clean up your service-linked role before you can delete it. **Note** The write-ahead logging operation isn't affected if you delete the AWSServiceRoleForEMRWAL role, but Amazon EMR won't auto-delete the logs that it created once your EMR cluster terminates. Therefore, you'll need to manually delete the Amazon EMR WAL logs if you delete the service-linked role. ### Cleaning up a service-linked role Before you can use IAM to delete a service-linked role, you must first confirm that the role has no active sessions and remove any resources used by the role. **To check whether the service-linked role has an active session in the IAM console** 1. Open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. In the navigation pane, choose **Roles**. Select the name (not the check box) of the AWSServiceRoleForEMRWAL role. 1. On the **Summary** page for the selected role, choose **Access Advisor**. 1. On the **Access Advisor** tab, review the recent activity for the service-linked role. **Note** If you are unsure whether Amazon EMR is using the AWSServiceRoleForEMRWAL role, you can try to delete the service-linked role. If the service is using the role, then the deletion fails and you can view the Regions where the service-linked role is being used. If the service-linked role is being used, then you must wait for the session to end before you can delete the service-linked role. You cannot revoke the session for a service-linked role. **To remove Amazon EMR resources used by the AWSServiceRoleForEMRWAL** + Terminate all clusters in your account. For more information, see [Terminate an Amazon EMR cluster in the starting, running, or waiting states](UsingEMR_TerminateJobFlow.md). ### Deleting a service-linked role (IAM console) You can use the IAM console to delete a service-linked role. **To delete a service-linked role (console)** 1. Open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. In the navigation pane, choose **Roles**. Select the check box next to AWSServiceRoleForEMRWAL, not the name or row itself. 1. For **Role actions** at the top of the page, choose **Delete role**. 1. In the confirmation dialog box, review the service last accessed data, which shows when each of the selected roles last accessed an AWS service. This helps you to confirm whether the role is currently active. To proceed, choose **Yes, Delete**. 1. Watch the IAM console notifications to monitor the progress of the service-linked role deletion. Because the IAM service-linked role deletion is asynchronous, after you submit the role for deletion, the deletion task can succeed or fail. If the task fails, you can choose **View details** or **View Resources** from the notifications to learn why the deletion failed. If the deletion fails because there are resources in the service that are being used by the role, then the reason for the failure includes a list of resources. ### Deleting a service-linked role (IAM CLI) You can use IAM commands from the AWS Command Line Interface to delete a service-linked role. Because a service-linked role cannot be deleted if it is being used or has associated resources, you must submit a deletion request. If these conditions are not met, that request can be denied. **To delete a service-linked role (CLI)** 1. To check the status of the deletion task, you must capture the `deletion-task-id` from the response. Type the following command to submit a service-linked role deletion request: ``` $ aws iam [delete-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-service-linked-role.html) --role-name AWSServiceRoleForEMRWAL ``` 1. Type the following command to check the status of the deletion task: ``` $ aws iam [get-service-linked-role-deletion-status](https://docs.aws.amazon.com/cli/latest/reference/iam/get-service-linked-role-deletion-status.html) --deletion-task-id deletion-task-id ``` The status of the deletion task can be `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED`, or `FAILED`. If the deletion fails, the call returns the reason that it failed so that you can troubleshoot. ### Deleting a service-linked role (IAM API) You can use the IAM API to delete a service-linked role. Because a service-linked role cannot be deleted if it is being used or has associated resources, you must submit a deletion request. If these conditions are not met, that request can be denied. **To delete a service-linked role (API)** 1. To submit a deletion request for a service-linked role, call [DeleteServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceLinkedRole.html). In the request, specify the AWSServiceRoleForEMRWAL role name. To check the status of the deletion task, you must capture the `DeletionTaskId` from the response. 1. To check the status of the deletion, call [GetServiceLinkedRoleDeletionStatus](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetServiceLinkedRoleDeletionStatus.html). In the request, specify the `DeletionTaskId`. The status of the deletion task can be `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED`, or `FAILED`. If the deletion fails, the call returns the reason that it failed so that you can troubleshoot. ## Supported Regions for AWSServiceRoleForEMRWAL Amazon EMR supports using the AWSServiceRoleForEMRWAL service-linked role in the following Regions. **** | Region name | Region identity | Support in Amazon EMR | | --- | --- | --- | | US East (N. Virginia) | us-east-1 | Yes | | US East (Ohio) | us-east-2 | Yes | | US West (N. California) | us-west-1 | Yes | | US West (Oregon) | us-west-2 | Yes | | Asia Pacific (Mumbai) | ap-south-1 | Yes | | Asia Pacific (Singapore) | ap-southeast-1 | Yes | | Asia Pacific (Sydney) | ap-southeast-2 | Yes | | Asia Pacific (Tokyo) | ap-northeast-1 | Yes | | Europe (Frankfurt) | eu-central-1 | Yes | | Europe (Ireland) | eu-west-1 | Yes | # Customize IAM roles with Amazon EMR You may want to customize the IAM service roles and permissions to limit privileges according to your security requirements. To customize permissions, we recommend that you create new roles and policies. Begin with the permissions in the managed policies for the default roles (for example, `AmazonElasticMapReduceforEC2Role` and `AmazonElasticMapReduceRole`). Then, copy and paste the contents to new policy statements, modify the permissions as appropriate, and attach the modified permissions policies to the roles that you create. You must have the appropriate IAM permissions to work with roles and policies. For more information, see [Allow users and groups to create and modify roles](emr-iam-roles-create-permissions.md). If you create a custom EMR role for EC2, follow the basic work flow, which automatically creates an instance profile of the same name. Amazon EC2 allows you to create instance profiles and roles with different names, but Amazon EMR does not support this configuration, and it results in an "invalid instance profile" error when you create the cluster. **Important** Inline policies are not automatically updated when service requirements change. If you create and attach inline policies, be aware that service updates might occur that suddenly cause permissions errors. For more information, see [Managed Policies and Inline Policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/policies_managed-vs-inline.html) in the *IAM User Guide* and [Specify custom IAM roles when you create a cluster](#emr-iam-roles-launch-jobflow). For more information about working with IAM roles, see the following topics in the *IAM User Guide*: + [Creating a role to delegate permissions to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) + [Modifying a role](https://docs.aws.amazon.com/IAM/latest/UserGuide/modifying-role.html) + [Deleting a role](https://docs.aws.amazon.com/IAM/latest/UserGuide/deleting-roles.html) ## Specify custom IAM roles when you create a cluster You specify the service role for Amazon EMR and the role for the Amazon EC2 instance profile when you create a cluster. The user who is creating clusters needs permissions to retrieve and assign roles to Amazon EMR and EC2 instances. Otherwise, a **account is not authorized to call EC2** error occurs. For more information, see [Allow users and groups to create and modify roles](emr-iam-roles-create-permissions.md). ### Use the console to specify custom roles When you create a cluster, you can specify a custom service role for Amazon EMR, a custom role for the EC2 instance profile, and a custom Auto Scaling role using **Advanced options**. When you use **Quick options**, the default service role and the default role for the EC2 instance profile are specified. For more information, see [IAM service roles used by Amazon EMR](emr-iam-service-roles.md). ------ #### [ Console ] **To specify custom IAM roles with the console** When you create a cluster with the console, you must specify a custom service role for Amazon EMR and a custom role for the EC2 instance profile. For more information, see [IAM service roles used by Amazon EMR](emr-iam-service-roles.md). 1. Sign in to the AWS Management Console, and open the Amazon EMR console at [https://console.aws.amazon.com/emr](https://console.aws.amazon.com/emr). 1. Under **EMR on EC2** in the left navigation pane, choose **Clusters**, and then choose **Create cluster**. 1. Under **Security configuration and permissions**, find the **IAM role for instance profile** and **Service role for Amazon EMR** fields. For each role type, select a role from the list. Only roles within your account that have the appropriate trust policy for that role type are listed. 1. Choose any other options that apply to your cluster. 1. To launch your cluster, choose **Create cluster**. ------ ### Use the AWS CLI to specify custom roles You can specify a service role for Amazon EMR and a service role for cluster EC2 instances explicitly using options with the `create-cluster` command from the AWS CLI. Use the `--service-role` option to specify the service role. Use the `InstanceProfile` argument of the `--ec2-attributes` option to specify the role for the EC2 instance profile. The Auto Scaling role is specified using a separate option, `--auto-scaling-role`. For more information, see [Using automatic scaling with a custom policy for instance groups in Amazon EMR](emr-automatic-scaling.md). **To specify custom IAM roles using the AWS CLI** + The following command specifies the custom service role, *MyCustomServiceRoleForEMR*, and a custom role for the EC2 instance profile, *MyCustomServiceRoleForClusterEC2Instances*, when launching a cluster. This example uses the default Amazon EMR role. **Note** Linux line continuation characters (\$1) are included for readability. They can be removed or used in Linux commands. For Windows, remove them or replace with a caret (^). ``` aws emr create-cluster --name "Test cluster" --release-label emr-7.12.0 \ --applications Name=Hive Name=Pig --service-role MyCustomServiceRoleForEMR \ --ec2-attributes InstanceProfile=MyCustomServiceRoleForClusterEC2Instances,\ KeyName=myKey --instance-type m5.xlarge --instance-count 3 ``` You can use these options to specify default roles explicitly rather than using the `--use-default-roles` option. The `--use-default-roles` option specifies the service role and the role for the EC2 instance profile defined in the `config` file for the AWS CLI. The following example demonstrates the contents of a `config` file for the AWS CLI the specifies custom roles for Amazon EMR. With this configuration file, when the `--use-default-roles` option is specified, the cluster is created using the *MyCustomServiceRoleForEMR* and *MyCustomServiceRoleForClusterEC2Instances*. By default, the `config` file specifies the default `service_role` as `AmazonElasticMapReduceRole` and the default `instance_profile` as `EMR_EC2_DefaultRole`. ``` [default] output = json region = us-west-1 aws_access_key_id = myAccessKeyID aws_secret_access_key = mySecretAccessKey emr = service_role = MyCustomServiceRoleForEMR instance_profile = MyCustomServiceRoleForClusterEC2Instances ``` # Configure IAM roles for EMRFS requests to Amazon S3 **Note** The EMRFS role mapping capability described on this page has been improved upon with the introduction of Amazon S3 Access Grants in Amazon EMR 6.15.0. For a scalable access control solution for your data in Amazon S3, we recommend that you use [S3 Access Grants with Amazon EMR](emr-access-grants.md). When an application running on a cluster references data using the `s3://mydata` format, Amazon EMR uses EMRFS to make the request. To interact with Amazon S3, EMRFS assumes the permissions policies that are attached to your [Amazon EC2 instance profile](emr-iam-role-for-ec2.md). The same Amazon EC2 instance profile is used regardless of the user or group running the application or the location of the data in Amazon S3. If you have a cluster with multiple users who need different levels of access to data in Amazon S3 through EMRFS, you can set up a security configuration with IAM roles for EMRFS. EMRFS can assume a different service role for cluster EC2 instances based on the user or group making the request, or based on the location of data in Amazon S3. Each IAM role for EMRFS can have different permissions for data access in Amazon S3. For more information about the service role for cluster EC2 instances, see [Service role for cluster EC2 instances (EC2 instance profile)](emr-iam-role-for-ec2.md). Using custom IAM roles for EMRFS is supported in Amazon EMR versions 5.10.0 and later. If you use an earlier version or have requirements beyond what IAM roles for EMRFS provide, you can create a custom credentials provider instead. For more information, see [Authorizing access to EMRFS data in Amazon S3](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-plan-credentialsprovider). When you use a security configuration to specify IAM roles for EMRFS, you set up role mappings. Each role mapping specifies an IAM role that corresponds to identifiers. These identifiers determine the basis for access to Amazon S3 through EMRFS. The identifiers can be users, groups, or Amazon S3 prefixes that indicate a data location. When EMRFS makes a request to Amazon S3, if the request matches the basis for access, EMRFS has cluster EC2 instances assume the corresponding IAM role for the request. The IAM permissions attached to that role apply instead of the IAM permissions attached to the service role for cluster EC2 instances. The users and groups in a role mapping are Hadoop users and groups that are defined on the cluster. Users and groups are passed to EMRFS in the context of the application using it (for example, YARN user impersonation). The Amazon S3 prefix can be a bucket specifier of any depth (for example, `s3://amzn-s3-demo-bucket` or `s3://amzn-s3-demo-bucket/myproject/mydata`). You can specify multiple identifiers within a single role mapping, but they all must be of the same type. **Important** IAM roles for EMRFS provide application-level isolation between users of the application. It does not provide host level isolation between users on the host. Any user with access to the cluster can bypass the isolation to assume any of the roles. When a cluster application makes a request to Amazon S3 through EMRFS, EMRFS evaluates role mappings in the top-down order that they appear in the security configuration. If a request made through EMRFS doesn't match any identifier, EMRFS falls back to using the service role for cluster EC2 instances. For this reason, we recommend that the policies attached to this role limit permissions to Amazon S3. For more information, see [Service role for cluster EC2 instances (EC2 instance profile)](emr-iam-role-for-ec2.md). ## Configure roles Before you set up a security configuration with IAM roles for EMRFS, plan and create the roles and permission policies to attach to the roles. For more information, see [How do roles for EC2 instances work?](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) in the *IAM User Guide*. When creating permissions policies, we recommend that you start with the managed policy attached to the default Amazon EMR role for EC2, and then edit this policy according to your requirements. The default role name is `EMR_EC2_DefaultRole`, and the default managed policy to edit is `AmazonElasticMapReduceforEC2Role`. For more information, see [Service role for cluster EC2 instances (EC2 instance profile)](emr-iam-role-for-ec2.md). ### Updating trust policies to assume role permissions Each role that EMRFS uses must have a trust policy that allows the cluster's Amazon EMR role for EC2 to assume it. Similarly, the cluster's Amazon EMR role for EC2 must have a trust policy that allows EMRFS roles to assume it. The following example trust policy is attached to roles for EMRFS. The statement allows the default Amazon EMR role for EC2 to assume the role. For example, if you have two fictitious EMRFS roles, `EMRFSRole_First` and `EMRFSRole_Second`, this policy statement is added to the trust policies for each of them. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Resource": "arn:aws:iam::123456789012:role/EMR_EC2_DefaultRole", "Sid": "AllowSTSAssumerole" } ] } ``` ------ In addition, the following example trust policy statement is added to the `EMR_EC2_DefaultRole` to allow the two fictitious EMRFS roles to assume it. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Resource": [ "arn:aws:iam::123456789012:role/EMRFSRole_First", "arn:aws:iam::123456789012:role/EMRFSRole_Second" ], "Sid": "AllowSTSAssumerole" } ] } ``` ------ **To update the trust policy of an IAM role** Open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. Choose **Roles**, enter the name of the role in **Search**, and then select its **Role name**. 1. Choose **Trust relationships**, **Edit trust relationship**. 1. Add a trust statement according to the **Policy document** according to the guidelines above, and then choose **Update trust policy**. ### Specifying a role as a key user If a role allows access to a location in Amazon S3 that is encrypted using an AWS KMS key, make sure that the role is specified as a key user. This gives the role permission to use the KMS key. For more information, see [Key policies in AWS KMS](https://docs.aws.amazon.com//kms/latest/developerguide/key-policies.html#key-policy-default-allow-users) in the *AWS Key Management Service Developer Guide*. ## Set up a security configuration with IAM roles for EMRFS **Important** If none of the IAM roles for EMRFS that you specify apply, EMRFS falls back to the Amazon EMR role for EC2. Consider customizing this role to restrict permissions to Amazon S3 as appropriate for your application and then specifying this custom role instead of `EMR_EC2_DefaultRole` when you create a cluster. For more information, see [Customize IAM roles with Amazon EMR](emr-iam-roles-custom.md) and [Specify custom IAM roles when you create a cluster](emr-iam-roles-custom.md#emr-iam-roles-launch-jobflow). **To specify IAM roles for EMRFS requests to Amazon S3 using the console** 1. Create a security configuration that specifies role mappings: 1. In the Amazon EMR console, select **Security configurations**, **Create**. 1. Type a **Name** for the security configuration. You use this name to specify the security configuration when you create a cluster. 1. Choose **Use IAM roles for EMRFS requests to Amazon S3**. 1. Select an **IAM role** to apply, and under **Basis for access** select an identifier type (**Users**, **Groups**, or **S3 prefixes**) from the list and enter corresponding identifiers. If you use multiple identifiers, separate them with a comma and no space. For more information about each identifier type, see the [JSON configuration reference](#emrfs-seccfg-json) below. 1. Choose **Add role** to set up additional role mappings as described in the previous step. 1. Set up other security configuration options as appropriate and choose **Create**. For more information, see [Create a security configuration with the Amazon EMR console or with the AWS CLI](emr-create-security-configuration.md). 1. Specify the security configuration you created above when you create a cluster. For more information, see [Specify a security configuration for an Amazon EMR cluster](emr-specify-security-configuration.md). **To specify IAM roles for EMRFS requests to Amazon S3 using the AWS CLI** 1. Use the `aws emr create-security-configuration` command, specifying a name for the security configuration, and the security configuration details in JSON format. The example command shown below creates a security configuration with the name `EMRFS_Roles_Security_Configuration`. It is based on a JSON structure in the file `MyEmrfsSecConfig.json`, which is saved in the same directory where the command is executed. ``` aws emr create-security-configuration --name EMRFS_Roles_Security_Configuration --security-configuration file://MyEmrFsSecConfig.json. ``` Use the following guidelines for the structure of the `MyEmrFsSecConfig.json` file. You can specify this structure along with structures for other security configuration options. For more information, see [Create a security configuration with the Amazon EMR console or with the AWS CLI](emr-create-security-configuration.md). The following is an example JSON snippet for specifying custom IAM roles for EMRFS within a security configuration. It demonstrates role mappings for the three different identifier types, followed by a parameter reference. ``` { "AuthorizationConfiguration": { "EmrFsConfiguration": { "RoleMappings": [{ "Role": "arn:aws:iam::123456789101:role/allow_EMRFS_access_for_user1", "IdentifierType": "User", "Identifiers": [ "user1" ] },{ "Role": "arn:aws:iam::123456789101:role/allow_EMRFS_access_to_demo_s3_buckets", "IdentifierType": "Prefix", "Identifiers": [ "s3://amzn-s3-demo-bucket1/","s3://amzn-s3-demo-bucket2/" ] },{ "Role": "arn:aws:iam::123456789101:role/allow_EMRFS_access_for_AdminGroup", "IdentifierType": "Group", "Identifiers": [ "AdminGroup" ] }] } } } ``` [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-emrfs-iam-roles.html) 1. Use the `aws emr create-cluster` command to create a cluster and specify the security configuration you created in the previous step. The following example creates a cluster with default core Hadoop applications installed. The cluster uses the security configuration created above as `EMRFS_Roles_Security_Configuration` and also uses a custom Amazon EMR role for EC2, `EC2_Role_EMR_Restrict_S3`, which is specified using the `InstanceProfile` argument of the `--ec2-attributes` parameter. **Note** Linux line continuation characters (\$1) are included for readability. They can be removed or used in Linux commands. For Windows, remove them or replace with a caret (^). ``` aws emr create-cluster --name MyEmrFsS3RolesCluster \ --release-label emr-7.12.0 --ec2-attributes InstanceProfile=EC2_Role_EMR_Restrict_S3,KeyName=MyKey \ --instance-type m5.xlarge --instance-count 3 \ --security-configuration EMRFS_Roles_Security_Configuration ``` # Use resource-based policies for Amazon EMR access to AWS Glue Data Catalog If you use AWS Glue in conjunction with Hive, Spark, or Presto in Amazon EMR, AWS Glue supports resource-based policies to control access to Data Catalog resources. These resources include databases, tables, connections, and user-defined functions. For more information, see [AWS Glue Resource Policies](https://docs.aws.amazon.com/glue/latest/dg/glue-resource-policies.html) in the *AWS Glue Developer Guide*. When using resource-based policies to limit access to AWS Glue from within Amazon EMR, the principal that you specify in the permissions policy must be the role ARN associated with the EC2 instance profile that is specified when a cluster is created. For example, for a resource-based policy attached to a catalog, you can specify the role ARN for the default service role for cluster EC2 instances, *EMR\$1EC2\$1DefaultRole* as the `Principal`, using the format shown in the following example: ``` arn:aws:iam::acct-id:role/EMR_EC2_DefaultRole ``` The *acct-id* can be different from the AWS Glue account ID. This enables access from EMR clusters in different accounts. You can specify multiple principals, each from a different account. # Use IAM roles with applications that call AWS services directly Applications running on the EC2 instances of a cluster can use the EC2 instance profile to obtain temporary security credentials when calling AWS services. The versions of Hadoop available with Amazon EMR release 2.3.0 and later have already been updated to make use of IAM roles. If your application runs strictly on top of the Hadoop architecture, and does not directly call any service in AWS, it should work with IAM roles with no modification. If your application calls services in AWS directly, you need to update it to take advantage of IAM roles. This means that instead of obtaining account credentials from `/etc/hadoop/conf/core-site.xml` on the EC2 instances in the cluster, your application uses an SDK to access the resources using IAM roles, or calls the EC2 instance metadata to obtain the temporary credentials. **To access AWS resources with IAM roles using an SDK** + The following topics show how to use several of the AWS SDKs to access temporary credentials using IAM roles. Each topic starts with a version of an application that does not use IAM roles and then walks you through the process of converting that application to use IAM roles. + [Using IAM roles for Amazon EC2 instances with the SDK for Java](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/java-dg-roles.html) in the *AWS SDK for Java Developer Guide* + [Using IAM roles for Amazon EC2 instances with the SDK for .NET](https://docs.aws.amazon.com/sdk-for-net/v4/developer-guide/net-dg-hosm.html) in the *AWS SDK for .NET Developer Guide* + [Using IAM roles for Amazon EC2 instances with the SDK for PHP](https://docs.aws.amazon.com/sdk-for-php/v3/developer-guide/guide_credentials_assume_role.html) in the *AWS SDK for PHP Developer Guide* + [Using IAM roles for Amazon EC2 instances with the SDK for Ruby](https://docs.aws.amazon.com/sdk-for-ruby/v3/developer-guide/credential-providers.html) in the *AWS SDK for Ruby Developer Guide* **To obtain temporary credentials from EC2 instance metadata** + Call the following URL from an EC2 instance that is running with the specified IAM role, which returns the associated temporary security credentials (AccessKeyId, SecretAccessKey, SessionToken, and Expiration). The following example uses the default instance profile for Amazon EMR, `EMR_EC2_DefaultRole`. ``` GET http://169.254.169.254/latest/meta-data/iam/security-credentials/EMR_EC2_DefaultRole ``` For more information about writing applications that use IAM roles, see [Granting applications that run on Amazon EC2 instances access to AWS resources](https://docs.aws.amazon.com/IAM/latest/UserGuide/role-usecase-ec2app.html). For more information about temporary security credentials, see [Using temporary security credentials](https://docs.aws.amazon.com/STS/latest/UsingSTS/using-temp-creds.html) in the *Using Temporary Security Credentials* guide. # Allow users and groups to create and modify roles IAM principals (users and groups) who create, modify, and specify roles for a cluster, including default roles, must be allowed to perform the following actions. For details about each action, see [Actions](https://docs.aws.amazon.com/IAM/latest/APIReference/API_Operations.html) in the *IAM API Reference*. + `iam:CreateRole` + `iam:PutRolePolicy` + `iam:CreateInstanceProfile` + `iam:AddRoleToInstanceProfile` + `iam:ListRoles` + `iam:GetPolicy` + `iam:GetInstanceProfile` + `iam:GetPolicyVersion` + `iam:AttachRolePolicy` + `iam:PassRole` The `iam:PassRole` permission allows cluster creation. The remaining permissions allow the creation of the default roles. For information about assigning permissions to a user, see [Changing permissions for a user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html) in the *IAM User Guide*. # 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*.