Setting Autoscaler on EKS Using OIDC
So. You want to deploy the Autoscaler on EKS. But, plot twist: you’ve got
OIDC in the mix. How do you do that without summoning an ancient demon from
the depths of AWS documentation?
Well, after a full day of dancing with Terraform dragons and arguing with
variables that behave like goblins, I stumbled across a solution.
(Or maybe it stumbled across me. These things are hard to tell.)
You might think you could just call module.eks.oidc_provider_arn and be
done with it. And in a world governed by logic and kindness, that might
actually work. But our world—our delightful chaos—uses a meta-module.
Which calls other modules. Like so:
- EKS (the head honcho)
- GitLab Runner (who shows up late but does the work)
- Istio (no one really understands it, but it’s important)
- Etc. (the real MVP)
So, the simple solution? Utterly useless. Because we want to get everything
from var.eks_cluster_name, which we gracefully pass into this meta-monster.
Using the first method would mean hardcoding the cluster name inside the
runner submodule. And hardcoding is, of course, a mortal sin.
Thus, we turn to a solution both elegant and absurdly convoluted. We reach
into the Terraform bag of holding and pull out data. Then we politely askaws_iam_openid_connect_provider for its precious arn. We use this in thetrust policy, so our noble runner may indeed be validated by the mighty OIDC.
Still with me? No? Excellent. That means you’re paying attention.
1 | data "aws_eks_cluster" "this" { |
Now, with this magical arn in hand, we can bravely proceed to summon ouraws_iam_role for the Autoscaler:
1 | resource "aws_iam_role" "autoscaler" { |
And what sacred bond do we forge in this trust relationship? Behold:
1 | { |
And lo! It works. Somehow. Don’t ask why. The code gods have smiled upon you.
1 | # module.gitlabrunner.aws_iam_role.autoscaler will be created |
So go forth, brave engineer! Your Autoscaler is alive. The OIDC has been
appeased. And you only had to sacrifice a little sanity to get here.