Search for a command to run...
How to use AWS IAM-Roles for Service Accounts to Assign Permissions to Kubernetes Pods on EKS using Terraform
Passionate engineer with a decade of experience in the cybersecurity industry. Enjoy piecing together solutions involving many moving parts. Big fan of the 'It finally works!' your brain yells when a complex project comes together. Love all things cloud, security, and containerized.
No comments yet. Be the first to comment.
As I type this, I’m scrolling the news and came across yet another vulnerability with an AI tool that removes the tools' safeguards, allowing malicious commands to be run. The rate that these vulnerabilities are occurring is a bit scary but unsurpris...
A simple example of Go modules and binaries
Look directly into ETCD, the backbone of your Kubernetes cluster
The AWS Documentation is vague on this subject, so this guide will detail the relationship between SecurityHub and Config. It's assumed that knowledge of what SecurityHub and AWS Config are is present. What will follow is based on AWS best practices....
AWS KMS is one of those services that works tirelessly in the background but doesn't get a lot of love. It's common to automatically encrypt every service as part of development and infrastructure-creation workflow, and this usually happens through K...
Relevant Links:
IRSA stands for IAM Roles for Service Accounts. It sounds a bit vague when thinking about it from a pure IAM perspective, but it allows you to create specific roles that can be assumed by pods running on a Kubernetes (k8s) cluster. In the before times, pods running on the cluster would act like docker containers and be bound to the node's IAM role of which they were running on. You used to have to do some trickery as shown Here.
Now, you can easily add your own custom IAM roles and their subsequent policies to specific pods on a k8s cluster. For example, if you have 3 pods running on one node, each pod can have a specific role giving it specific permissions that are not limited to the node's role -- in fact, best practice now would dictate the node role should have very limited permissions, perhaps a simple SSM policy that allows logging in directly to the node for troubleshooting.
See below for a simple diagram of what this looks like:
In a nutshell, when you use IRSA, you are creating a role that can be assumed by a pod. How does this work? Basically an OIDC provider is created, in the background. An IAM role is created, with a specific pod-policy attached. The role specifies the principal as A federated OIDC provider that was created for you. This role can only be assumed by a k8s service account (SA). That SA is annotated in K8s with the specific IAM role name.
All of this is taken care of for you in the background, and EKS does the hard work behind the scenes of figuring out the mapping between the Annotated SA and which pods are using that service account. Once everything is created, you should see the following from running:
kubectl get sa [service-account-name]
So how do we implement this in Terraform? We use the this Terraform Module. This module makes everything incredibly easy for creating the proper IAM resources needed to deploy your IRSA role. The actual tying of it to the pods should be done via a helm chart, but all that usually involves is setting the proper annotations for the EKS service account. The module conveniently outputs the role arn, so you can reference it in other places in Terraform.
Take a look at the following piece of code.
As mentioned before, all you need to do is reference this module's iam_role_arn output in Terraform wherever your annotations are being set for your service accounts, then ensure your pods are set to use that service account.
You'll know you did it correctly if you check your pods yaml file and see the following env variables:
Please check out my GitHub https://github.com/hrmcardle0 for other examples.
Thank you for reading.