Kubernetes Security: RBAC, Network Policies, and Pod Security
Configure Kubernetes RBAC roles, enforce network policies that restrict pod-to-pod traffic, and apply pod security standards to limit privilege escalation.
Kubernetes Attack Surface Overview
Kubernetes orchestrates containerized workloads at scale, but its complexity creates a rich attack surface. Key components that must be secured include: the API Server (the central control plane — compromise here gives control of the entire cluster), etcd (the cluster state database — stores secrets in base64, must be encrypted at rest), kubelet (node agent — unauthenticated kubelet API allows arbitrary pod execution), container runtime (Docker/containerd), and the network fabric connecting all pods. Security+ candidates should understand that Kubernetes misconfigurations are among the most common cloud security findings.
RBAC: Role-Based Access Control in Kubernetes
Kubernetes RBAC (Role-Based Access Control) controls which users, service accounts, and processes can perform which actions on which API resources. The model has four objects: Role (namespaced permissions), ClusterRole (cluster-wide permissions), RoleBinding (grants a Role to a subject within a namespace), and ClusterRoleBinding (grants a ClusterRole to a subject cluster-wide). Every kubectl command translates to an API call checked against RBAC rules. If RBAC is not configured, any authenticated user (or service account) may have administrative access.
# Create a role allowing only pod reads in 'default' namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: pod-reader
namespace: default
rules:
- apiGroups: ['']
resources: ['pods']
verbs: ['get', 'list', 'watch']All lessons in this course
- Container Security: Image Hardening and Runtime Protection
- Kubernetes Security: RBAC, Network Policies, and Pod Security
- Serverless and Function Security
- Infrastructure as Code Security Scanning