RBAC & Security

Kubernetes Intermediate/Advanced

Chapter 4 · RBAC & Security

This chapter closes two loops left open earlier in this course: k8s1-7's promise that "who can read Secret objects at all" would be covered properly here, and k8s1-10's brief mention of per-namespace access control. It also revisits cloud1-6's IAM material — from Cloud Platforms — now applied specifically inside a Kubernetes cluster.

Why Kubernetes Needs Its Own Access Control

Revisiting cloud1-6's AuthN-vs-AuthZ split directly: getting into a cluster (authentication — typically via the cloud provider's own IAM feeding into k8s1-4's kubeconfig) is a different question from what you're allowed to do once you're in (authorization). Kubernetes' own RBAC (Role-Based Access Control) system handles authorization specifically, entirely separate from whatever authentication mechanism sits in front of it.

The Building Blocks — Roles, ClusterRoles, RoleBindings, ClusterRoleBindings

Role — a set of permissions (verbs like get/list/create/delete on specific resource types), scoped to one namespace (k8s1-10's namespace material).
ClusterRole — the same idea, but cluster-scoped — for cluster-scoped resources (k8s1-10's own Nodes example) or reused across multiple namespaces.
RoleBinding — grants a Role's permissions to a specific user/group/ServiceAccount, within one namespace.
ClusterRoleBinding — grants cluster-wide.

Genuinely important to be careful about: a Role/RoleBinding pair is namespace-scoped even if a Role with the exact same name exists in another namespace — they're completely separate objects.

ServiceAccounts — Identity for Pods, Not People

Humans authenticate via the cluster's own auth mechanism, often tied to cloud provider IAM. But pods and applications sometimes need their own identity to interact with the Kubernetes API directly — a controller or operator that needs to list/watch other resources, for instance. A ServiceAccount is exactly this: an identity for a pod or process, not a person.

Every pod gets a default ServiceAccount automatically

An easy-to-overlook default with real security implications: if none is specified, a pod is automatically assigned the namespace's default ServiceAccount. It typically has minimal but non-zero permissions — worth being deliberate about rather than assuming it's harmless.

A Concrete RBAC Example, Explained

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: shop-app
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: monitoring-can-read-pods
  namespace: shop-app
subjects:
  - kind: ServiceAccount
    name: monitoring-sa
roleRef:
  kind: Role
  name: pod-reader

A read-only Role, a ServiceAccount for a monitoring tool, and a RoleBinding connecting them — exactly the kind of setup k8s2-2's own log-agent/monitoring DaemonSet example would genuinely need to query the Kubernetes API for pod information.

The Principle of Least Privilege, Applied to Kubernetes

Directly reusing dbsec1-3/cloud1-6's least-privilege material: never grant cluster-admin or broad wildcard permissions ("*" on "*") when a narrowly-scoped Role would do.

"cluster-admin for now, we'll tighten it later" — a real, common anti-pattern

Granting every ServiceAccount cluster-admin during development, to avoid dealing with permissions while iterating, then never actually tightening it before production — exactly the same anti-pattern cloud1-6 flagged for cloud IAM, recurring here at the Kubernetes RBAC layer.

Closing the Loop on Chapter 1-7's Secrets Warning

k8s1-7 stated plainly that Secrets are only base64-encoded, not encrypted, and that "RBAC restricting who can read Secret objects at all" was part of the real protection — deferred to this chapter. Concretely: a Role can specifically restrict get/list access on Secret resources. Even though a Secret's value is trivially decodable once retrieved, properly scoped RBAC ensures far fewer identities can actually retrieve and decode it in the first place — closing that loop directly.

Pod Security Standards, Briefly

A different, complementary layer: Pod Security Standards (replacing the older, now-removed PodSecurityPolicy) define baseline security postures a pod's own spec must comply with — disallowing running as root, disallowing privileged containers — enforced at the namespace level via labels.

Genuinely distinct from RBAC: RBAC controls who can create or modify resources. Pod Security Standards control what a pod is allowed to actually configure or run as, regardless of who created it — two complementary layers worth not conflating.

Hands-On Exercises

Exercise 1

Explain the difference between a Role and a ClusterRole, and between a RoleBinding and a ClusterRoleBinding — specifically regarding scope.

📄 View solution

Exercise 2

Explain what a ServiceAccount is for, and why an application/pod needs one distinct from a human user's own cluster credentials.

📄 View solution

Exercise 3

Explain how properly scoped RBAC closes the security gap left open by Chapter 1-7's "Secrets are only base64-encoded, not encrypted" warning. What specifically does RBAC restrict that base64 encoding alone doesn't?

📄 View solution

Chapter 4 Quick Reference

Authentication (getting in) vs. RBAC/authorization (what you can do) — the same split as cloud1-6, now inside Kubernetes itself
Role/RoleBinding — namespace-scoped; ClusterRole/ClusterRoleBinding — cluster-wide
ServiceAccount — identity for pods, not people; every pod gets a default one automatically, worth being deliberate about
Never grant cluster-admin as a permanent "development shortcut" — the same anti-pattern as broad cloud IAM policies
Scoped RBAC on Secrets restricts who can even retrieve a Secret — the missing piece base64 encoding alone never provided
Pod Security Standards — complementary to RBAC; controls what a pod is allowed to run as, not who can create it
Next chapter: Networking Deep Dive — CNI plugins, Network Policies, a service mesh overview