Kubernetes Admission Control, Policy-as-Code and Runtime Guardrails — DedSec Project

Deepen Kubernetes security by focusing on the control path between an API request and a running workload: admission, mutation, validation, pod-security controls, policy engines and runtime drift.

Learning objectives

By the end of this module you should be able to:

• Explain API admission lifecycle and identify its most important trust boundary, state transition, and evidence source.
• Explain mutating versus validating admission and identify its most important trust boundary, state transition, and evidence source.
• Explain Pod Security Standards concepts and identify its most important trust boundary, state transition, and evidence source.
• Explain policy-as-code engines and identify its most important trust boundary, state transition, and evidence source.
• Explain image provenance and allowlists and identify its most important trust boundary, state transition, and evidence source.
• Explain namespace and service-account context and identify its most important trust boundary, state transition, and evidence source.

Deep concepts

1. admission lifecycle

Kubernetes admission runs after authentication/authorization but before an API object is persisted. It is a policy enforcement point for resource configuration, not a replacement for runtime isolation, RBAC, image security, or continuous drift detection.

2. mutating versus validating admission

Mutating admission can add/default fields before validation; validating admission accepts or rejects the resulting object. Keep mutations predictable and observable because hidden changes make policy reasoning, debugging, and signed-manifest expectations harder.

3. Pod Security Standards

Pod Security Standards define baseline/restricted expectations for risky pod settings such as privilege, host namespaces, capabilities, volume types, and seccomp. Apply profiles according to workload need and manage narrow exceptions explicitly.

4. policy engines

Admission policy engines evaluate manifests against organization-specific rules. Version policies as code, test allow/deny cases in CI, use clear messages, scope rules carefully, and monitor exceptions so a temporary bypass does not become permanent architecture.

5. image provenance and allowlists

Admission can restrict registries, digests, signatures/attestations, or provenance according to deployment policy. Prefer immutable digests and verified provenance for high-assurance workloads rather than trusting a mutable image tag alone.

6. namespace and service-account context

The same manifest can have different risk depending on namespace labels, service account, secrets, network policy, quotas, and target environment. Admission decisions should include the context that actually determines workload authority.

7. runtime drift

Admission checks desired objects at creation/update time, but containers, nodes, credentials, external services, or manually changed infrastructure can drift afterward. Combine admission with runtime telemetry, configuration reconciliation, and periodic policy checks.

8. telemetry and exceptions

Record policy/version, object, namespace, user/service account, decision, violated rule, and exception identity. Exception workflows should require owner, reason, scope, and expiry, with dashboards showing which high-risk workloads are outside normal policy.

Authorized lab sequence

• Lab 1 — Write policy requirements for a toy Kubernetes manifest: non-root, restricted capabilities, approved image source and resource limits.

• Lab 2 — Compare admission-time and runtime evidence for the same fictional workload.

• Lab 3 — Create an exception record with owner, reason, expiry and compensating control, then define an automated review trigger.

Knowledge checks

Answer these without looking at the notes:

Next modules

Recommended related modules: 024, 041, 075, 093, 097, 113. From the main menu, choose Search lessons to find related sections across the full guide.