Skip to main content
Welcome to the final domain: Security and Policy Enforcement. This module turns everything you’ve built into a platform that is secure by default. Read on to learn the Kubernetes threat model, a practical defense-in-depth strategy, and how each security layer maps to specific tools and controls. Subsequent lessons will build on these foundations.
The image lists five learning objectives related to Kubernetes security, focusing on security challenges, threat models, defense strategies, and exam security domains.
Why this matters — a real-world scenario Imagine a fintech startup operating a shared Kubernetes cluster for six teams. One team installs a debugging tool that runs as cluster-admin and exposes a web shell via a NodePort. An attacker discovers that endpoint, escalates to cluster-admin, and enumerates secrets across namespaces—database credentials, API keys, payment processor tokens.
Exposed debugging tools, excessive privileges like cluster-admin, and publicly reachable NodePorts are a common attack chain. Treat any privileged tooling as high-risk and restrict network exposure.
The image illustrates the risk of shared platforms, showing a person with a laptop gaining access through a debugging tool and a NodePort web shell, with cluster-admin access and secret enumeration across namespaces.
The financial and regulatory impact can be severe: incident response costs, lost revenue, and compliance fines. The root cause is rarely a single misstep; it’s a chain of failures:
  • Improper RBAC: teams can create cluster role bindings or use cluster-admin.
  • Missing admission controls: privileged containers and unsafe specs are allowed.
  • No network isolation: sensitive endpoints are reachable from outside.
  • No image scanning: known CVEs and malicious artifacts are deployed.
The image outlines four root causes related to shared platforms and amplified risk: no RBAC restrictions, no admission control, no network policies, and no image scanning.
What makes Kubernetes uniquely challenging to secure?
  • Multi-tenancy by design: misconfigurations in one namespace can affect others.
  • A powerful API server: it can create pods, mount secrets, and perform cluster-wide actions.
  • Flat default network: pods can reach each other unless isolation is applied.
  • Public images and supply chain risk: base images or charts can contain vulnerabilities or backdoors.
The image outlines the risks associated with shared platforms, highlighting features like multi-tenancy, powerful API surfaces, flat network structure, and software supply chain vulnerabilities.
As a platform engineer your goal is simple: make the secure path the easy path. That means enforcing platform-level defaults, applying least privilege everywhere, and building layered defenses that don’t rely on perfect human behavior. Understand the attackers Common threat vectors you must defend against:
  • External attackers: scanning for exposed services, leaked kubeconfig files, or unauthenticated dashboards.
  • Insider or misconfiguration misuse: overly-permissioned users or automation making destructive mistakes.
  • Supply chain attacks: vulnerable base images, malicious Helm charts, or unsigned artifacts.
  • Lateral movement: compromised pods using service account tokens to enumerate secrets and pivot.
The image outlines the Kubernetes Threat Model, detailing four threat categories: External Attacker, Insider/Misconfigured, Supply Chain Attack, and Lateral Movement. Each category includes examples, such as public dashboard vulnerabilities and misuse of permissions.
Map threats to layered controls (defense in depth) Defense in depth means overlapping controls so a single failed control doesn’t lead to catastrophe. A practical Kubernetes stack typically includes:
  • Role-Based Access Control (RBAC): define who can do what.
  • Admission controllers and webhooks: validate and mutate resources before creation.
  • Pod Security Standards (PSS): enforce safe runtime profiles (no privileged containers, limited capabilities).
  • Network Policies: control pod-to-pod and external traffic.
  • Service mesh with mTLS: encrypt traffic and enforce service identity.
  • Supply chain security: image scanning, signing, and provenance verification.
The image illustrates "Defense in Depth: Six Security Layers," which include RBAC, Admission Control, Pod Security, Network Policy, Service Mesh, and Supply Chain Security, each with a brief description.
Defense in depth reduces single points of failure. Apply platform-wide defaults so teams inherit secure settings automatically, and require explicit exceptions for risky actions.
How these layers connect — follow a request
  1. A user authenticates to the API server (OIDC, client certs, etc.).
  2. RBAC evaluates whether the user can create a Deployment in the namespace.
  3. Admission webhooks validate or mutate the Deployment/Pod spec against policy.
  4. Pod Security Standards enforce runtime constraints before the pod is scheduled.
  5. If scheduled, Network Policies determine which peers the pod can reach.
  6. A service mesh enforces mTLS to encrypt communication and verify service identities.
The image depicts a flowchart illustrating how layers work together in a Kubernetes setup, covering user authentication, RBAC checks, pod security, network policy, and traffic encryption. Each step has a brief description of its function in the process.
That’s six checkpoints before a workload is running and communicating—so even if one control fails, others remain to contain impact. Threat vectors vs. recommended controls Recommended links and references Summary
  • Shared platforms amplify risk; one weak workload can impact all tenants.
  • The Kubernetes threat model includes external attackers, insider mistakes, supply chain compromise, and lateral movement.
  • Defense in depth—RBAC, admission control, PSS, Network Policies, service mesh, and supply chain controls—reduces single points of failure.
  • Make the secure choice the default: platform-level enforcement, least privilege, and automated checks before runtime.
By the end of this module you should be able to identify likely attack chains, pick the right controls for each risk, and implement platform defaults that protect teams without blocking productivity.

Watch Video