search

kubernetes-sigs / aws-iam-authenticator

A tool to use AWS IAM credentials to authenticate to a Kubernetes cluster
Apache License 2.0
2.19k stars 418 forks source link

IAM roles with paths are only recognized without the path #153

Open alfredkrohmer opened 5 years ago

alfredkrohmer commented 5 years ago

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 commented 5 years ago

@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

alfredkrohmer commented 5 years ago

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 commented 5 years ago

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

nckturner commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

jpb commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

fejta-bot commented 5 years ago

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 commented 5 years ago

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

fejta-bot commented 5 years ago

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

k8s-ci-robot commented 5 years ago

@fejta-bot: Closing this issue.

In response to [this](https://github.com/kubernetes-sigs/aws-iam-authenticator/issues/153#issuecomment-513592323): >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](https://github.com/fejta). >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
zettatronn commented 4 years ago

/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.

k8s-ci-robot commented 4 years ago

@zettatronn: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to [this](https://github.com/kubernetes-sigs/aws-iam-authenticator/issues/153#issuecomment-563376372): >/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](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
nckturner commented 4 years ago

/reopen

k8s-ci-robot commented 4 years ago

@nckturner: Reopened this issue.

In response to [this](https://github.com/kubernetes-sigs/aws-iam-authenticator/issues/153#issuecomment-565131078): >/reopen Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
fejta-bot commented 4 years ago

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

k8s-ci-robot commented 4 years ago

@fejta-bot: Closing this issue.

In response to [this](https://github.com/kubernetes-sigs/aws-iam-authenticator/issues/153#issuecomment-573347156): >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](https://github.com/fejta). >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
joanayma commented 4 years ago

/reopen

k8s-ci-robot commented 4 years ago

@joanayma: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to [this](https://github.com/kubernetes-sigs/aws-iam-authenticator/issues/153#issuecomment-610879151): >/reopen Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
nckturner commented 4 years ago

/reopen /lifecycle frozen

billinghamj commented 3 years ago

Between #333, #268, #153 and #98 - would be good to get duplicates closed and it tracked in one place

sftim commented 1 year ago

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.

gothrek22 commented 8 months ago

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).