What is Kubernetes Role-Based Access Control (RBAC)?
Tags: kubernetes, k8s, cka
Published: 2022-01-05 14:40:14

## Overview
Kubernetes Role-Based Access Control (RBAC) is a kind of access and identity management (IAM) that involves the use of a permissions list or template that decides who (subjects) can perform what (verbs) and in what order (namespaces). RBAC is a change from the more traditional attribute-based access controls (RBAC)--which gives access to users based on their name, not on the basis of responsibilities.

## What Exactly is Kubernetes?
Kubernetes (also called Kube, k8s, or) is an open container orchestration platform developed by the open-source community which automatizes a lot of manual steps involved in the deployment managing, scaling, and managing containers for applications.
If managed through Kubernetes, as mentioned in the [Kubernetes Training in Chicago](https://www.edureka.co/kubernetes-certification-training-course-chicago), Linux containers give microservice-based applications an ideal deployment device and self-contained execution environment. Additionally, since Kubernetes deployments can be written with YAML and YAML, the code is readable by humans.

## What are the Kubernetes Roles?
Roles give different degrees of accessibility to pods and nodes. Roles are able to gain access to a particular cluster or group of clusters that are in collaboration in the form of an application load (known simply as roles) or even entire clusters (known as cluster roles).

- Roles allow access to virtually connected clusters, referred to as namespaces. Roles are a kind of namespace resource since user access to a particular workload is determined by the clusters that are part of the particular namespace. Users or groups of users and service account name names may be combined into one role by binding roles.

- The role of a cluster gives permission to whole clusters, which consist of groups of hardware devices. Cluster roles may span several namespaces. The binding of a cluster role connects a role in a cluster to all namespaces in the cluster. For instance, the administrator role has no restrictions on access to the clusters.
Role binding and cluster-specific permissions can be combined or stackable using metadata. This allows permissions specified within a cluster role to resources in the namespace for the role binding. This helps create common roles for the cluster, which can be reused across different namespaces.

## What Is The Procedure For Kubernetes RBAC Function?
The Kubernetes API (application programming interface) is the interface to Kubernetes' control plane. It is the Kubernetes API that communicates with a system or computer to obtain information or carry out the task.
Kubernetes RBAC is a system that collects functions that are related to it into API groups and communicates with API servers when it connects certain functions with API endpoints.
For more information on using Kubernetes RBAC--including Kubernetes documentation, rbac.authorization.k8s.io authentication, the kubectl command-line tool, add-ons, kubelet TLS bootstrapping, and setting up network policies.

## Summary
Based on these cases, we are able to see certain limitations and behaviors with RBAC resources:

- Roles and bindings for roles must be part of the exact namespace.
- Role bindings may be in separate namespaces from service accounts.
- Role bindings may link roles in a cluster, but they can only grant access to the namespace for that role's binding.
- Cluster role bindings tie the accounts of individuals to roles in clusters and give access to all resources.
- Cluster role bindings are not able to refer to roles.
The most intriguing implication, in this case, is that a group role can establish common permissions, which can be expressed by a namespace it is referenced by a binding. This eliminates the requirement to create duplicate roles across multiple namespaces.