Error matching iam role when role uses a path

[scyellleader]

I'm having a problem getting the iam roles to match when the assumed role contains a path.

kubeconfig settings:
apiVersion: v1
clusters:
- cluster:
    server: <endpoint>
    certificate-authority-data: <cert>
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: aws
  name: aws
current-context: aws
kind: Config
preferences: {}
users:
- name: aws
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      command: heptio-authenticator-aws
      args:
        - "token"
        - "-i"
        - "eks-cluster"
        - "auth-test"
        - "-r"
        - "arn:aws:iam::000000000000:role/roles/SomeRole"

Non Working ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::000000000000:role/worker-node
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes
    - rolearn: arn:aws:iam::000000000000:role/roles/SomeRole
      username: admin:{{SessionName}}
      groups:
        - system:masters

Working ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::000000000000:role/worker-node
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes
    - rolearn: arn:aws:iam::000000000000:role/SomeRole
      username: admin:{{SessionName}}
      groups:
        - system:masters

As you can see from the non-working and working comparison I have to trim out the iam path to get the authentication to work. (arn:aws:iam::000000000000:role/roles/SomeRole vs arn:aws:iam::000000000000:role/SomeRole) Technically on AWS side the arn with the trimmed path is not the same role.

[christopherhein]

Thanks @scyellleader. Under the hood this is how the ARNs work the roles/ is considered a friendly name or prefix - https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-friendly-names

We don't have specificity on the STS side to validate a specific prefix cause they can be anything.

[mattlandis]

This looks like a bug with role arns involving paths when mapping the assumed-role -> role. The code is only taking the first part after assumed-role. This should probably by strings.Join(parts[1:len(parts)-1], "/"). parts[0] is 'assumed-role' and parts[len(parts)-1] is the Session if memory serves me correctly.

https://github.com/heptio/authenticator/blob/master/pkg/arn/arn.go#L42

[scyellleader]

@mattlandis yes, that looks correct to me. You just need to drop the first and last index for the parts array to be left with the full path and role. That should also cover if the path has multiple slashes. Thanks for finding the bug!

[MarkPare]

This cost me about a day's worth of work when trying to configure Codebuild to run commands on an EKS cluster. To allow a role to access a kubernetes cluster on EKS, you need to pass a rolearn to a config map in cluster. As this thread points out, when you assume a role (as you need to do in Codebuild when running commands on an eks cluster) that has a path, aws under the hood will actually omit the path portion of the role arn. This causes the string value of rolearn in the k8s config map to differ from the one that Codebuild is using, resulting in failure to authenticate.

I'm sure there's some history to why this is the case, but to my mind this is an unacceptable bug and, if nothing else, deserves to be documented very clearly in multiple places, especially in IAM docs.

[ch3lo]

I agree with @MarkPare , I had inverted 2 days deploying a EKS cluster in Landing Zone without success and the problem was my instances roles had a path in the ARN. In my comnpany this is a requirement because we group our IAM Roles in path for security reasons.

Regards

[michael-burt]

I wasted about a week on this bug.

[rafaelmagu]

Aaaaand I just found this out. Good 48 hours spent on this. 🤦‍♂

Is the correct approach here to put the roles in the aws-auth ConfigMap object without their paths?

[michael-burt]

Aaaaand I just found this out. Good 48 hours spent on this. 🤦‍♂

Is the correct approach here to put the roles in the aws-auth ConfigMap object without their paths?

Yes, you can just remove the path in the ConfigMap and it will all work as expected.

[amitsehgal]

I wasted few hours when moved a cluster from non path to path based role. stumbled upon this thread....Thanks

[naseem-opal]

Sam here. Just lost 6 hours to this inconsistency :(

[billinghamj]

This is definitely not resolved yet. See #333, #268, #153