What is RBAC?

Role-Based Access Control (RBAC) in Kubernetes is a powerful mechanism to control and manage access to various resources in your cluster. It allows you to define roles and permissions for users and service accounts, ensuring that only authorized entities can interact with the cluster.

For example, a Developer role could permit users to create and list pods, while a separate Administrator role facilitates privileged actions, such as deleting pods.

Permissions are always additive; users are granted the set of permissions accrued from all the roles they've been assigned. This means that a user with both the Developer and Administrator roles would be able to create, list, and delete pods.

Exploring RBAC on Kubernetes

RBAC in Kubernetes consists of the following key components:

Role: A Role defines permissions within a specific namespace. It allows access to certain resources such as pods, services, or config maps.
ClusterRole: A ClusterRole is similar to a Role but applies cluster-wide. It defines permissions across all namespaces in the cluster.
RoleBinding: A RoleBinding binds a Role to a user or a group, granting them the defined permissions in a specific namespace.
ClusterRoleBinding: A ClusterRoleBinding binds a ClusterRole to a user or a group, granting them cluster-wide permissions.

The distinction between Roles and ClusterRoles is enforced because Kubernetes requires that all objects are either namespaced or non-namespaced.

This means you should use a Role when you want to control access to resources within a specific namespace. Or you can create a ClusterRole instead if you plan to reuse a Role across multiple namespaces or you're trying to limit access to cluster-level objects, such as nodes that aren't part of any namespace.

Real-Life Example:

Imagine you are managing a large e-commerce platform on Kubernetes. You have different teams responsible for various aspects of the application, such as development, operations, and security. RBAC can be used to control access as follows:

Developers: You create a Role named "developer-role" that grants permissions to read and modify pods within the "development" namespace. You then create RoleBindings to associate individual developers or the "developers" group with this Role.
Operations Team: You create a ClusterRole named "operations-role" that grants permissions to view and manage pods and services across all namespaces. You use ClusterRoleBindings to associate the "operations" group with this ClusterRole.
Security Team: You create a ClusterRole named "security-role" that grants permissions to view secrets and config maps across all namespaces. You use ClusterRoleBindings to associate the "security" group with this ClusterRole.

RBAC Code Example:

Below is an example of RBAC resources defined in YAML:

# Role for Developers
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: development
  name: developer-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch", "create", "delete"]

# RoleBinding for Developers
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: developer-role-binding
  namespace: development
subjects:
- kind: User
  name: developer-1
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer-role
  apiGroup: rbac.authorization.k8s.io

# ClusterRole for Operations Team
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: operations-role
rules:
- apiGroups: [""]
  resources: ["pods", "services"]
  verbs: ["get", "list", "watch", "create", "delete"]

# ClusterRoleBinding for Operations Team
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: operations-role-binding
subjects:
- kind: Group
  name: operations
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: operations-role
  apiGroup: rbac.authorization.k8s.io

This code example demonstrates how to create Roles and RoleBindings for developers, as well as ClusterRoles and ClusterRoleBindings for the operations team. Similar resources can be created for the security team and other groups as needed.

RBAC in Kubernetes provides fine-grained control over access, ensuring that teams and individuals have the appropriate permissions for their roles and responsibilities in your application's management.

How to create Users and how to do user management in Kubernetes?

In Kubernetes, users are typically created and managed through an external authentication system, such as an LDAP directory or an identity provider like Google or GitHub. These systems provide a way to authenticate users and allow them to access Kubernetes resources based on their assigned roles and permissions.

Once a user is authenticated, Kubernetes uses Role-Based Access Control (RBAC) to determine what resources the user can access and what actions they can perform on those resources. This allows cluster administrators to control who can access and modify the Kubernetes resources in the cluster.

Let's take a simple example to explain this to a non-IT person:

Suppose you are the owner of a company that has a Kubernetes cluster to host its applications. You have a team of developers who need access to the Kubernetes cluster to manage the applications. To give your developers access, you first need to create user accounts for them in an external authentication system, such as an LDAP directory or an identity provider. Once their user accounts are created, you can configure RBAC in Kubernetes to grant them the appropriate access to the cluster.

For example, you might create a Role in Kubernetes that allows users to read and list the pods in the cluster. You can then create a RoleBinding that assigns this Role to a group of users, such as your team of developers.

Kubernetes Service Accounts:

In Kubernetes, a Service Account is an identity that allows a Pod to interact with the Kubernetes API server and other Kubernetes resources. Think of a Service Account as a way for a Pod to prove its identity and obtain permission to access resources in the cluster.

Here's a simple example to explain Service Accounts to a non-IT person:

Imagine you're a VIP attending a party at a club. To enter the club and access certain areas, you need to prove your identity by showing your ID and pass a security check. Once you're inside, you can use your VIP pass to access exclusive areas and services. In Kubernetes, a Pod is like a person at the party, and a Service Account is like a VIP pass. The Service Account allows the Pod to access certain areas and services in the cluster. The Pod can use the Service Account to prove its identity and obtain permission to access Kubernetes resources.

Roles:

A role is a set of permissions that defines what actions a user or group of users can perform on a specific resource in a K8s cluster. A role is defined using a YAML file that specifies the rules for the role.

The following is an example of a role definition:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: <role-name>
  namespace: <namespace>
rules:
- apiGroups: [""]
  resources: ["<resource>"]
  verbs: ["<verb>"]

This role definition allows the specified user or group of users to perform the specified verb on the specified resource.

Role Bindings:

A role binding is a Kubernetes resource that binds a role to a user, group of users, or service account. A role binding allows a user or service account to perform the actions defined in the role.

The following is an example of a role-binding definition:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: <role-binding-name>
  namespace: <namespace>
subjects:
- kind: User
  name: <username>
roleRef:
  kind: Role
  name: <role-name>
  apiGroup: rbac.authorization.k8s.io

This role-binding definition binds the specified user to the specified role.

Identity Providers:

An identity provider (IDP) is a third-party service that is used to authenticate and authorize users in a K8s cluster. K8s supports various identity providers, including LDAP, Active Directory, and OpenID Connect.

The following is an example of an OpenID Connect identity provider configuration:

apiVersion: v1
kind: ConfigMap
metadata:
  name: oidc-config
data:
  issuer: <issuer-url>
  client-id: <client-id>
  client-secret: <client-secret>
  redirect-uri: <redirect-uri>
  response-type: code

This configuration specifies the URL of the OpenID Connect provider, the client ID and secret, the redirect URI, and the response type.

To log in to an OpenShift cluster, follow these steps:

Get the URL of the OpenShift cluster and your credentials from your system administrator.

🔗 developers.redhat.com/developer-sandbox
Install the oc command-line tool on your local machine.
Use the oc login command to log in to the OpenShift cluster:

oc login <cluster-url> --username=<username> --password=<password>

This command logs you into the specified OpenShift cluster with the specified username and password.

Once you are logged in, you can use the oc command-line tool to manage resources in the cluster.

Kubernetes RBAC and Pod Security Policy

Kubernetes Cluster can be secured by using Role Based Access Control (RBAC) and Pod Security Policies (PSP).

RBAC: defines both roles & bindings on either namespace or cluster level.

In Kube, there are 3 types of Subjects : [User, Group, ServiceAccount]

We assign Permissions to a Role.

We can Bind Role/ClusterRole with [User, Group, ServiceAccount]

{API Permissions -> Role -> Subject -> Actions in Kube Cluster}

Role Binding grants permissions to ServiceAccount at Namespace level or Whole Cluster level.

cluster-admin Role gives permissions to perform any action in the cluster. This is like giving root access to User in a Linux system.

RBAC in Kubernetes:

Apps running in Pods, need right permissions to call Kube API. For this, Pods need to use a Service Account.
When you use kubectl tool or Kubernetes Dashboard, you need a User API Token for Authentication and Authorization with Kube API server.
But when ReplicationController or Apps inside Pods or External Apps want to talk to API server, they will require ServiceAccount.
If you want to Revoke Access to Users / ServiceAccount, then please delete all Role Bindings for these Users and ServiceAccounts.

K8s RBAC is a powerful security mechanism that helps administrators manage access to resources in a K8s cluster. It allows administrators to define roles, role bindings, and service accounts to control access to resources. Identity providers can be used to authenticate and authorize users in a K8s cluster. By following the steps outlined in this blog, you can create and manage users, service accounts, roles, and role bindings in a K8s cluster, and you can also configure identity providers to authenticate and authorize users.

All About Kubernetes RBAC