IAM roles with paths are only recognized without the path

[alfredkrohmer]

Assuming I have the following role ARN:

arn:aws:iam::1234567890:role/iam-ss/some-path/actual-role-name

If I enter this under mapRoles, this will not be recognized. Instead I need to enter:

arn:aws:iam::1234567890:role/actual-role-name

[davekonopka]

@devkid Are you using an assumed role? It looks like this PR might be related to what you're seeing: #144

[alfredkrohmer]

The role is used by an EC2 instance with an IAM instance profile. Not sure if this counts as "assumed"? (Does EC2 "assume" the role on behalf of the instance to provide the credentials?)

[davekonopka]

Yes. Roles are always assumed now that I think about it.

[nckturner]

Yeah, this is definitely confusing UX with the current implementation. Some possible ways forward are 1. to allow paths to be included, in which case we would want to validate them (they are not returned in the STS assume role response because they are not included assumed role ARNs), 2. to force the path to be included in the ARN (again needing the validation step), or 3. to consider allowing or requiring the Principle ID to be used in mappings instead of ARNs.

[timvanderkooi]

Any update here? I'd like to be able to use Terraform to resolve the ARN and place it into my auth map, but with this implementation I have to manually specify that modified ARN as a variable.

[fernandogoncalves-me]

@timvanderkooi, good news! Apparently this was solved by #103 and it's already part of the pre-release v0.4.0-alpha.1.

[jpb]

I ran into this, and the fix in #103 isn't sufficient to resolve the issue because role paths are not included in assumed-role ARNs. I created #144 which implements @nckturner's option (1.) or (2.) (not sure which one based on the description above), but it is currently stalled right now.

Given that roles are unique based on their name only, it would be safe to drop the path in the role ARN in mapRoles as a temporary workaround.

[BeardedCloudWalker]

Still seeing the appearance off this issue. in configMap having to drop path:
- rolearn: arn:aws:iam::1234567890:role/prod-path/eks-role
in automation needs to be parsed down to
- rolearn: arn:aws:iam::12334567890:role/eks-role

Following EKS Setup documentation, this can initially manifest in Nodes not being able to join the cluster after the instance role is passed to the auth config step.

[jalvarezferr]

Using AWS EKS with a worker role having an IAM path other than / causes worker to fail to join the cluster.
/var/log/messages shows streams of Unauthorized errors.
Is this related to this same issue?

[alfredkrohmer]

@jalvarezferr Yes, that is the issue. Just cut out the path from the aws-auth, it should work then.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten