Lesson 4: RBAC & Security Basics

1. RBAC — Role-Based Access Control

RBAC controls who can do what in the cluster. It answers: "Can user X perform action Y on resource Z?"

RBAC Model:
  WHO (Subject)     +     WHAT (Role)         =    HOW (Binding)
  ─────────────           ──────────                ─────────────
  User                    Role (namespace)          RoleBinding (namespace)
  Group                   ClusterRole (cluster)     ClusterRoleBinding (cluster)
  ServiceAccount

Component	Scope	Defines
Role	Namespace	Permissions within a single namespace
ClusterRole	Cluster	Permissions for the entire cluster or all namespaces
RoleBinding	Namespace	Assigns a Role to a Subject in a specific namespace
ClusterRoleBinding	Cluster	Assigns a ClusterRole to a Subject across the entire cluster

Exam tip: KCNA questions often test: "Which resource do you use for cluster-wide permission?" → ClusterRole + ClusterRoleBinding. "Which for a single namespace?" → Role + RoleBinding.

2. ServiceAccounts

ServiceAccount is an identity used by Pods to interact with the Kubernetes API. Each namespace has a default ServiceAccount.

Feature	ServiceAccount	User account
Who uses it	Pods, controllers, apps	Humans (admin, developer)
Created by	kubectl / API	External provider (OIDC, LDAP)
Kubernetes manages	Yes	No
Mounted as	Token in Pod	kubeconfig

3. NetworkPolicy

NetworkPolicy controls network traffic between Pods. Default: all traffic is allowed. After a NetworkPolicy is applied, only traffic matching the rules is permitted (whitelist model).

NetworkPolicy Example:
  Namespace: production
  ┌────────────────────────────────────┐
  │  frontend Pods ──► backend Pods   │ ✓ Allowed (rule exists)
  │  random Pods   ──► backend Pods   │ ✗ Denied  (no matching rule)
  │  backend Pods  ──► database Pods  │ ✓ Allowed (rule exists)
  └────────────────────────────────────┘

Exam tip: NetworkPolicy requires a CNI plugin that supports it (Calico, Cilium). The default kubenet plugin does NOT support NetworkPolicy — creating the resource has no effect without proper CNI!

4. Pod Security Standards (PSS)

Pod Security Standards define 3 policy levels for Pod security, replacing the deprecated PodSecurityPolicy (PSP).

Level	Restrictions	Use case
Privileged	No restrictions	System-level workloads (kube-system)
Baseline	Prevents known privilege escalation	Standard application workloads
Restricted	Strictest, follows Pod hardening best practices	High-security workloads

5. SecurityContext

Setting	Function
runAsNonRoot: true	Prevents running as root
readOnlyRootFilesystem: true	Makes the root filesystem read-only
allowPrivilegeEscalation: false	No process can gain more privileges than its parent
runAsUser: 1000	Container runs as user UID 1000
capabilities.drop: ["ALL"]	Removes all Linux capabilities

6. Cheat Sheet

Exam question	Answer
Namespace-scoped permissions?	Role + RoleBinding
Cluster-wide permissions?	ClusterRole + ClusterRoleBinding
Identity for Pods accessing API?	ServiceAccount
Control Pod-to-Pod traffic?	NetworkPolicy
Replace deprecated PodSecurityPolicy?	Pod Security Standards (PSS)
NetworkPolicy requires?	CNI supporting it (Calico, Cilium)

7. Practice Questions

Q1: A team wants to grant a developer read-only access to Pods in the 'staging' namespace only. Which RBAC resources should they create?

• A) ClusterRole + ClusterRoleBinding
• B) Role + RoleBinding ✓
• C) ClusterRole + RoleBinding
• D) ServiceAccount + Secret

Explanation: Since the permission scope is a single namespace ('staging'), use Role (to define pod read permissions in that namespace) + RoleBinding (to assign the Role to the user in that namespace).

Q2: By default, what happens when you create a NetworkPolicy that selects certain Pods?

• A) All traffic is blocked for all Pods in the namespace
• B) Only traffic matching the policy rules is allowed to the selected Pods ✓
• C) The policy has no effect until the cluster is restarted
• D) All outbound traffic from selected Pods is blocked

Explanation: When a NetworkPolicy selects Pods, those Pods switch to a whitelist model — only explicitly allowed ingress/egress is permitted. Pods not selected by any policy remain unrestricted (allow all).

Q3: Which Pod Security Standard level should be applied to general application workloads that don't need special privileges?

• A) Privileged
• B) Baseline ✓
• C) Restricted
• D) Default

Explanation: Baseline prevents known privilege escalation (no hostNetwork, no privileged containers, no hostPID/IPC) while remaining permissive enough for most applications. Restricted is stricter (required for high-security environments), and Privileged has no restrictions.