Figuring It Out — Kubernetes, EKS, AWS | #3 — Role-Based Access Control (RBAC)

In the last two chapters, we have been mostly occupied with the initial setup of EKS, along with initial monitoring tools for understanding our cluster better. What about onboarding our teammates onto our EKS Kubernetes cluster, and assigning different groups of teammates the appropriate access rights? Let’s explore that today!

(Here’s the ongoing series — both old and new content. Clone the project at the correct tag to receive content up to that stage):

Role-Based Access Control (RBAC)

In line with the theme of security, RBAC represents the idea of assigning permissions to users through “roles”, and not exposing access to your tools publicly for all. These “roles” can represent different actual roles and functions in your company, such as DevOps engineers and Backend engineers.

Why is RBAC important?

Through these assigned “roles”, different users can gain the appropriate level of read and write access to tools that they need to function properly in their jobs. For example, a user assigned a “DevOps Engineer” role should have both read and write access to most Kubernetes resources in EKS for all environments, while a “Backend Engineer” role may only have up to read access in the production environment.

One benefit of following the RBAC methodology is the ease of delegating and maintenance of access control, especially if there is a large group of team members to cater for. It would simply be too much work to have to assign each granular permission for each individual. However, since most of these team members would fall under the same group, we can instead follow through with the following steps:

• Create roles with themes — like “DevOps Engineer” and “Backend Engineer”
• Assign permissions only to roles instead of to individuals
• Assign individuals to roles during onboarding. Offboarding/changing…