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.
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 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.
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.
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.
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.
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.
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