How to Secure vSphere Kubernetes Service (VKS) with Kyverno

To secure VMware vSphere Kubernetes Service (VKS), run Kyverno in every VKS cluster and enforce three baseline policy sets at admission: Pod Security Standards, RBAC best practices and image signature verification. Store the policies in Git, sync them with the Argo CD service that VKS already includes, and let Kyverno’s background scans catch drift in resources that are already running.

I talked through this setup with Anika Suri, who leads product marketing for VMware’s VKS ISV partners, on VCF Breakroom Chats Episode 95. The full technical detail is in Broadcom’s reference architecture, Nirmata Kubernetes Governance on vSphere Kubernetes Service on VMware Cloud Foundation. This post is the short version.

What VKS provides, and what it leaves to policy

VKS is the CNCF-certified Kubernetes runtime built into VMware Cloud Foundation (VCF). It creates and upgrades clusters through Cluster API, and its Supervisor provides shared services such as the Harbor registry, Contour ingress and Argo CD. For many VMware shops it is the easiest way into Kubernetes, because teams keep their vSphere tools and skills.

What a runtime doesn’t decide is what is allowed to run on it. Developers want to ship quickly; platform and security teams need to stop non-compliant workloads and misconfigurations. Kubernetes is declarative and highly configurable, so those rules belong in policy, applied consistently across the whole fleet of clusters. That is the layer Kyverno and Nirmata add to VKS.

How Kyverno fits into a VKS cluster

Kyverno runs as an admission controller inside each VKS cluster. Every create or update request passes through it, and policies can validate, mutate or reject the request before it is stored. Kyverno policies are Kubernetes resources written in YAML, so platform teams already know the format.

The reference architecture describes two deployment models:

Model	What runs where	Use it when
Standalone	Nirmata Enterprise for Kyverno installed in each VKS cluster with Helm; all policy management and enforcement stay in the cluster	Air-gapped or high-compliance environments with no outbound connectivity
Control Hub	Each cluster also runs a Nirmata agent that connects to Nirmata Control Hub (SaaS or self-hosted)	You want central policy distribution and one compliance view across clusters

Both models use the same Kyverno engine. The paper was validated on VKS 3.6 with Kubernetes v1.35, and lists VKS 3.5 or later, cert-manager, Helm 3 and the VCF CLI as prerequisites.

Which policies to enforce first

Start with three foundational policy sets. Each links to the policies in Nirmata’s open-source kyverno-policies repository:

Policy set	What it blocks	Policies
Pod Security Standards	Privilege escalation, host namespaces, root and privileged containers	pod-security (baseline and restricted)
RBAC best practices	Wildcard verbs or resources, cluster-admin bindings to service accounts, bindings to the default service account	rbac-best-practices-vpol
Image verification	Container images that aren’t signed and attested with Cosign	VerifyImage

To check that enforcement works, try to start a privileged pod:

kubectl run test-pod --image=nginx --privileged -n default

With the Pod Security policies in Enforce mode, the admission webhook denies the request and names the failing policy (for example, disallow-privileged-containers).

Managing policies with GitOps on VKS

VKS ships Argo CD as a Supervisor service, so policy distribution is already solved. Keep policies in a Git repository and point an Argo CD Application at the folder for your VKS clusters. With automated sync, prune and self-heal turned on, Argo CD applies new policies and reverts manual changes to existing ones.

Managing policy as code this way gives compliance teams what they ask for: every policy change is versioned, reviewed and traceable in Git. The reference architecture includes an example Argo CD Application manifest. For tips on running the two together, see 3 essential tips for using Argo CD and Kyverno.

Day 2: continuous compliance across the fleet

Once the baseline is in place, the work becomes fleet-wide, continuous compliance, often across hundreds of clusters. Kyverno contributes two things here:

Admission control keeps non-compliant workloads and unsigned images out of every cluster.
Background scanning re-evaluates existing resources. If a change slips past admission, or a resource predates a policy, the scan reports it.

Kyverno writes the results to policy reports in each cluster. In the Control Hub model, Nirmata Control Hub aggregates them across all connected VKS clusters and provides governance dashboards for platform and security teams.

Watch the episode

Next steps

Read the reference architecture for the cluster configuration, Helm installation for both deployment models, and the Argo CD example.
See the Nirmata and Broadcom announcement for background on the partnership.
Learn about Nirmata Enterprise for Kyverno and Nirmata Control Hub.
For regulated environments, see how Chase UK made Kubernetes audit-ready with Kyverno.

Frequently asked questions

How do you enforce Pod Security Standards on VKS?

Install Kyverno (or Nirmata Enterprise for Kyverno) in each VKS cluster with Helm, then apply a Pod Security Standards policy set in Enforce mode. Kyverno validates every pod at admission and rejects ones that break the profile, such as privileged containers. A quick test is to run a pod with --privileged and confirm the request is denied.

Can Kyverno run in air-gapped VKS environments?

Yes. The VMware reference architecture describes a standalone model where Nirmata Enterprise for Kyverno is installed from a mirrored registry and all policy management and enforcement stay inside the cluster, with no outbound connection to a SaaS service.

How do you deploy Kyverno policies to many VKS clusters?

Two ways. VKS includes Argo CD as a Supervisor service, so policies kept in Git can be synced to target clusters like any other manifest. For a central view, each cluster can also run the Nirmata agent and connect to Nirmata Control Hub, which distributes policies and aggregates compliance results across clusters.

Does Kyverno only check resources at admission?

No. Kyverno also runs background scans of existing resources. If something changes outside the normal path or was created before a policy existed, the scan reports it, so configuration drift does not go unnoticed.