Securing EKS Resource Deployment: Integrating OIDC IAM Roles with GitHub Actions

This blog guides integrating OIDC with GitHub and AWS. This integration enhances security by removing the necessity for persistent IAM access keys, offering a safer approach for accessing AWS resources directly from your GitHub repository. Additionally, it will cover a method to enable communication between other IAM principals and your EKS cluster.

1.Configuring OpenID Connect (OIDC)

In the IAM service, select Identity Provider

Add the identity provider
Provider URL: https://token.actions.githubusercontent.com
Audience: sts.amazonaws.com

2.Assign an IAM Role

Create an IAM role with the permission necessary to perform the operation on the EKS cluster and assign it to the provider.

Either create a new role or use the existing one. For this blog, I will create a new role.

Update the GitHub username for which the role is going to be used. You can also restrict the usage by adding the repository and branch details.

Earlier, I created a policy with access to manipulate the cluster within the account and attached the policy to the role.

After attaching the policy review the details and create the role. We will later use this role to deploy the resources on the EKS cluster.

Adding IAM role to EKS cluster using aws-auth config map

By default, rights within the cluster are immediately granted to the IAM principal who created it. To allow other IAM principals to communicate with your cluster, update the aws-auth ConfigMap within Kubernetes and create the Kubernetes role/cluster role and role binding/cluster role binding.

Role and ClusterRole

An RBAC Role or ClusterRole contains rules that represent a set of permissions. A Role always sets permissions within a particular namespace. On the other hand, ClusterRole is not namespaced(cluster-wide).

RoleBinding and ClusterRoleBinding

A role binding grants the permissions defined in a role to a user or set of users. It holds a list of subjects (users, groups, or service accounts), and a reference to the role being granted. A RoleBinding grants permissions within a specific namespace whereas a ClusterRoleBinding grants that access cluster-wide.

3.Adding the role in the cluster

Create the Role in the cluster. For example purposes, I have been given full access to the role. Remember a Role is always bound to a namespace. Create the Rolebinding for the above role. Add the resources in the cluster Update the aws-auth config map.
In the end we need to update the config map in the cluster. This will allow IAM role to communicate with the cluster. I am going to use eksctl tool to update the ConfigMap. Now, the IAM role can access the EKS cluster.

4.Test the pipeline

I created a basic pipeline that will create a Deployment on the eks cluster and will start a pod(redis). Please check eks-blog repository for the files. After adding the environment, and secret variables in the repository. I was able to deploy the resource on the cluster using the IAM role created earlier.

This blog discusses access to EKS by using the aws-auth config map to allow various IAM roles, which is a traditional method for EKS cluster access management. There is also a newer method, using Access Entries. The upcoming blog will delve into this new method, exploring how it can be used for managing access to EKS clusters more effectively.