User is not authorized to perform: iam:PassRole on resource

Question

I'm attempting to create an eks cluster through the aws cli with the following commands:

aws eks create-cluster --name ekCsluster --role-arn arn:aws:iam::111111111111:role/eksServiceRole --resources-vpc-config subnetIds=subnet-1,subnet-2,subnet-3,subnet-4,subnet-5,subnet-6,securityGroupIds=sg-1

And get the following error:

An error occurred (AccessDeniedException) when calling the CreateCluster operation: User: arn:aws:iam::111111111111:user/userName is not authorized to perform: iam:PassRole on resource: arn:aws:iam::111111111111:role/eksServiceRole

However, I've created a permission policy, AssumeEksServiceRole and attached it directly to the user, arn:aws:iam::111111111111:user/userName:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "iam:GetRole",
                "iam:PassRole"
            ],
            "Resource": "arn:aws:iam::111111111111:role/eksServiceRole"
        }
    ]
}

In the eksServiceRole role, I've defined the trust relationship as follows:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "eks.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    },
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:user/userName"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

What am I missing? How can I go about debugging this error message? Thanks for any and all help.

In the ARNs you've got 000000... and 111111... - does that mean the user and the role are in *different AWS accounts*? That could probably cause quite a few issues. Can you try with a *user* in the same account as the *role*? — MLu, Jan 08 '19 at 21:49
No, they're all the same account. I've updated the question to reflect that. — Kurt Mueller, Jan 09 '19 at 14:59

score 0 · Answer 1 · answered Feb 02 '19 at 17:10

I would try removing the user from the trust relationship (which is unnecessary anyways). AWS services don't play well when having a mix of accounts and service as principals in the trust relationship, for example, if you try to do that with CodeBuild it will complain saying it doesn't own the the principal.

score 0 · Answer 2 · answered Aug 30 '19 at 14:19

In your case, you can just use:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "iam:GetRole",
                "iam:PassRole"
            ],
            "Resource": "arn:aws:iam::111111111111:role/eksServiceRole"
        }
    ]
}

I use this:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "CustomEditor",
            "Effect": "Allow",
            "Action": [
                "iam:GetRole",
                "iam:PassRole"
            ],
            "Resource": "*"
        }
    ]
}

Your entry in the eksServiceRole role is not necessary.

User is not authorized to perform: iam:PassRole on resource

2 Answers2