Security: Defense in Depth

Kubernetes doesn't have one security boundary — it has a stack of independent controls, and each one is structurally blind to almost everything the others check. A scanner has no idea what RBAC will later allow. RBAC has no idea whether the object it just authorized is actually safe to run. A NetworkPolicy has no idea a Pod's own code has already been compromised — it only cares where that Pod tries to go next. And nothing before this page's last layer knows a container is doing something it has never done before; catching that is its job alone. This page is the map: what runs before a workload ever reaches the cluster, what the cluster's own write-time gate checks — RBAC and admission control, already covered in full in RBAC & Admission Control — what keeps watching after that gate is finished, and how one real credential, a Secret, has to survive every layer without ever being the thing that breaks it. None of this is CKA-scoped; most of it is exactly what CKS exists to test.

Before the cluster: what shouldn't even reach the registry

☺ Like you're 10: Nobody wants to open the box marked "bad" — much better if it never gets shipped to the door in the first place.

The cheapest security fix is the one that never has to run in production, and that's the entire premise of the supply-chain layer. It starts with what's in the image: a minimal or distroless base with no shell and no package manager gives an attacker who does achieve code execution nowhere to pivot from — there's no /bin/sh to reach for, a pattern DevOps' immutable infrastructure & golden images covers from the build-pipeline side. From there, a scanner like Trivy checks every layer of the built image against known-CVE databases before it's ever pushed, an SBOM records exactly what's inside so a future disclosure is a minutes-long query instead of a days-long audit, and Sigstore & cosign signs the resulting artifact — keylessly, via OIDC identity, with the signature recorded in a public transparency log — so the cluster can later verify not just what it's about to run but that it came from the pipeline it claims to have come from. DevSecOps' Container & supply-chain security is the full treatment of this layer on its own; this page's job is only to place it correctly in the stack.

# A build pipeline's supply-chain gate, in order
trivy image --severity HIGH,CRITICAL --exit-code 1 registry.example.com/checkout:sha-9f1c2a

# Sign only after the scan passes — an unsigned image never reaches the cluster's allow-list
cosign sign --yes registry.example.com/checkout@sha256:9f1c2a...

# Later, at admission time (see the next section), a policy verifies this exact signature
cosign verify --certificate-identity-regexp "https://github.com/example-org/checkout/.*" \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  registry.example.com/checkout@sha256:9f1c2a...

Write-time: RBAC decides who, admission decides what

☺ Like you're 10: Two separate checks at the same door — first your wristband color, then, no matter the color, someone still looks at exactly what you're carrying.

Once an image clears layer one, the cluster's own write-time gate takes over, and this course already gives it a full page: RBAC & Admission Control covers the request pipeline in precise order, aggregated ClusterRoles, the escalate/bind/impersonate verbs, bound ServiceAccount tokens, the built-in admission plugins, the mutating-then-validating webhook chain, and Pod Security Admission in full — read it for the mechanics. What that page doesn't spend time on, because it's a supply-chain concern rather than an admission-mechanics one, is the one control that ties layer one and layer two together directly: image-signature verification at admission. A policy engine like Kyverno or OPA Gatekeeper can run verifyImages-style rules as a validating admission policy — rejecting any Deployment whose image isn't signed by a trusted identity, the same signature cosign sign produced back in layer one. Without this check, signing is only ever advisory; an unsigned or wrong-signer image is still perfectly free to get scheduled, because nothing at write-time was ever asked to look.

# A Kyverno ClusterPolicy enforcing layer one's signature at layer two's gate
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-signed-images
spec:
  validationFailureAction: Enforce
  rules:
  - name: verify-checkout-signature
    match:
      any:
      - resources: { kinds: ["Pod"] }
    verifyImages:
    - imageReferences: ["registry.example.com/checkout:*"]
      attestors:
      - entries:
        - keyless:
            subject: "https://github.com/example-org/checkout/.*"
            issuer: "https://token.actions.githubusercontent.com"

Pod Security Admission — the floor every namespace enforces whether you configured anything or not — is the other half of this layer, and it's covered in full on the RBAC page. The one thing worth restating here: PSA checks the shape of a Pod spec (root user, host mounts, capabilities), never the behavior of the code running inside it. A Pod can be perfectly restricted-compliant and still be running an application with a live remote-code-execution bug — which is exactly why write-time is only half the stack.

Continuous: NetworkPolicy decides where, runtime detection decides what happens next

☺ Like you're 10: The write-time gate only ever looks once, at the door. These two keep looking, for as long as the thing is actually inside.

Admission is the last check that ever inspects the object as submitted — the moment it's persisted to etcd and scheduled, admission is finished and never looks again. Everything from here on is watching a Pod that's already running. NetworkPolicy, the layer that decides where a Pod is allowed to talk, gets a full mechanical treatment — including the trap that a policy silently does nothing on a CNI that doesn't enforce it — in Networking & the CNI; the short version here is that a default-deny policy scoped tightly to a workload's actual dependencies is what turns "attacker got a shell in one Pod" into "attacker got a shell in one Pod that can reach exactly the two things it was already allowed to reach."

The layer nothing else on this page covers is runtime detection, and it exists because every control above it shares one blind spot: none of them can see what a container's process tree actually does after it starts. A tool like Falco — a CNCF-graduated engine built on eBPF — attaches at the kernel syscall level and evaluates live behavior against a ruleset: a shell spawning inside a container image that has never spawned one, a process reading /etc/shadow, an outbound connection from a Pod that has no business making one. Where a NetworkPolicy only ever answers "is this connection allowed," Falco can answer "did something inside this Pod just start behaving like nothing that Pod's own code has ever done" — a structurally different question, answerable only from inside the running container, which is why it's this page's fifth and final layer rather than a restatement of the fourth. DevSecOps' Container runtime security is the deep mechanical treatment — eBPF probes, the default ruleset, and routing alerts to a SIEM instead of a log file nobody reads.

# A Falco rule: alert the instant a shell appears inside a container
# that has no legitimate reason to ever spawn one.
- rule: Unexpected Shell in Payments Container
  desc: A shell was spawned inside a container in the payments namespace
  condition: >
    spawned_process
    and container
    and k8s.ns.name = "payments"
    and proc.name in (bash, sh, zsh)
    and not proc.pname in (entrypoint.sh, healthcheck.sh)
  output: >
    Shell spawned in payments container
    (user=%user.name container=%container.name image=%container.image.repository
    parent=%proc.pname cmdline=%proc.cmdline)
  priority: CRITICAL
  tags: [container, shell, mitre_execution]

Secrets: the one thing every layer has to protect, and none of them fully can

☺ Like you're 10: A secret has to survive walking through all five checkpoints without a single one of them accidentally leaving it lying on the counter.

A Kubernetes Secret is base64-encoded, not encrypted — anyone who can kubectl get secret -o yaml it can decode it in one command, which is exactly why layer two's RBAC gating get/list on secrets is doing real work here, not a formality. What Kubernetes stores at rest is whatever etcd holds, and by default that's the same unencrypted base64 — real encryption at rest requires an explicit EncryptionConfiguration on kube-apiserver, ideally backed by a KMS provider rather than a static key file sitting on a control-plane node. How that mounts into a Pod matters too: a Secret projected as a volume file lives only in an in-memory tmpfs and never shows up in a process listing or a crash dump the way an environment variable does, which is why envFrom: secretRef is the pattern worth defaulting away from, not toward. And a growing number of teams skip persisting the real credential in etcd — or in a Git repo it was templated from — entirely, using something like External Secrets & the secrets patterns to sync from Vault or a cloud secrets manager at the last possible moment, with the manager doing rotation instead of a human remembering to. DevSecOps' Secrets management covers the leak-scanning and rotation-policy side of this, and Cryptography & key management covers what "encrypted" is actually claiming underneath a KMS call. The thread that connects all five layers, restated: a secret should never be baked into layer one's image, should never be readable without layer two's explicit grant, should never leave etcd unencrypted under layer three's watch, should never be worth exfiltrating past layer four's policy, and its access pattern is exactly the kind of thing layer five should be watching for anomalies in.

This page is the map; three of its five layers already have a full page of their own elsewhere. RBAC & Admission Control is the write-time gate in full mechanical detail, Networking & the CNI covers exactly how (and how not) NetworkPolicy gets enforced, and cross-course, DevSecOps' own Kubernetes security deep dive covers the same write-time-versus-continuous split from the security-team side of the table, alongside Container runtime security for eBPF mechanics past what fits on this page. None of it is CKA-scoped. If this is the direction you're headed, the CKS blueprint is the specialist certification built entirely around this stack, the associate-level KCSA blueprint is the on-ramp to it, Platform Engineering's Security & Policy Enforcement covers the same territory from a CNPE angle, and the wider CNCF security-track ladder beyond CKS lives on the sibling Golden Astronaut course.