aws-iam-authenticator
aws-iam-authenticator copied to clipboard
kubernetes-sigs
IAM roles with paths are only recognized without the path
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
@devkid Are you using an assumed role? It looks like this PR might be related to what you're seeing: https://github.com/kubernetes-sigs/aws-iam-authenticator/pull/144
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?)
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.
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.
@timvanderkooi, good news! Apparently this was solved by #103 and it's already part of the pre-release v0.4.0-alpha.1.
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.
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.
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?
@jalvarezferr Yes, that is the issue. Just cut out the path from the aws-auth, it should work then.
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
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
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /close
@fejta-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity. Reopen the issue with
/reopen. Mark the issue as fresh with/remove-lifecycle rotten.Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
/reopen
This ticket was closed due to inactivity but this bug is still present. We currently have to use 2 ARNs in all configmaps to work around this issue.
@zettatronn: You can't reopen an issue/PR unless you authored it or you are a collaborator.
In response to this:
/reopen
This ticket was closed due to inactivity but this bug is still present. We currently have to use 2 ARNs in all configmaps to work around this issue.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
@nckturner: Reopened this issue.
In response to this:
/reopen
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /close
@fejta-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity. Reopen the issue with
/reopen. Mark the issue as fresh with/remove-lifecycle rotten.Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
@joanayma: You can't reopen an issue/PR unless you authored it or you are a collaborator.
In response to this:
/reopen
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
Between #333, #268, #153 and #98 - would be good to get duplicates closed and it tracked in one place
If people want to highlight this issue to the vendor, AWS, then please visit https://github.com/aws/containers-roadmap/issues/573 and add a thumbs-up reaction.
Seems that it's kind of fixed upstream here: https://github.com/aws/containers-roadmap/issues/185
They now not only support an API to manage cluster access, but also switch to AWS iam principal id, instead of ARN (which is relevant to this ticket).
