-
Notifications
You must be signed in to change notification settings - Fork 419
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
Is it possible to use with AssumeRoleWithWebIdentity? #154
Comments
This is currently not supported. I don't see any problem with adding support for it though. Let's discuss implementation and user experience here. As a work around you can remove the -r option from the kubeconfig, use the CLI to get credentials with /kind feature |
There is a new credential provider being added to the SDKs to support AssumeRoleWithWebIdentity that should land later this year. Once that is ready, it should just be a matter of updating the Go SDK for this repo to support this: See aws/aws-sdk-go#2193 Getting an token from your OIDC provider in the first place will require some extra code though. |
@micahhausler good news, thanks. I already have some code to obtain an identity token from the auth provider but I'm struggling to find a sensible way of hooking it all up with the aws cli (ro run aws sts) and then to pass that session token to the aws-iam-authenticator. |
I'd love a solution for this too. We can't use dex with AWS EKS, so this path would be the next best thing. @micahhausler @xibz will that aws/aws-sdk-go#2193 patch land soon? That seems the cleanest way forward. |
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. |
aws/aws-sdk-go#2193 looks like it might be landing soon. The simplest thing we can do is just update the SDK, then the user would need to ensure a token is placed in the location specified by |
@cromega if aws/containers-roadmap#166 lands we'll be able to use OIDC directly without having to jump through all the IAM hoops. Plus you can get back to the more fine-grained security of user:user mapping, rather than all federated users being glommed onto one cluster username as happens now. Should eliminate one of the current big drawbacks of using EKS. 🎉 |
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. |
/lifecycle rotten Still waiting for an OIDC or Web Identity authentication option. |
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. |
It's not an issue per se because I'm not even sure what I'm trying to do is possible.
I installed an EKS cluster but a requirement is setting up federated login with G-suite. I created a Role for federated access via the Google identity provider:
The aws-auth-cm.yml applied on the cluster looks like this:
and my kubeconfig is as follows:
If I execute aws-iam-authenticator directly with the same parameters I get
I'm not quite sure what I'm trying to do makes sense but let me explain what I expect the user experience to look like:
Is it possible to set up authentication like this? If not then I don't really understand how the authenticator is supposed to get a token through normal AssumeRole.
Please help!
The text was updated successfully, but these errors were encountered: