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 for service accounts vs kube2iam #368
Comments
I'm using EKS on AWS and ~ 1 and half years ago i've successfully migrated from kube2iam to IRSA. |
Firstly, thank you very much for the work on kube2iam, we have been using it in EKS for a while now in production. We started looking at IAM roles for service accounts recently because of the lack of support for IMDSv2 (now fixed, thanks to you and to the author of that PR for that), and also because until recently, this project appeared to have stopped being actively supported (understandably so). But IAM roles for service accounts provided by AWS has been anything but smooth for us in adoption.
The first option is basically discouraged (blocked) by our corporate account governance due to security concerns, so we are left with option 2. With option 2, it seems like AWS has provided a half-baked solution - they provide an admission controller that injects env vars needed to make role assumption work for a container running in EKS. However, this does not suffice for cross account role assumption, which uses IAM role chaining. For role chaining to work, the running container has to know both the local role and the "chained" remote account role arns. So for us as a platform team, we would need to have every single tenant update their deployments to inject these values into their deployments.. OR for us to create some tooling (like a controller) to inject these automatically. So this makes staying with kube2iam a much more preferred option :) as long as it supports our current infrastructure. We would not mind PRing support for ipv6 to the project, if that is something you would consider. |
We still use kube2iam because IAM roles for service accounts require exposure of unauthenticated public json oauth provider data in an S3 bucket or a server, and our organization policies prohibit such things, meaning the entire integration AWS has set out isn't accessible to us. Very similar to @mindgrep 's comment about corporate governance. |
With IAM roles for service accounts, my understanding was that kube2iam was not required anymore and that IAM roles for service accounts should be preferred for kubernetes on AWS.
It doesn't look like it's 100% the case so I am trying to understand why kube2iam is still needed. Are IAM roles for service accounts only for EKS? Are there reasons to prefer kube2iam even on EKS? I would love to hear the thoughst of the community to help guiding the future direction for kube2iam e.g. deprecation or not.
The text was updated successfully, but these errors were encountered: