-
Notifications
You must be signed in to change notification settings - Fork 79
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
[Discussion] EKS Pod Identity #42
Comments
You will need to do the association somewhere. You might not need to pass the variable(s) to the helm chart (if you use the correct service name and namespace) but you still need to create the iam and associate it. Also the application need to use a recent version of the aws sdk to be able to support it if I read correctly. For me the goal is to remove the going back and forth from TF to yaml. Our idea (still idea) is to use the terraform operator for this. So we can make a crd for a TF module that does the association and make it part of the chart. |
Yeah I've done an internal comparison between tf-controller, Pulumi operator and Crossplane this week so familiar with the play. Though in those scenarios you still need to pass something into the cluster to be able to "get your bearings" - like the current VPC ID, or the EKS cluster name, or subnets etc, things that allow you to do relative lookups. I've had a decent enough success with just passing in the VPC Id and the EKS cluster name, as you can derive most other things from those terraform data sources... That being said, I am seeing the value of passing arbitrary strings into my ArgoCD cluster secret to be able to use them in templating in the ApplicationSets, as this repo demonstrated so nicely. I just see the IRSA/IAM Role ARN/Service Account chain part of this process diminishing with time. Doubly so if they add wildcard support for namespaces and service accounts in the Pod Identity mappings. This entire paradigm has been born out of the limitations we faced and how to surpass them so I'll be happy for the day when they don't exist any more and it all just works. |
Even if no metadata data is passed I find it useful the examples of showing the ApplicationSet used with cluster generator to show how you can have different clusters for different environments (dev, stage, prod) this could be 100s of clusters using the same repo each with an argocd instance, but all the clusters with same config having different versions of helm charts and corresponding values.yaml |
For sure, this repository has been a fantastic introduction (and I've adopted it at work) for doing environmental configs with It's a bit cross cutting as I've been doing most of my musing on the Akuity/Kargo discord, if we end up in a position where we can pull helm values from an arbitrary secret and or free form hash map of values on a Stage Kargo Object then we could replicate most of this in Kargo too. At the very least I'm excited for reducing my IRSA use as 2024 goes on. Guess still waiting on the upstream Terraform modules to adopt it before it's going to be rolled out in my org. Cross link for anyone else stumbling on this issue: aws-ia/terraform-aws-eks-blueprints-addons#289 |
Same here, adopted this as well. Thank you for this entire project, its been immensely helpful. I still struggle with having to make two commits, one in the bootstrap and another in the template-repo when I need to turn something else on, but I guess there's not much anyone can do about that. |
Hi @danielloader the team is looking on implementing EKS Pod identity in the, once we have a v2 I will update gitops-bridge |
Hi @mbuotidem
Can you provide more details on what is the pain point? |
On the other hand ... once you automate everything the added value apart from the visibility from EKS console is limited imho. Cross account permissions (for example external dns with route53 in a different account) become more difficult with pod-identity. |
This has gone a long way to getting there, thanks! |
I'll start with a controversial statement - Since EKS Pod Identity has been launched at re:invent 2023 the value add for creating IRSA roles, passing those IAM roles through to ArgoCD and down into ServiceAccount annotations seems to have diminished.
Is this a fair read on the situation? It's removed the chicken and egg situation I once faced and why I assumed this repository came to exist in the first place.
Open to thoughts on the matter and hopefully start some discourse as someone who has adopted the patterns in this repository and found them to be the only way to make IRSA truly usable in my organisation - but my eyes are on the future and simplification where possible.
The text was updated successfully, but these errors were encountered: