-
Notifications
You must be signed in to change notification settings - Fork 423
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IAM roles with paths are only recognized without the path #153
Comments
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?) |
Yes. Roles are always assumed now that I think about it. |
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 Given that roles are unique based on their name only, it would be safe to drop the path in the role ARN in |
Still seeing the appearance off this issue. in configMap having to drop path: 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. |
@jalvarezferr Yes, that is the issue. Just cut out the path from the |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Rotten issues close after 30d of inactivity. Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
@fejta-bot: Closing this issue. In response to this:
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:
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 |
@nckturner: Reopened this issue. In response to this:
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. Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
@fejta-bot: Closing this issue. In response to this:
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 |
@joanayma: You can't reopen an issue/PR unless you authored it or you are a collaborator. In response to this:
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 |
`aws-iam-authenticator` has an open issue where it will not recognize IAM roles that include paths. This change causes the path supplied to `var.iam_path` to be stripped when generating the `aws-auth` ConfigMap in order to work around this. kubernetes-sigs/aws-iam-authenticator#153
* fix: Work around path bug in aws-iam-authenticator `aws-iam-authenticator` has an open issue where it will not recognize IAM roles that include paths. This change causes the path supplied to `var.iam_path` to be stripped when generating the `aws-auth` ConfigMap in order to work around this. kubernetes-sigs/aws-iam-authenticator#153 aws/containers-roadmap#926
* fix: Work around path bug in aws-iam-authenticator `aws-iam-authenticator` has an open issue where it will not recognize IAM roles that include paths. This change causes the path supplied to `var.iam_path` to be stripped when generating the `aws-auth` ConfigMap in order to work around this. kubernetes-sigs/aws-iam-authenticator#153 aws/containers-roadmap#926
If people want to highlight this issue to the vendor, AWS, then please visit aws/containers-roadmap#573 and add a thumbs-up reaction. |
Seems that it's kind of fixed upstream here: aws/containers-roadmap#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). |
Assuming I have the following role ARN:
If I enter this under
mapRoles
, this will not be recognized. Instead I need to enter:The text was updated successfully, but these errors were encountered: