As you begin working with Elastic Kubernetes Service (EKS), one of the first questions that’ll come up is how you'll manage access to your cluster. Your team will need to know how to get the access they need and management will need to understand how the chosen tools will address security risks and policies.
In this blog post, you’ll learn about a two methods to manage access to EKS:
Out of the box, Kubernetes provides the rbac.authorization.k8s.io/v1 API that’s available in the named API group. rbac.authorization.k8s.io/v1 provides the ability to manage everything and anything from a permissions perspective for every Kubernetes resource. It’s very granular so if, for example, you want a particular user to only have read permissions to Pods in a particular namespace, you can configure those specifications.
First things first. You’ll need a user, service account, or group. Because Kubernetes doesn’t have a method out of the box to create users, you can use a service account in the Core API group.
Next, create a Role. The Role will have specific permissions mentioned inside of it. The example definition below indicates that for Pods and Deployments, you want the ability to list/get/read them and create/update them.
To ensure that the service account can use this Role, bind them together with a RoleBinding.
You should now be able to see the Role and RoleBinding created.
Although this may not seem like a lot of setup for one service account, what if you have five? Or ten? Or one hundred? And what about users and groups? The native RBAC in Kubernetes, although extremely powerful, can become a major hassle very quickly.
One alternative to using Kubernetes RBAC is OpenID Connect (OIDC). There are several solutions that allow you to use a third party to authenticate and authorize permissions on a Kubernetes cluster. Fortunately, one of those OIDC solutions integrates with AWS IAM which can help streamline access management on EKS clusters.
In this section, you’ll learn how to configure an IAM OIDC identity provider using AWS IAM.
The first step is to log into the AWS console and go to your EKS cluster. If you go to the Overview tab and click on Details you’ll be able to find and copy the OpenID Connect URL.
Next, open the IAM service and navigate to **Identity Providers **under Access Management. Next, click the blue Add provider button.
Choose OpenID Connect as the provider type.
Paste in the OpenID Connect URL that you copied from the EKS cluster and then click the Get thumbprint button.
For the Audience, add: sts.amazonaws.com
Once complete, click the blue Add provider button.
Now you’ll see an output similar to the screenshot below indicating that the provider has been added. You’ll also see a message that requires you to assign an IAM role so the provider can be added. Click the Assign role button and choose the option to Create a new role.
Choose Web identity for the OpenID provider (the provider should already be auto-populated) and then choose the Audience. Once complete, click the blue Next: Permissions button.
The permissions indicate what a Pod is allowed to access in AWS. For example, if the Pod needs to communicate with S3, you could give the role S3 permissions.
Click Next through the Tags screen, indicating that you don’t add any tags (although, you can if you’d like). Then, give the Role a name and click the blue Create role button.
Congrats! You have successfully configured EKS to use IAM Roles via OIDC.
In native Kubernetes, the job of authentication and authorization are separate. But from the perspective of your Kubernetes cluster, OIDC for IAM in AWS combines these concerns and moves the details to AWS. For many engineering teams, this can help streamline access management since users, roles and permissions are probably already set up in AWS IAM. Enabling IAM user and role access to your cluster helps centralize and simplify access management which, in turn, will help you keep your company more secure.
