Skip to content

One of the main pillars of the cloud  are scalability; availability; reliability and elasticity.

Not all cloud solutions are scalable, so it is important to know  the  best practices to achieve this. 

EKS, the AWS managed service for Kubernetes, launched in 2018  has  the ability to integrate with IAM. So you could authenticate against the Kubernetes API using your IAM credentials.

You don’t have to worry about more credentials for you to manage, simply use  config map to register which IAM user or IAM role and selectively assign cluster wide or namespace selected permissions. 

AWS announced the integration of EKS with IAM Identity Providers, that allows  mapping IAM Roles for Service Accounts, to allow/give granular permissions to containers running on pods that needed specific AWS Resources permissions; for example, access to SNS topics, SQS queues, S3 buckets, and so on. 

To keep with the  Least Privilege Principle you had to use tools like Kube2IAM or Kiam (IAM Proxies), or otherwise give the IAM permissions to the whole node and all pods running on that node breaking the Least Privilege Principle, because you would be extending the permission to other pods that don’t need it. 
IRSA (IAM Roles for Service Account), was really a solution for scalable permission handling for containers/pods. But it still didn’t cover the individual users accessing the Kubernetes API. It basically consisted of using IAM as the OIDC provider that connects Roles with the Service Accounts in the cluster. So that Kubernetes pods could use it to authenticate against AWS resources, like an S3 bucket, for example.

After EKS was capable of connecting to IAM Identity Providers, using the OpenID Connect protocol, AWS finally took advantage of this.
In early 2020 AWS announced that EKS supported user authentication with OIDC compatible Identity Providers, which, after 3 years, aimed at the different ways users could interact with the Kubernetes API, and addresses the scalability problem!

How does it help scalability?

If you are or your company is using an OIDC compliant Identity Provider (which is common nowadays) you can continue using that same user configuration to decide how they can interact with Kubernetes API. EKS will trust that IDP (Identity Provider) and promote the handshake for both systems to allow pass permissions of the users from the IDP to Kubernetes.

It’s important to note that this is possible in EKS, because Kubernetes as is, already supports OpenID Connect. AWS took this feature and injected it into the core of EKS, so that  you can associate an OIDC provider to the cluster.

You can configure it using the AWS CLI, AWS SDK, CloudFormation, eksctl, or the AWS Management Console.

After you set everything up correctly, your users will be bound to Cluster Roles that define the specific set of actions they can do against the Kubernetes API.

So, if a new user requires access to the API, you no longer have to go to a configuration file in Kubernetes to allow it, or its role. Instead, it should  be added to the IDP already, so ensure it is compliant with the rules you established (i.e belongs to a certain group, has a certain role, etc), then show the user where the Kubernetes cluster is.

Considerations

These are important points you’ll need to consider when using OIDC as a user authentication method on EKS:

  • You can only attach an OIDC provider to an EKS cluster, at least at this time. This might impact your workflow if you already have one for the IAM Roles for Service Accounts solution.
  • The OIDC needs to be publicly accessible, so that EKS can access it.
  • The version of Kubernetes needs to be 1.16 or higher.

EKS exposes access logs to its “audit log” to CloudWatch. You can also monitor using the authentication log. The audit logs are disabled, but can be turned on at any time. Just a heads up on CloudWatch cost.

Real life examples

We are making a series of blog posts on this topic. These are labs with different Identity Provider Services integrated with EKS. You can follow up with the one you like/need.

Conclusion

If you already have a central source of Identity Provider that supports OIDC, you can connect it with EKS. This will give your users access to the Kubernetes API. The process might change depending on which IDP you are using , but in general it is the same. Auth0, Okta, Azure AD, or even Amazon Cognito, are IDPs that support this protocol.`

Share this post

Share on facebook
Share on linkedin
Share on twitter
Share on telegram
Share on pinterest
Share on email
Share on reddit
Share on whatsapp

How To Start In 3 Steps:
1. Book A Call.
Set a time for us to talk.
2. Create and Execute Your Plan.
Requirements timelines and Resources.
3. Enjoy Your Life In The Cloud.
Fast reliable and continuous delivery.