RBAC in Kubernetes: Relevant Access Control Explained

Role-Based Access Control (RBAC) in Kubernetes is one of the most critical security concepts every DevOps engineer must master. It defines who can do what on which resource inside the cluster.

In simple terms: RBAC ensures the right people and workloads get the right level of access — nothing more, nothing less.

---

🔹 Types of Identities in RBAC

Kubernetes RBAC works with two types of identities:

1. Users

   • Human identities (developers, admins, DevOps engineers).

   • Kubernetes itself does not manage users directly. Instead, it offloads user management to external identity providers like:

     • AWS IAM (for EKS)

     • Google Identity / OIDC (for GKE)

     • Azure AD (for AKS)

     • LDAP, OKTA, KeyCloak, SSO providers

Example: In EKS, you can use your IAM user or IAM role mapped to Kubernetes RBAC.

2. Service Accounts

   • Machine identities inside Kubernetes.

   • Used by Pods, Deployments, or Controllers to talk to the Kubernetes API.

   • By default, every pod gets a default service account unless we explicitly attach another one.

---

🔹 Core RBAC Components

RBAC in Kubernetes can be broken down into three main building blocks:

1. Users / Service Accounts – Who is requesting access?

2. Roles / ClusterRoles – What actions are allowed?

3. RoleBindings / ClusterRoleBindings – How do we map users or service accounts to roles?

---

🔹 How RBAC Works in Practice

Let’s walk through a practical example.

1️⃣ Create a Service Account

This account will represent an application running in our cluster.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: default

Apply:

kubectl apply -f sa.yaml

---

2️⃣ Define a Role

Let’s say developers should only read Pods, ConfigMaps, and Secrets in the default namespace.

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

---

3️⃣ Bind the Role to the Service Account

Now we attach the dev-role to our my-app-sa service account using a RoleBinding.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-role-binding
  namespace: default
subjects:
- kind: ServiceAccount
  name: my-app-sa
  namespace: default
roleRef:
  kind: Role
  name: dev-role
  apiGroup: rbac.authorization.k8s.io

---

4️⃣ Test RBAC Permissions

Run a pod with this service account:

apiVersion: v1
kind: Pod
metadata:
  name: test-rbac
spec:
  serviceAccountName: my-app-sa
  containers:
  - name: curl
    image: curlimages/curl
    command: ["sleep", "3600"]

Exec into the pod:

kubectl exec -it test-rbac -- sh

Get token and test access:

TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)

# Allowed: list pods
curl -sSk -H "Authorization: Bearer $TOKEN" \
  https://kubernetes.default.svc/api/v1/namespaces/default/pods

# Not allowed: delete pod
curl -X DELETE -sSk -H "Authorization: Bearer $TOKEN" \
  https://kubernetes.default.svc/api/v1/namespaces/default/pods/test-rbac

👉 Result: The first command succeeds, the second fails. That’s RBAC in action!

---

🔹 Cluster Roles vs Namespace Roles

• Role → applies to a single namespace only.

• ClusterRole → applies across the entire cluster.

• Example: A monitoring tool like Prometheus may need a ClusterRole to read resources across all namespaces.

---

🔹 DevOps Engineer’s Perspective

As DevOps engineers, our primary responsibilities with RBAC are:

• Define who (users, teams, workloads) should access what (pods, secrets, configmaps).

• Map external users (via IAM, LDAP, SSO) into Kubernetes RBAC.

• Create and bind service accounts with least privilege for workloads.

• Audit and regularly review access policies to avoid privilege creep.

---

🔹 Key Takeaways

• Kubernetes doesn’t manage users itself — it relies on identity providers.

• Service Accounts are the native Kubernetes way of managing access for workloads.

• Access is granted via Roles (permissions) and Bindings (mappings).

• Always follow principle of least privilege to secure your cluster.

---

🚀 With this understanding and practical YAML examples, you can now design RBAC in your Kubernetes clusters (local KIND or cloud-managed) with confidence.