New EKS IAM Auth Changes
AWS has recently introduced an improved and simplified way to manage access to your EKS cluster with IAM.
The Amazon EKS team has improved the cluster authentication (AuthN) and authorization (AuthZ) user experience with improved cluster access management controls. As of the date of this post, cluster administrators can now grant AWS IAM principals access to all supported versions (v1.23 and beyond) of Amazon EKS clusters and Kubernetes objects directly through Amazon EKS APIs. This new functionality relies on two new concepts: access entries and access policies. An access entry is a cluster identity—directly linked to an AWS IAM principal user or role—that is used to authenticate to an Amazon EKS cluster. An Amazon EKS access policy authorizes an access entry to perform specific cluster actions.
This change is effectively a better aws-auth
ConfigMap. Before, we had to map SSO roles and users from IAM to the Kubernetes cluster and then use Kubernetes roles to configure access. For example, you can grant access to certain Kubernetes namespaces without using Kubernetes Roles.
The improved customer access management controls enable administrators to completely remove or refine the permissions automatically granted to the AWS IAM principal used to create the cluster. If a misconfiguration occurs, then cluster access can be restored simply by calling an Amazon EKS API, as long as the caller has the necessary permissions.
I wrote previously about how EKS cluster creators have complete admin access. The new API auth fixes these issues with the old ConfigMap auth.
I haven’t had a chance to play around with these changes, but it seems like a big step in the right direction.
If you’d like to read the AWS blog post, you can do so here.
Master GitHub Actions with a Senior Infrastructure Engineer
As a senior staff infrastructure engineer, I share exclusive, behind-the-scenes insights that you won't find anywhere else. Get the strategies and techniques I've used to save companies $500k in CI costs and transform teams with GitOps best practices—delivered straight to your inbox.
Not sure yet? Check out the archive.
Unsubscribe at any time.