Kubernetes Security

Kubernetes security has a reputation for sprawl, and it's earned: identity, admission, workload hardening, secrets, network segmentation, and audit all live in different APIs. But the sprawl organizes cleanly once you see the structure — a request path to defend, a workload posture to harden, and layers around both. A cluster is not secure by default; it is securable, and the difference is a series of deliberate decisions this course maps.

The framing the ecosystem uses is the 4C's of cloud native security: Cloud, Cluster, Container, Code. Each layer builds on the one outside it — a hardened cluster on a compromised cloud account is not hardened, and perfect application code inside a privileged container is not protected. Kubernetes security work is mostly the middle two C's, with sharp boundaries to what must be handled elsewhere.

Defending the front door: API access

Everything in Kubernetes goes through the API server, so controlling API access is the single highest-leverage security surface. Every request passes three gates in order: authentication (who are you — client certificates, bearer tokens, OIDC; there is no built-in user database for humans), authorization (may you do this — RBAC in practice), and admission control (should this object be allowed or modified — policy enforcement on writes). TLS protects the transport throughout.

RBAC (role-based access control) is where most authorization work happens: Roles (namespaced) and ClusterRoles (cluster-wide) bundle permissions as verbs on resources; RoleBindings and ClusterRoleBindings grant them to users, groups, or service accounts. RBAC is deny-by-default and purely additive — there are no deny rules, which keeps reasoning tractable. The standing advice is least privilege: prefer namespaced Roles, avoid wildcard verbs, and treat cluster-admin bindings as incidents waiting to be scheduled.

Workloads have identity too: every Pod runs as a ServiceAccount, whose short-lived, automatically projected tokens authenticate in-cluster API calls. The default service account in each namespace should stay unprivileged — and Pods that don't need the API shouldn't mount tokens at all.

Hardening workloads

The second surface is what your Pods are allowed to be. A container is a process on a shared kernel; the securityContext controls how much of that kernel it can reach: run as non-root, drop Linux capabilities, forbid privilege escalation, mount the root filesystem read-only, use seccomp profiles. Privileged containers and hostPath/hostNetwork access effectively erase the container boundary — they are node access with extra steps.

Rather than auditing every Pod by hand, the Pod Security Standards define three cumulative profiles — Privileged (unrestricted), Baseline (blocks known privilege escalations), and Restricted (current hardening best practice) — and Pod Security Admission, built into the API server, enforces them per namespace in three modes: enforce, audit, and warn. (The old PodSecurityPolicy API was removed in v1.25; PSA plus policy engines replaced it.) For anything PSA can't express — custom rules, mutation, image provenance — validating admission policies and external engines like OPA/Gatekeeper or Kyverno fill the gap.

Secrets, network, and audit

Secrets hold sensitive configuration separately from images and Pod specs — but a Secret is base64-encoded, not encrypted, and etcd stores it in plaintext unless you enable encryption at rest. Anyone who can read Secrets in a namespace, or create a Pod that mounts them, effectively owns them; RBAC around Secrets deserves its own review. For higher assurance, external secret stores (cloud KMS, Vault) integrate via CSI drivers and operators.

NetworkPolicy (covered in depth in the networking course) is the segmentation layer — default-deny plus explicit allows is the posture. Audit logging records who did what to the API and when: the forensic backbone, and one of the first things to configure on any cluster that matters.

Who owns what

Security responsibilities split across roles: cloud/platform teams own the outer layers (account security, node images, control plane configuration — largely the provider's job on managed clusters), platform engineers own admission policy, RBAC design, and secrets infrastructure, and application teams own workload posture (securityContext, images, dependencies). The 4C model doubles as an ownership map — most real-world gaps happen at the handoffs.

Limits and honest caveats

Kubernetes gives you strong mechanisms and no default posture: namespaces don't isolate network traffic by themselves, Secrets aren't encrypted until you make them so, and any workload is one privileged: true away from the node. Containers share a kernel — for hostile multi-tenancy, you need stronger isolation (separate node pools, sandboxed runtimes via RuntimeClass, or separate clusters). And no cluster configuration compensates for a compromised supply chain: image scanning, provenance, and dependency hygiene are code-layer work that Kubernetes can enforce but not perform.