Securing EKS Resource Deployment: Integrating OIDC IAM Roles with GitHub Actions
profile picture Somya Sharma
3 min read Mar 27, 2024

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 1_blog3.png

Add the identity provider
Provider URL:

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. 3_blog3.png

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

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. 7_blog3.png Create the Rolebinding for the above role. 8_blog3.png Add the resources in the cluster 9_blog3.png 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. 10_blog3.png 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. 11_blog3.png 12_blog3.png

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.

service category

Innovate faster, and go farther with serverless-native application development. Explore limitless possibilities with AntStack's serverless solutions. Empowering your business to achieve your most audacious goals.

Build with us


Your Digital Journey deserves a great story.

Build one with us.

Recommended Blogs


These cookies are used to collect information about how you interact with this website and allow us to remember you. We use this information in order to improve and customize your browsing experience and for analytics and metrics about our visitors on this website.

If you decline, your information won’t be tracked when you visit this website. A single cookie will be used in your browser to remember your preference not to be tracked.

Build With Us