The full cloud-native security stack — from the API server front door to the AI agent fleet — and how each layer becomes an enforceable, evidence-producing control. Built as a refresher for security & GRC engineers: every concept has a hands-on demo, the dense technical detail, and the compliance mapping.
Everything in Kubernetes passes through a handful of programmable choke points: the API server, admission, the network fabric, the credential issuer. Security and compliance live at those points as running code that produces its own evidence. Tap any card or tile to open its deep-dive.
Every change to the cluster — human or machine — is an API request through authentication, authorization (RBAC), and admission. Own those three gates and you own the preventive control plane.
Non-human identities — service accounts, workloads, CI jobs, AI agents — outnumber humans roughly 45:1 in cloud environments. Most real incidents are credential incidents. Who holds what, for how long, verified how?
Every concept above has its own tab with an interactive demo and the dense technical card. 11 tabs, one self-contained page — works offline, light and dark.
Kubernetes security is layered: Cloud → Cluster → Container → Code. The classic escalation is a compromised container that steals its ServiceAccount token, talks to the API server, and walks away with the secrets of the whole cluster. Whether that path completes depends entirely on which layers you hardened.
An attacker has code execution inside one container (a dependency exploit, say). Switch the cluster posture and watch how far the attack path gets before a layer stops it.
The technical detail. The API server is the single front door: every actor — kubectl, controllers, kubelets, operators — mutates the cluster through it, which is why authentication, RBAC and admission (the next two tabs) are the preventive control plane. etcd is the crown jewels: it holds the entire cluster state including every Secret, so read access to etcd (or to an unencrypted etcd backup) is equivalent to cluster admin — it must be isolated, mTLS-only, and encrypted at rest. Other classic surfaces: the kubelet API (10250/tcp — require authn/z, never anonymous), the cloud metadata service (steal node credentials from a pod — enforce IMDSv2 / block via egress policy), and hostPath mounts or privileged pods that turn a container into the node.
Version hygiene is itself a control: upstream supports roughly the last three minor releases — v1.36 is current (v1.36.2, June 2026) with v1.37 due August 26, 2026 — so a cluster more than ~3 minors behind is unpatchable, which auditors read as a CM-2/CM-6 configuration-management failure. Interview lens: layered defense maps cleanly to control families — each hop in the demo above is a different framework control, which is why scoping a cluster audit starts with this diagram.
Kubernetes has no user database: identity arrives from x509 client certificates, OIDC tokens, or ServiceAccount tokens. Authorization is then RBAC: verbs (get, list, watch, create, update, patch, delete) on resources, granted by Roles and ClusterRoles, attached by bindings. The binding you choose IS the blast radius of a stolen credential.
A CI pipeline needs to deploy an app to the prod namespace. Its token leaks in a build log (it happens constantly). Switch the binding it was given and watch what the attacker now holds.
The technical detail. RBAC objects: Role (namespaced) and ClusterRole (cluster-wide), attached via RoleBinding / ClusterRoleBinding; ClusterRoles can be aggregated via label selectors. The dangerous grants auditors hunt for: wildcards (verbs: ["*"], resources: ["*"]), the escalate and bind verbs (grant roles above your own), impersonate (become another user), and create pods in a namespace with powerful ServiceAccounts (mount the SA, inherit its power). One special case outranks them all: the system:masters group in a client certificate bypasses RBAC entirely and cannot be revoked short of rotating the CA — it should never be issued for humans.
Tooling for reviews: kubectl auth can-i --list --as=<subject>, SelfSubjectAccessReview, and graph tools that answer “who can read Secrets in prod?” — the cluster-native version of an access review. Interview lens: periodic access reviews (SOC 2 CC6.1–6.3, NIST AC-2/AC-6) only scale when the review is a query, not a spreadsheet — the same principle as auditing 3,000+ repos for external access with automation instead of eyeballs.
After authentication and RBAC, every write passes the admission chain: mutating admission (defaults get injected) then validating admission (rules get enforced). This is the preventive gate: a rule enforced at admission cannot be violated by anything that exists in the cluster. Pod Security Admission is the built-in floor; policy engines and CEL policies build the rest.
A developer submits a pod with privileged: true, a hostPath mount of /, and a root user — effectively “give me the node.” Switch the namespace enforcement level and watch whether the API server lets it exist.
The technical detail. PodSecurityPolicy was removed in v1.25 and replaced by Pod Security Admission (stable since 1.25): namespace labels select one of three Pod Security Standards profiles — privileged (no restrictions), baseline (blocks known escalations: privileged containers, hostPath, hostNetwork, added capabilities), restricted (hardened: runAsNonRoot, seccompProfile: RuntimeDefault, drop ALL capabilities, no privilege escalation) — in one of three modes: enforce, audit, warn. Roll out safely by running audit/warn first, then flipping enforce.
Beyond the built-in floor: Kyverno (policies written as YAML/CEL; CNCF graduated March 2026; LinkedIn runs it at 20,000+ admission requests/minute across 230+ clusters) and OPA Gatekeeper (Rego constraint templates; v3.22, March 2026) add mutation, generation, and image-verification policies. And the webhook tax is disappearing into the API server itself: ValidatingAdmissionPolicy (CEL, GA v1.30) and MutatingAdmissionPolicy (GA v1.36, April 2026) evaluate policy in-process — no webhook server to run, no availability trade-off on the critical path.
Interview lens: for a GRC engineer this tab is gold — an enforced admission policy is a preventive control whose evidence is the policy object itself plus its enforcement mode, both queryable from the API. No screenshots, no attestation emails: the same one-control-one-query pattern extends to supply-chain verification and Compliance-as-Code.
The non-human identity problem in one line: things need to prove who they are to other things, and the lazy answer — a long-lived API key in an environment variable — is the root cause of a huge share of real breaches. The cloud-native answer: identities that are issued after attestation, scoped to an audience, short-lived, and rotated automatically.
A payments service must authenticate to an internal API. Switch the credential model and watch what an attacker gets if the credential leaks — the only scenario that matters.
The technical detail. Kubernetes-native: since v1.21+ ServiceAccounts use bound tokens from the TokenRequest API — projected into the pod, audience-bound, time-limited, invalidated when the pod dies; the old never-expiring Secret-based tokens stopped being auto-created in v1.24. Bound tokens also federate outward: the cluster is an OIDC issuer, so cloud IAM can trust it directly (AWS IRSA / EKS Pod Identity, GKE Workload Identity, Azure Workload Identity) — workloads get cloud permissions with zero stored cloud keys.
SPIFFE/SPIRE (CNCF graduated 2022) generalizes this beyond one cluster: a workload gets a spiffe://trust-domain/workload identity as an SVID (short-lived X.509 cert or JWT) only after the SPIRE agent attests it (node identity + selectors like namespace, ServiceAccount, binary hash). Rotation is automatic and fast; there is nothing worth stealing at rest. This is the substrate for universal mTLS and the workload-identity layer the AIMS IETF draft (March 2026) composes with WIMSE and OAuth 2.0 for AI agent identity.
Interview lens: credential lifecycle is a compliance object (NIST IA-5, SOC 2 CC6.1). Short-lived attested identity dissolves the worst audit questions — “show me rotation evidence” becomes “the credential cannot outlive the rotation window by construction.”
A Kubernetes Secret is stored in etcd base64-encoded and, by default, unencrypted. Anyone who can read etcd, restore an etcd backup, or hold broad get secrets RBAC reads everything. Real secrets programs answer three questions: encrypted where, accessed by whom, rotated how.
Follow a database password from the app that needs it down to disk. Switch the protection model and watch which link stays readable.
The technical detail. At-rest: the API server’s EncryptionConfiguration encrypts resources before they hit etcd; the recommended provider is KMS v2 (GA v1.29) doing envelope encryption — a per-object DEK wrapped by a KEK that lives in an external KMS/HSM, so the key never sits next to the data and KEK rotation does not require rewriting everything. Remember: etcd backups inherit whatever posture you had — an unencrypted backup is the whole cluster on a platter.
Above the cluster: External Secrets Operator syncs from Vault / AWS Secrets Manager / GCP SM into Secrets; the Secrets Store CSI driver mounts them without creating Secret objects at all; Sealed Secrets makes them safe to commit for GitOps. Prefer file mounts over env vars (env leaks via /proc, crash dumps, and child processes). And treat sprawl detection (gitleaks, trufflehog in CI) as part of the program — the failure mode is rarely the vault, it is the copy that escaped it.
Interview lens: the July 2026 Grok Build privacy incident — repos and SSH keys leaving the client — is exactly this class: a secrets-boundary failure. The mature GRC response is a control loop: postmortem → a permanent automated check (secret scanning at the boundary, scoped tokens, egress allowlists) so the bug class cannot silently return.
Default Kubernetes networking: every pod can talk to every pod, across namespaces, in plaintext. Segmentation is opt-in via NetworkPolicy (enforced by the CNI), and proving who is on the other end of a connection takes mutual TLS — usually from a service mesh.
An attacker owns a frontend pod and wants the database two namespaces away. Tighten the network model and watch the lateral path close.
The technical detail. NetworkPolicy is an allow-list model with no deny rules: the instant any policy selects a pod, everything not explicitly allowed is dropped — so the foundational move is a default-deny ingress (and ideally egress) policy per namespace, then allow the known flows. Enforcement lives in the CNI (Cilium, Calico); vanilla kubenet ignores policies silently. Egress is the forgotten half: it is what turns a compromised pod into an exfiltration or C2 problem, and metadata-service access should be blocked here too. Cilium adds eBPF-based L7 policy (HTTP method/path, DNS names) and Hubble flow observability — segmentation you can see.
NetworkPolicy segments by label/IP; it does not authenticate. A service mesh (Istio — including sidecarless ambient mode, GA since 2024 — or Linkerd) issues per-workload certificates (SPIFFE-compatible), enforces mutual TLS with automatic rotation, and adds authorization policies in identity terms (“only api-gw may call payments”) — encryption-in-transit plus peer identity, inside the cluster, by default.
Interview lens: SOC 2 CC6.7 / ISO 27001 A.8.24 (encryption in transit) inside a cluster = mesh mTLS posture + continuous verification — probe endpoints and read mesh cert inventories on a schedule rather than trusting the architecture diagram. This is precisely the pattern of a continuous TLS-compliance agent fleet: the control is the test suite, run daily. See Compliance-as-Code.
The question a cluster should ask before running any image: who built this, from what, and can I verify that cryptographically? Signing (Sigstore), provenance (SLSA), and inventory (SBOM) answer it — and admission policy is where the answer gets enforced instead of documented.
An attacker pushes a lookalike image to your registry (compromised CI creds — the classic). Raise the verification bar and watch whether the cluster will run it.
The technical detail. Sigstore: cosign signs images; keyless mode removes key management by binding the signature to an OIDC identity (e.g. the exact CI workflow) via a short-lived certificate from Fulcio, with the event recorded in the Rekor transparency log — verifiable, non-repudiable, nothing long-lived to steal. Enforcement: Kyverno verifyImages or Sigstore policy-controller at admission — unsigned or wrongly-signed images simply never schedule. Pin by digest, not mutable tag.
SLSA v1.0 grades the build pipeline (L1–L3) and emits signed provenance attestations — proof of the builder, source repo, and inputs, which is what actually stops a “built from the wrong repo” attack. SBOMs (SPDX or CycloneDX) turn zero-day response from “rescan everything” into a database query: which running images contain liblzma 5.6.0? Regulatory pull is real: US EO 14028 made SBOMs table stakes for federal supply, and FedRAMP / EU CRA expectations keep tightening.
Interview lens: supply-chain controls are the cleanest example of compliance and velocity aligning — the gate is automated, evidence is the admission policy plus Rekor entries (both queryable), and engineers never file a ticket. At a ship-fast org, policy engines are how you keep speed and provability.
Admission policies stop bad configurations; they cannot stop a zero-day exploited inside an already-approved pod. The detective layer watches the cluster as it runs: Falco on kernel events, kube-bench against the CIS Benchmark, and the API audit log recording every touch. Each mechanism sees a different class of event — the matrix below shows which.
Click a column header to highlight which mechanisms cover that event. Note the pattern: config scanners see states, runtime sensors see behaviors, audit logs see API calls — no single tool sees everything.
| Mechanism | Anonymous kubelet access enabled | Shell spawned in prod container | Human runs kubectl exec | Miner process starts | Pod reads /etc/shadow |
|---|---|---|---|---|---|
| kube-bench (CIS v1.12 scan) | ✓ | — | — | — | — |
| Falco (eBPF syscall rules) | — | ✓ | ✓ | ✓ | ✓ |
| API server audit log | — | ▲ only via exec API | ✓ | — | — |
| Admission policy (preventive) | — | — | — | — | ▲ only if spec-level |
Reading the rows: kube-bench sees misconfigured states (flags, file permissions on the control plane). Falco sees behaviors as syscalls in real time. The audit log sees API-level actions with full identity attribution. Admission only sees what is declared in a spec — nothing that happens after.
The technical detail. Falco (CNCF graduated February 2024) hooks kernel events via a modern eBPF probe and evaluates rules like Terminal shell in container, Write below /etc, Outbound connection to known miner pool; outputs stream to a SIEM or an observability platform for alerting. kube-bench executes the CIS Kubernetes Benchmark (v1.12 is current, with distro variants for EKS/GKE/AKS/OpenShift) — API server flags, etcd TLS, kubelet auth, file permissions. The audit policy deserves design attention: log RequestResponse for secrets reads and RBAC changes, Metadata for the noisy rest — it is the forensic record and the attribution source.
Hardening that shrinks what runtime must catch: readOnlyRootFilesystem, distroless base images, dropped capabilities — an immutable container makes almost any write a signal. Interview lens: detective controls are evidence streams, not annual samples — a daily agent posting per-control pass/fail (FIM checks, vuln-scan currency, admin-activity review) is this tab operationalized, and it is exactly what production compliance agents do.
AI agents are NHIs with a twist: they choose their own actions. An agent with a credential is a workload identity plus autonomy — which is why OWASP now tracks both an NHI Top 10 and an Agentic Top 10, and why the industry is racing to give agents real identity infrastructure instead of shared API keys.
A compliance agent queries repos, cloud accounts, and monitors on its own schedule. Step up the governance model and watch the failure modes disappear one by one.
The technical detail. The OWASP NHI Top 10 (2025) catalogs the failure modes: improper offboarding, secret leakage, overprivileged NHIs, long-lived credentials, and cross-environment credential reuse; the OWASP Agentic Top 10 (2026) extends the list to autonomous behavior. Standards are converging fast: the AIMS draft (Agent Identity Management System, IETF, March 2026 — engineers from AWS, Zscaler, Ping, Defakto) deliberately invents nothing new, composing SPIFFE for workload identity, WIMSE for workload-to-workload auth, and OAuth 2.0 for delegated authorization. The market signal matching it: ServiceNow closed its acquisition of Veza — positioned as the “enterprise agent identity control plane” — on March 2, 2026.
The engineering discipline, in four layers: (1) identity — one identity per agent, never shared, so every action attributes to a specific agent version; (2) least privilege — scoped, short-lived, read-only by default; (3) verification — granted and effective permissions drift apart, so probe what credentials can actually do (non-destructively) rather than trusting the IAM console; (4) audit & inventory — the fleet itself is an asset class: owner, purpose, credential, expiry, full action trail. Governance frameworks are catching up: ISO/IEC 42001 and the NIST AI RMF both expect exactly this inventory-and-control posture for AI systems.
Interview lens: this is the tab where GRC engineering and security engineering become the same job — an agent fleet governed this way produces its own compliance evidence, and an ungoverned one is a breach with a scheduler. If you have built capability-verification probes or scoped-credential agent fleets, this is the vocabulary that frames that work.
Everything in the previous nine tabs becomes auditable through one pattern: map the framework control to the cluster mechanism, then collect evidence from the mechanism’s API on a schedule. Preventive controls live at admission; detective controls at runtime; evidence is a query, never a screenshot.
Four controls auditors actually test, from SOC 2, ISO 27001:2022, and NIST 800-53 (FedRAMP). Switch between them and watch where in the cluster the control lives and what the automated evidence looks like.
The technical detail. The mapping discipline: SOC 2 CC6.1–6.3 (logical access) → RBAC bindings + access-review queries; CC6.7 / ISO A.8.24 (crypto in transit) → mesh mTLS posture + endpoint probes; CC8.1 / NIST CM-6 (baseline config) → admission policies + kube-bench results; NIST SC-28 (at rest) → EncryptionConfiguration + KMS key policy; AU-2/AU-12 (audit events) → API audit policy + log pipeline health. FedRAMP HIGH and DoD SRG overlays add rigor (FIPS-validated crypto modules, personnel and physical controls) but not a different pattern — the cluster mechanisms are the same.
Operationally this becomes a continuous evidence pipeline: scheduled agents query the API server, the policy engine, the mesh, and the scanners; results land as immutable, timestamped records mapped to control IDs; failures page the owning team, not a compliance analyst at quarter-end. One well-designed control satisfies many frameworks at once when the mapping table is the system of record — the common-control-framework idea, implemented in software.
Interview lens: this is the thesis of the whole page — the control IS the test suite. A GRC engineer who can build this pipeline (query APIs, ship agents, keep the mapping table clean) turns audits from archaeology into a dashboard read, which is exactly the job description behind titles like “Security Engineer — GRC Frameworks & AI Governance.”