Kubernetes - RBAC And Admission Controllers

What is RBAC?

From Wikipedia:

"In computer systems security, role-based access control (RBAC) or role-based security is an approach to restricting system access to authorized users. It is an approach to implement mandatory access control (MAC) or discretionary access control (DAC)."

From official Kubernetes doc:

“Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within your organization.”

RBAC (Role-Based Access Control) is a critical concept to understand when working with a Kubernetes cluster, as it determines which users can perform which actions within the cluster. In a multi-tenant environment, you may want to grant access to different teams within their own namespace, with each team having different roles (such as developer or admin). You may also need to define different RBAC roles for different job roles within a namespace and for accessing different resources within a namespace.

Simply put, RBAC allows you to protect access to resources within your cluster(s).

In addition to RBAC, you may also want to use Admission Controllers, which are a set of features in Kubernetes that allow you to control what is allowed into your cluster. With Admission Controllers, you can validate and manipulate incoming requests, and there may be various use cases for doing so. Most Kubernetes distributions come with several out-of-the-box admission controller plugins that are enabled by default, which you should be aware of.

❗In this article, we will combine information from the official Kubernetes documentation with our own insights and experience to provide a more comprehensive and understandable overview of the topic. We will clearly distinguish between content from the official documentation and our own additions by highlighting the former in the text

This article aims to provide a thorough understanding of the RBAC concept in Kubernetes, rather than step-by-step instructions for setting it up. The concepts discussed in this article are applicable to all Kubernetes distributions, though specific implementations, such as the integration of AWS IAM with Kubernetes RBAC in AWS EKS, may vary. By the end of this article, you should have a solid understanding of how RBAC works in Kubernetes.

For more in-depth instructions on setting up Kubernetes RBAC, keep an eye out for a full Kubernetes course to be released soon at devoriales.com.

RBAC Objects

In this paragraph, we are listing the objects that are related to the Kubernetes RBAC model and where they fit in the cluster. Later on, we will learn how they depend on each other.

• Entities: These are users, groups, or service accounts that need permissions to perform actions in the cluster, either within a namespace or cluster-wide.
• Resources: These are objects within the cluster, such as pods, secrets, config maps, services, and PVCs, that the entities need access to.
• Roles: These define the actions that entities can perform on resources within a namespace.
• ClusterRoles: These work similarly to roles, but are used to define actions that exist at the cluster level (such as nodes or namespaced resources) and can be granted for all namespaces.
• Bindings: RoleBindings and ClusterRoleBindings link an entity (e.g. a user) to a set of permissions (a role or cluster role).
• Namespaces: These provide a security boundary that allows different users or teams to work with their own resources within the cluster. They are useful for creating a multitenant environment within the cluster.

The following represents the components related to Kubernetes RBAC and where they fit in the cluster: