Kubernetes Security: RBAC, Network Policies, and Pod Security

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.

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.

Every pod in Kubernetes runs under a service account — an identity used for API authentication. By default, pods use the default service account in their namespace, which may have broad permissions. The principle of least privilege requires creating dedicated service accounts for each application with only the permissions it needs. Additionally, setting automountServiceAccountToken: false on pods that do not need API access prevents the service account token from being mounted into the pod filesystem, where a compromised application could use it to make API calls.

By default in Kubernetes, all pods can communicate with all other pods in any namespace. A compromised pod can immediately attempt to reach databases, internal APIs, and other microservices. Kubernetes NetworkPolicy resources define rules that restrict pod-to-pod traffic based on labels, namespaces, and ports. The recommended approach is a 'default deny all' network policy in each namespace, followed by explicit allow rules for required communication paths. Note that NetworkPolicy requires a CNI plugin that supports it (Calico, Cilium, Weave) — vanilla Kubernetes ignores NetworkPolicy without a compatible CNI.

Pod Security Standards (PSS), introduced in Kubernetes 1.23 and stable in 1.25, replace the deprecated Pod Security Policy (PSP) with three built-in profiles enforced at the namespace level: Privileged (unrestricted, for system components), Baseline (prevents known privilege escalations like privileged containers and host network access), and Restricted (hardened, requires non-root users, drops all capabilities, enforces read-only root filesystems). Namespaces are labeled to enforce a policy level, and pods that violate it are rejected at admission.

Kubernetes Secrets store sensitive data like passwords, tokens, and TLS certificates. By default, Secrets are stored in etcd as base64-encoded values — not encrypted. Anyone who can read etcd or has sufficient RBAC permissions can decode them trivially. Best practices include: enabling encryption at rest for etcd using AES-GCM with a key stored in a KMS (AWS KMS, GCP KMS), integrating with an external secrets manager like HashiCorp Vault or AWS Secrets Manager via the Secrets Store CSI Driver, and restricting Secret access via RBAC so only the service accounts that need them can read them.

Admission controllers are plugins in the Kubernetes API server that intercept API requests after authentication and authorization but before object persistence, allowing them to validate, mutate, or reject requests. Security-relevant admission controllers include: PodSecurity (enforces Pod Security Standards), ImagePolicyWebhook (allows external image signing verification), AlwaysPullImages (forces fresh image pulls to prevent using locally cached malicious images), and OPA/Gatekeeper (Open Policy Agent — the most flexible, allows custom policies expressed in Rego language to enforce any organizational security rule).

Hardening the Kubernetes control plane components is critical: the API server should have --anonymous-auth=false to disable unauthenticated access, --audit-log-path configured to capture all API activity, and TLS for all connections. The kubelet should have --authorization-mode=Webhook (not AlwaysAllow) and anonymous authentication disabled. etcd should have TLS peer and client encryption, restricted network access (only reachable by the API server), and encrypted data at rest. The CIS Kubernetes Benchmark provides a comprehensive checklist for all component settings.

Kubernetes namespaces provide logical separation of resources but are not a strong security boundary by themselves — they primarily provide organizational isolation. For true multi-tenant isolation (e.g., different customers' workloads), additional controls are required: network policies to block cross-namespace traffic, resource quotas to prevent noisy-neighbor DoS, separate node pools for strongly isolated tenants, or dedicated clusters per tenant. Many organizations use Hierarchical Namespaces or commercial solutions like vCluster for stronger multi-tenancy within a single cluster.

Kubernetes audit logging records every API request: who made it, from where, what action was requested, and what resource was targeted. Audit logs are essential for forensic investigation after a security incident and for detecting anomalous behavior like unusual role bindings, access to secrets, or exec commands into production pods. Audit logs should be streamed to a centralized SIEM. Falco provides runtime monitoring of container behavior, while cloud-managed Kubernetes services (EKS, GKE, AKS) provide native audit log integration with their respective logging platforms.

Supply chain security for Kubernetes ensures that only trusted, verified images reach production. The CNCF Supply Chain Security recommendations include: verifying image signatures with Cosign before deployment (enforced via admission controllers), generating and verifying SBOMs (Software Bills of Materials) for all container images to track component provenance, pinning images to digests (myimage@sha256:abc123) rather than mutable tags, and scanning all third-party Helm charts for misconfigurations and vulnerabilities before deployment.

Test your understanding of CompTIA Security+ (SY0-701) concepts from this lesson.

In this lesson you learned: Kubernetes RBAC controls API access through Roles, ClusterRoles, and Bindings — always apply least privilege to service accounts, NetworkPolicy default-deny configurations prevent lateral movement between pods and namespaces, and Pod Security Standards enforce container hardening at the namespace level, blocking privileged containers, host network access, and root execution. Next up we explore serverless security and function-level attack surfaces.