EKS (AWS) AND RBAC, step by step
Introduction
Amazon Elastic Kubernetes Service (Amazon EKS) offers a rich set of controls that can be used to effectively secure clusters and their applications. This article will focus on two key controls: Environment segmentation and Role-based access control.
Environment segmentation serves as an obstacle, which makes lateral movement difficult and isolates security issues. Whether it be a malicious attack or technical fault, proper segregation can limit the spread to other internal areas, reducing the potential impact. Role-based access control (RBAC) is a method of regulating access to a computer or network resources based on the roles of individual users within an enterprise.
This guide has the goal of giving step-by-step information to achieve the following objectives:
- Create three different environments: dev, qa and prod
- Create three different roles: Admin, Developer, Production Maintenance
- Admin will have full access to all environments
- Developer will have full access to Dev, restricted access to QA and no access to Prod
- Production Maintenance will have no access to dev and qa but full access to prod
3. Create three different users, one for each role
4. Configure aws-cli to “jump” from one user to another to check the permissions on each environment
Below points are covered in this article:
1- Concepts
2- Configuration
3- Testing
4- Conclusion
5- References
1- Concepts
EKS
EKS is the Kubernetes platform build by AWS. The cloud provider lets create the essential elements to have a Kubernetes cluster up and running in a short time.
Authorization/authentication model
One of the most valuable ways to integrate the authorization and authentication schema of AWS with the ones provided by k8s is RBAC (Role-Based Access Control)
In this model, the authentication is delegated to AWS, and the authorization remains in the k8s cluster through the aws_cli software that allows performing actions from the command line in the AWS cloud.
2- Configuration
An operative EKS cluster, aws-cli installed and configured, kubectl installed and configured to manage the EKS cluster. The following steps are designed to work in a *NIX system
Create namespaces
In this step, we set up three namespaces that will be the ones that the configurations will be applied to. This is just a typical situation for a development environment.
Create IAM roles, groups and policies
The creation of the three roles, groups and policies is as follows:
Admin
Developer
Production
Role and permission binding
In this step, the k8s roles received their grants. The details of what each permission and api-groups and resources do will be explained in another post.
Admin EKS cluster role and cluster role binding creation
In this step, the predefined Kubernetes admin role is assigned to “our” AWS role for the whole cluster
Developer role and role binding for dev in EKS
In this step, we bind the developer permissions to dev environment.
Developer role and role binding for qa in EKS
In this step, we bind the developer permissions to qa environment.
Support role and role binding for prod in EKS
In this step, we bind the production support role permissions to prod environment.
Create the EKS roles
In these steps we create the roles in our cluster and make them explicit for use in the RBAC configuration
We start the configmap editing with:
kubectl edit configmap -n kube-system aws-auth
And add the roles in the following way
Create IAM users for test
Now is the time to create some users and configurations for testing. This step is not required for the porpoise of this tutorial but it is useful for testing the capabilities of the roles that recently were created
Developer
Admin
Production
Add users configurations for EKS
3- Testing
Now you can jump from one user to another just by setting the AWS_PROFILE variable in the command line
export AWS_PROFILE=admin
Testing the credentials
aws sts get-caller-identity
4- Conclusion
RBAC is a powerful tool for handling the authorization process in Kubernetes. The integration with AWS EKS is a little bit tricky because in the config-map the structure:
username: admin-user
despite the tag name, it refers to the AWS role, which can create confusion and that is because AWS make a bet for their own container management services such as ECS and the EKS come lately based on the Kubernetes success as orchestrator.
5- References
Basic roles definition
https://kubernetes.io/docs/reference/access-authn-authz/rbac/#discovery-roles
Kubernetes cheatsheet
https://kubernetes.io/docs/reference/kubectl/cheatsheet
Verbs and resources in Kubernetes
https://kubernetes.io/docs/reference/access-authn-authz/authorization/