kubernetes

The VKS Policy Bundle Admission Control as a Distributed Enforcement Problem

Kubernetes admission policy is where workload security stops being advisory. Broadcom’s new policy bundle for vSphere Kubernetes Service packages the baseline controls the engineering question is how you operate policy at fleet scale without breaking application teams. The technical read.

Broadcom shipped a policy bundle for vSphere Kubernetes Service this week, and the framing in the announcement is the correct one: the hard problem in Kubernetes security isn’t understanding the value of admission policy it’s managing enforcement at scale. This piece covers the mechanics: what admission policy actually does, what the bundle’s control targets are, and the operational model that makes policy enforcement survivable across a fleet of clusters.

The Mechanics Where Admission Policy Sits

Every object that enters a Kubernetes cluster passes through the API server’s admission phase after authentication and authorisation but before persistence to etcd. Admission is the last point at which a workload specification can be validated or rejected before it exists in the cluster which makes it the enforcement point for the class of controls that runtime scanning can only report on after the fact. A policy evaluated at admission is preventive; everything downstream is detective.

The control targets the bundle addresses are the canonical container-hardening set: privileged containers (privileged: true grants the container effectively host-root capability and defeats the container isolation boundary), host namespace access (hostNetwork, hostPID, hostIPC each collapses one isolation dimension between pod and node), and containers running as root (runAsUser 0 inside the container, which converts any container-escape primitive into node-level compromise). These map directly onto the restricted tier of the Kubernetes Pod Security Standards and onto the container-platform sections of CIS benchmarks which is what makes admission-enforced policy auditable, not just protective.

Why a Bundle Rather Than Hand-Rolled Policy

Any platform team can write these policies the primitives (Pod Security Admission at namespace level, ValidatingAdmissionPolicy with CEL expressions since Kubernetes 1.30, or an external engine like Kyverno/Gatekeeper) are well understood. What a curated bundle changes is the maintenance economics: policy definitions tracked against VKS releases, tested against the workloads the platform itself runs (CSI drivers, CNI components, and other system workloads legitimately need privileges that application workloads must not have), and versioned as a unit rather than as a folder of YAML with unknown drift. The system-workload exemption problem is the one that burns hand-rolled deployments a policy set that blocks privileged containers without a correctly-scoped exemption model either breaks the platform’s own components or gets watered down until it blocks nothing.

The Operating Model Enforcement at Fleet Scale

• Audit before enforce. Every admission policy supports a warn/audit mode; run the bundle in audit across the fleet first and harvest the violation inventory. The violations you find are your migration backlog, and their owners need lead time flipping to enforce without an audit phase converts a security rollout into an application outage.

• Namespace scoping is the tenancy boundary. Policy strictness should map to namespace classes system namespaces exempted explicitly, application namespaces at the restricted baseline, and any legitimately-privileged workloads (node agents, storage) in dedicated namespaces with documented exceptions. The exception list is an architectural artefact; review it like firewall rules.

• Policy is fleet configuration, not per-cluster configuration. The failure mode at scale is per-cluster divergence cluster 14 has the old policy version, cluster 15 has a local exemption nobody documented. Distribute the bundle through the same mechanism that manages cluster lifecycle, and treat policy version as part of the cluster’s desired state alongside the Kubernetes version.

• Violations are compliance telemetry. Admission denials and audit-mode warnings are evidence of both control operation and attempted drift route them to the same place your ACC findings land, and the Kubernetes layer joins the platform’s continuous-compliance surface rather than sitting beside it.

The Architect’s Takeaway

Admission policy is the Kubernetes-layer equivalent of what VCF 9.1 has been doing platform-wide: turning point-in-time hardening checklists into continuously-enforced desired state. The bundle removes the authoring and maintenance burden; the work that remains audit-first rollout, namespace-class scoping, a governed exemption list, fleet-consistent distribution is operating-model work, and it’s where the design effort belongs. Write the namespace policy classes and the exemption governance into the platform design; the YAML is the easy part.