🔐 Kubernetes RBAC 🔐

In Kubernetes, RBAC is used to control who (which users or processes) can perform what actions (create, delete, get, update) on resources (pods, services, nodes, etc.). Managing access to various Kubernetes resources is crucial for security and control. RBAC provides a way to define fine-grained access policies.

The RBAC API declares four kinds of Kubernetes object.

1. Role

2. ClusterRole

3. RoleBinding

4. ClusterRoleBinding

An RBAC Role or ClusterRole contains rules that represent a set of permissions. Permissions are purely additive (there are no "deny" rules).

A RoleBinding grants permissions within a specific namespace whereas a ClusterRoleBinding grants that access cluster-wide.

Key Components of Kubernetes RBAC:

Role: A Role always sets permissions within a particular namespace; when you create a Role, you have to specify the namespace it belongs in. A role can be associated with one or more resources.

ClusterRole: ClusterRole is a non-namespaced resource. It grants permissions within the entire cluster.

💡If you want to define a role within a namespace, use a Role.

💡If you want to define a role cluster-wide, use a ClusterRole.

RoleBinding: A role binding grants the permissions defined in a role to a user or set of users. It holds a list of subjects (users, groups or service accounts), and a reference to the role being granted.

ClusterRoleBinding: Binds a ClusterRole to a user or a group across the entire cluster.

💡If you want to define a role within a namespace, use a Role; if you want to define a role cluster-wide, use a ClusterRole.

❌ After creating a binding, you cannot change the Role or ClusterRole that it refers to. If you try to change a binding's roleRef, you get a validation error. If you do want to change the roleRef for a binding, you need to remove the binding object and create a replacement.

How RBAC Works:

1. User Authentication: Users authenticate themselves to the Kubernetes cluster using various authentication mechanisms (such as certificates, tokens, or external providers).

2. Authorization: After authentication, the Kubernetes API server checks whether the authenticated user is authorized to perform the requested action. This is where RBAC comes into play.

3. RBAC Rules: RBAC rules are defined through Roles and ClusterRoles. These roles specify what actions are allowed on which resources.

4. Binding Roles: Roles and ClusterRoles are then bound to users or groups using RoleBindings and ClusterRoleBindings.

🗨 Example Scenario:

Let's say you have a namespace called "testenv," and you want to grant a user named "testuser" the ability to list and get pods within that namespace.

Step 1: Create a Role

Step 2: Create a RoleBinding

In this example, the "testuser" user is bound to the "pod-reader" Role within the "testenv" namespace, granting them the ability to get and list pods.