Kubernetes has a RBAC system that is analogous to AWS IAM. The RBAC systems is based on Roles that have one or more rules that allow that role to perform actions within the cluster. While the ability to create Roles and rules is quite robust, I will be focusing on utilizing preexisting roles that exist by default in every cluster. Kubernetes has both roles and cluster roles, with the former scoped to just a single namespace and the later scoped at the cluster level. All the role we will look at in the series will be cluster roles.
The first cluster role you should be aware of is the cluster-admin role. This is the super-user role for the cluster and can do anything within the cluster. When you create your EKS cluster the IAM principal used to create the cluster is granted the cluster-admin role. You must continue to use this IAM principal to configure a new cluster until you grant other IAM principals’ access to a role or cluster roles in the EKS cluster.
The other cluster role we will be looking at in this series is the admin role. Unlike the cluster-admin role, this role is intended to be used to manage a single namespace within the cluster. Default roles also include an edit and view role. While I won’t really address these other roles, they can be configured in the same way as the admin role. In-depth descriptions of each role can be found in the Kubernetes documentation, but at a high level:
- admin can manage all resources within a NameSpace, except for ResourceQuota configuration.
- edit can manage all resources except role configuration for the NameSapce. Think of this as like the PowerUser IAM policy.
- view allows readonly access to the namespace. Does not allow read access to role configuration or secrets.
Kubernetes groups are assigned to a role via a RoleBinding resource creating within a specific namespace. Note: Kubernetes users also exist but are not used when integrating Kubernetes RBAC with IAM.
A manifest for a RoleBinding resource looks like the following:
– kind: Group
This manifest creates a RoleBinding resource in the team1 namespace. It binds (i.e. assigns) members of the group team-admins1 to the cluster role admin. So, any principal that is part of the team1-admins group gets the admin role in the team1 namespace.
Groups are not a fist class object in Kubernetes. You create groups by simply referring to them in resources such as a RoleBinding resource. In the example above the team1-admins group did not have to be created before it is used, it is created by the fact it is referred to in the manifest.
Assigning IAM Principals to Kubernetes Roles
EKS allows assignment of IAM principles to Kubernetes roles. This is done via a ConfigMap that maps IAM principles to Kubernetes groups. Once the IAM principle is mapped to a group it is the bound to the role as covered in the RoleBinding config discussed above.
The aws-auth ConfigMap is used to map IAM roles to Kubernetes groups. Creating this ConfigMap in the kube-system namespace was one of the initial EKS cluster configuration steps. The manifest file below shows how to map a role with the ARN arn:aws:iam::123456789012:role/eks-team1-admins to the group team1-admins groups.
– rolearn: arn:aws:iam::123456789012:role/EksWorkers-NodeInstanceRole-FB41US3UY2HG
– rolearn: arn:aws:iam::123456789012:role/eks-team1-admins
It’s important to make sure to leave the first mapping for the EksWorkers role as this is needed for new EC2 instances to join your cluster.
The next installment of the series will cover IAM integration on the client side and how kubectl uses IAM principles to access your EKS cluster.
If you find that you’d like to help talking these kinds of problems with EKS, then checkout our Jumpstart for Container Orchestration. We can come on site and show you how to get EKS up and running securely and ready for production.