Using job execution roles with Amazon EMR on EKS

To use the StartJobRun command to submit a job run on an EKS cluster, you must first onboard a job execution role to be used with a virtual cluster. For more information, see Create a job execution role in Setting up steps.

The following permissions must be included in the trust policy for the job execution role.

  {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::AWS_ACCOUNT_ID:oidc-provider/OIDC_PROVIDER"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringLike": {
          "OIDC_PROVIDER:sub": "system:serviceaccount:NAMESPACE:emr-containers-sa-*-*-AWS_ACCOUNT_ID-BASE36_ENCODED_ROLE_NAME"
        }
      }
    }
  ]
}
 

The trust policy in the preceding example grants permissions only to an EMR managed Kubernetes service account with a name that matches the emr-containers-sa-*-*-AWS_ACCOUNT_ID-BASE36_ENCODED_ROLE_NAME pattern. Service accounts with this pattern will be automatically created at job submission, scoped to the namespace where the job is submitted. This trust policy allows these service accounts to assume the execution role and get the temporary credentials of the execution role. Any other service account from a different EKS cluster or from a different namespace within the same EKS cluster can not assume the execution role.

You can run the following command to update the trust policy automatically in the format given above.

aws emr-containers update-role-trust-policy \
       --cluster-name cluster \
       --namespace namespace \
       --role-name iam_role_name_for_job_execution

Controlling access to the execution role

An EKS cluster administrator can create a multi-tenant Amazon EMR on EKS virtual cluster to which an IAM administrator can add multiple execution roles. These execution roles can be used to submit jobs by untrusted tenants running arbitrary code. Therefore, you may want to restrict those tenants so that they cannot run code that gains the permissions assigned to one or more of these execution roles. You can use condition keys to restrict access to execution roles. The IAM administrator can restrict the IAM policy attached to an IAM identity by using an optional string condition key named emr-containers:ExecutionRoleArn. This condition accepts a list of execution role ARNs that have permissions to use a virtual cluster, as the following permissions policy demonstrates.

  {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "emr-containers:StartJobRun",
      "Resource": "arn:aws:emr-containers:REGION:AWS_ACCOUNT_ID:/virtualclusters/VIRTUAL_CLUSTER_ID",
      "Condition": {
        "StringEquals": {
          "emr-containers:ExecutionRoleArn": [
            "execution_role_arn_1",
            "execution_role_arn_2",
            ...
          ]
        }
      }
    }
  ]
}
 

If you want to allow all execution roles that begin with a particular prefix, such as MyRole, the condition operator StringEquals can be replaced with a StringLike operator, and execution_role_arn value in the condition can be replaced with a wildcard * character. For example, arn:aws:iam::AWS_ACCOUNT_ID:role/MyRole*. All other string condition keys are also supported.

Note

Amazon EMR on EKS currently does not support tag-based access control (TBAC) for execution roles. You cannot grant permissions to the execution roles based on tags.