Security in kubernetes can be quite complex, as there are a lot of disparate parts which must be pieced together in order to get a full picture of the overall architecture. One of the best ways to understand security in kubernetes is to study the individual concepts one at a time. Today we are going to explore the concept of Role Based Access Controls (RBAC) and how they fit in with the general architecture of kubernetes.

Imagine that you are a kubernetes administrator, working on a large cluster or clusters comprising of many nodes and complex applications. How do you define a systematic approach to authorization for your team? Surely, not every team member needs to have access to all parts of the cluster. How do you define what rights and privileges are granted to each member of your team to create, view, modify or delete resources? Luckily, kubernetes provides Role Based Access Control (RBAC). RBAC helps us to achieve fine-grained control over who can do what within our cluster(s).

To understand RBAC, it is necessary to understand how kubernetes processes requests. The API server is responsible for processing requests in kubernetes. When a request comes into the API server, it has to go through a series of events before it is processed by the API server. These series of steps are broadly categorized into Authentication, Authorization and Admission Control.

Authentication validates the identity of the requester that sent the API request. This could be users communicating via kubectl, service accounts within pods or the control-plane and worker nodes. Authentication is enabled through authentication plugins. With plugins, we can define several authentication methods to the API server. There are several authentication plugins that enable authentication, some of which include: client certificates, authentication tokens or Basic HTTP.

Authorization is the process that determines if the requester is allowed to perform actions on resources as stated in the submitted API request. Authorization is also enabled through authorization plugins. This could be Role Based Access Control (RBAC), Node or Attribute Based Access Control (ABAC). Role Based Access Control in kubernetes is implemented at the authorization stage of the API request.

Admission control basically enables administrative control over API requests. This is achieved by admission controllers, which intercept requests to the API server before the object is persisted in etcd.

What Are Role Based Access Controls?

Role based access control is an authorization plugin implemented on the API Server. RBAC is a method of regulating access to cluster resources based on defined roles assigned to subjects. RBAC allows us to write rules which determine what actions can be performed on resources in our cluster. Since RBAC denies by default, only allow rules can be written which permits actions to be performed on the resource. These rules will then have to be bound to subjects. Subjects in RBAC refer to users, groups or service accounts. RBAC implements several API objects such as role, cluster role, role binding and cluster role binding.

Roles define what actions that can be performed on resources within a namespace. Roles can be made up of one or several rules which define the Verbs for resources. Roles are defined using RESTful HTTP semantics. Verbs are similar to HTTP styled verbs such as GET, DELETE, etc. Since RBAC denies access by default, only allow rules can be defined for roles. Since Roles only exist within a namespace, the rules that are defined are bound within that namespace. It is not possible to define a role to perform an action outside the namespace in which it exists.

ClusterRoles are quite similar to roles. They both define permission for actions to be performed on resources. The fundamental difference is that ClusterRole is not a namespaced API object. What this means is that ClusterRole is cluster-scoped. They provide access across all namespaces and to cluster-scoped resources such as Nodes and Persistent volumes. Using a ClusterRole enables us to define a single set of rules and apply them across all resources within our cluster. This greatly reduces administrative overhead since we do not need to define the same rule set over and over across all namespaces.

RoleBinding grants a subject access to a Role or ClusterRole. Essentially, a RoleBinding defines who can do what has been defined in a Role or ClusterRole. When a Role is attached to a RoleBinding, the intention is to grant permissions within a namespace. When a ClusterRole is attached to a RoleBinding, the intention is to grant permissions across several or all namespaces.

ClusterRoleBinding is used to grant cluster-wide permissions across all namespaces. when a ClusterRole is attached to a ClusterRoleBinding, permissions are granted across all namespaces and cluster-scoped (non-namespaced) resources.

Kubernetes provides default roles that can immediately be put to use if we do not wish to define custom Roles/ClusterRoles.

• Cluster-admin: This ClusterRole is the super user in kubernetes. It can potentially perform all actions on all resources across all namespaces. When it is attached to a RoleBinding, it has unrestricted access and rights across the defined namespace. When used with a ClusterRoleBinding, it assumes unrestricted rights and privileges across all namespaces and cluster-scoped resources.

• Admin: This role permits unlimited read/write access to resources within a namespace. However, it does not grant access to the namespace itself.

• Edit: This role grants read/write access within a given Kubernetes namespace. Access to view and modify Roles and RoleBindings is however denied.

• View: This role allows read-only access within a given namespace. A subject in a RoleBinding attached to this role will only be able to view resources but unable to modify, create or delete them.

Properly implementing Role Based Access Control within a cluster is a very important aspect of security in kubernetes. RBAC gives an administrator the ability to implement least-privileged access in Kubernetes.