Introduction

In this blog, we will explore how we can authorize our new user (learner) to interact with cluster resources using RBAC, with hands-on examples. Let's get started.

What is RBAC?

Role-Based Access Control (RBAC) in Kubernetes is a method for regulating access to the Kubernetes API. It allows you to specify who can access what resources within a Kubernetes cluster, and what actions they can perform on those resources.

Key Concepts in Kubernetes RBAC:

Role: Defines a set of permissions within a namespace. It contains rules that represent allowed operations on Kubernetes resources.
RoleBinding: Grants the permissions defined in a Role to a user, group, or service account within a specific namespace.
ClusterRole: Similar to a Role, but it is cluster-wide. It can be used to define permissions across all namespaces or for cluster-scoped resources.
ClusterRoleBinding: Similar to RoleBinding, but it grants the permissions of a ClusterRole to a user, group, or service account across the entire cluster.

How RBAC Works in Kubernetes:

Roles and RoleBindings are typically used to control access within a single namespace like pods, deployments,etc.
ClusterRoles and ClusterRoleBindings are used for granting access to resources across the entire cluster or for non-namespaced resources like nodes.

Before starting with examples, please set an alias for kubectl:

alias k=kubectl

Role

A Role in Kubernetes is a set of permissions defined within a specific namespace. It allows you to specify which actions can be performed on which resources within that namespace.

Example: Defining a Role

Let's define a Role that grants read access to Pods in the default namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

RoleBinding

A RoleBinding associates a Role with a user, group, or service account within a specific namespace. This binding gives the specified subjects the permissions defined in the Role.

Example: Creating a RoleBinding

Let's bind the pod-reader Role to a user named jane:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRole

A ClusterRole is similar to a Role but is not limited to a specific namespace. It can define permissions cluster-wide or for specific namespaces. This is useful for granting permissions that need to be applied across the entire cluster.

Example: Defining a ClusterRole

Here's a ClusterRole that grants read access to all Pods in the cluster:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

ClusterRoleBinding

A ClusterRoleBinding associates a ClusterRole with a user, group, or service account at the cluster level. This binding gives the specified subjects the permissions defined in the ClusterRole across all namespaces.

Example: Creating a ClusterRoleBinding

Let's bind the cluster-pod-reader ClusterRole to a user named john:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-pods-cluster-wide
subjects:
- kind: User
  name: john
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-pod-reader
  apiGroup: rbac.authorization.k8s.io

Combining Roles and Bindings

RBAC in Kubernetes is powerful due to its flexibility in combining Roles, RoleBindings, ClusterRoles, and ClusterRoleBindings to achieve precise control over who can do what within the cluster. Here are a few more examples to illustrate different scenarios.

Example: Granting Admin Access to a Namespace

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: development
  name: admin
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: admin-binding
  namespace: development
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: admin
  apiGroup: rbac.authorization.k8s.io

Example: Granting Read-Only Access to All Namespaces

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: read-only
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-only-binding
subjects:
- kind: User
  name: bob
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: read-only
  apiGroup: rbac.authorization.k8s.io

What is a Service Account in Kubernetes?

A Service Account in Kubernetes is an identity used by processes running in pods to authenticate and interact with the Kubernetes API. Unlike regular user accounts meant for humans, Service Accounts are intended for system components, like pods, to perform actions on the cluster. When a pod needs to interact with the Kubernetes API—like listing resources, creating or modifying resources—it does so under the identity of a Service Account.

By default, when a pod is created, Kubernetes automatically assigns it a default Service Account from the same namespace unless specified otherwise. This Service Account allows the pod to authenticate and gain access to the cluster's resources according to the permissions granted to it.

Authentication in Kubernetes Service Accounts

Authentication in Kubernetes involves validating the identity of the entity (human user, pod, etc.) making a request to the API server. For Service Accounts, Kubernetes uses tokens that are automatically generated when the account is created.

Manually Creating a Long-Lived API Token for a Service Account

Sometimes, you might need a long-lived API token for a Service Account, especially for non-interactive processes or external systems that need to access the Kubernetes API. To manually create a long-lived token, follow these steps:

Create the Service Account:

 kubectl create serviceaccount <service-account-name>

Create a Secret to Hold the Token:

 apiVersion: v1
 kind: Secret
 metadata:
   name: <secret-name>
   annotations:
     kubernetes.io/service-account.name: "<service-account-name>"
 type: kubernetes.io/service-account-token

Associate the Secret with the Service Account: This step is usually handled automatically by Kubernetes, where it binds the token secret to the Service Account. You can verify this by describing the Service Account:
```
 kubectl describe serviceaccount <service-account-name>
```

Retrieve the Token: Finally, you can retrieve the token from the secret:

 kubectl get secret <secret-name> -o jsonpath='{.data.token}' | base64 --decode

This token can now be used to authenticate against the Kubernetes API.

Conclusion

Kubernetes RBAC is an essential feature for securing your cluster and managing permissions effectively. By understanding Roles, RoleBindings, ClusterRoles, and ClusterRoleBindings, you can precisely control access to resources within your cluster. Kubernetes Service Accounts are a crucial component in securing and managing workloads in a Kubernetes cluster. By understanding how to configure Service Accounts, manage their authentication, and control their permissions through roles and bindings, you can ensure that your Kubernetes environment remains secure and efficient.

Reference

https://www.youtube.com/watch?v=DswQe7shSa4&list=PLl4APkPHzsUUOkOv3i62UidrLmSB8DcGC&index=25

https://www.youtube.com/watch?v=k2iCq7IlMKM&list=PLl4APkPHzsUUOkOv3i62UidrLmSB8DcGC&index=26

https://www.youtube.com/watch?v=uGcDt7iNFkE&list=PLl4APkPHzsUUOkOv3i62UidrLmSB8DcGC&index=24

Day 23/24/25 of 40daysofkubernetes : Kubernetes RBAC Explained