# Stop Letting "YOLO Deployments" Break Your Cluster: Hello, Kyverno!

## **Introduction: The Silent Guardian of the API Server**

Maintaining a Kubernetes cluster often feels like a constant battle against configuration drift. As teams scale, the anxiety of "<mark>who deployed what and why</mark>" grows. Without a gatekeeper, your API server is essentially an open door to any configuration, regardless of how insecure or inefficient it might be.

This is where Admission Controllers step in. Think of them as the middleware of the Kubernetes world—an essential layer of logic that scrutinizes every request after it has passed authentication and authorization, but *before* the state is persisted to the **etcd** database. This specific timing makes them the ultimate arbiter of what actually enters your cluster’s "source of truth."

An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but only after the request is authenticated and authorized. In simpler terms, admission controllers can be thought of as <mark>middleware that can validate, mutate, or reject requests to the Kubernetes API.</mark>

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1768681835445/2a80bf09-0501-49b8-8ab2-fd760f6da521.png align="center")

## **The "Wild West" of K8s: Why we can't have nice things**

At the scale of an large company, Kubernetes can quickly become a "Wild West." Without strict policy enforcement, clusters are prone to systemic risks. Some researches also identifies misconfigurations—specifically overly permissive RBAC and **unbounded service accounts**—as the leading cause of security breaches.

Beyond security, there is the silent financial leak of "<mark>Resource Asymmetry.</mark>" The `kube-scheduler` relies on a complex scoring algorithm to assign pods to nodes based on CPU and memory. However, because this scoring is highly variable, developers often "play it safe" by over-estimating resource requests to avoid performance issues. This leads to a scenario where "spending outstripping use" becomes the norm.

The danger of "<mark>Missing Requests and Limits</mark>" is particularly acute; without these guardrails, a single resource-hungry pod can trigger a <mark>denial-of-service</mark> for its neighbors. This evolving threat landscape, combined with the risk of insider threats, makes automated gatekeeping the architect's path to sanity.

## **Kyverno vs. OPA: Why I refuse to learn another language (Rego)**

When choosing a policy engine, the industry generally gravitates toward two heavyweights: Kyverno and OPA Gatekeeper. However, the friction of learning a specialized query language like Rego (used by OPA) often slows down security adoption for YAML-native teams.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1768681847010/a91fae98-2361-40ec-b4b5-d66aa03a6759.png align="center")

The tech team at Adevinta recently highlighted a "<mark>functional failure</mark>" in OPA Gatekeeper’s mutation capabilities that led them to migrate. Specifically, Gatekeeper's `Assign` feature failed because it could not modify fields based on **contextual data**—information residing outside the specific field being observed. While OPA requires a complex external data provider setup for this, Kyverno handles it natively within the same manifest.

## **It’s just YAML! (The moment you fall in love)**

The Kyverno advantage is simple: it feels like a natural extension of the Kubernetes experience. Because policies are written in native YAML, they integrate seamlessly with `kubectl`, Helm, and GitOps workflows. It is a more intuitive way to handle governance than traditional programming-heavy engines.

We are also witnessing a major shift with the arrival of **<mark>CEL (Common Expression Language)</mark>**<mark>.</mark> In Kubernetes **<mark>v1.33</mark>**, `ValidatingAdmissionPolicy` has officially reached **V1 (GA)**. This is a game-changer because it allows for declarative validation directly in the vanilla API server **without external HTTP webhooks**. By removing the need for these callouts, architects can eliminate network latency and webhook failure modes entirely. Even OPA Gatekeeper is acknowledging this shift by adding CEL support, signaling a move toward standardized, high-performance logic.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1768681879352/b1087f89-8a56-46be-b2da-19a74241d769.png align="center")

## 3-Minute Install: From "Zero" to "Governance"

Getting started is faster than your coffee cools. You can go from an unmanaged cluster to a governed environment using the standard Helm workflow for Kyverno:

1. **Add the Repo:** `helm repo add kyverno` [`https://kyverno.github.io/kyverno/`](https://kyverno.github.io/kyverno/)
    
2. **Update:** `helm repo update`
    
3. **Install:** `helm install kyverno kyverno/kyverno --namespace kyverno --create-namespace`
    

### **The Lifecycle of a Request**

To master admission control, you must understand the technical sequence of a request:

1. **Mutating Phase:** The controller modifies the request (e.g., injecting sidecars or team labels).
    
2. **Schema Validation:** The API server performs a structural JSON check to ensure the resource is well-formed.
    
3. **Validating Phase:** The controller checks the request against security rules and finally accepts or rejects it.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1768681905795/eb44a427-7272-4145-917e-62fbe02bc06d.png align="center")

<div data-node-type="callout">
<div data-node-type="callout-emoji">💡</div>
<div data-node-type="callout-text"><strong><em>Pro Tip:</em></strong><em> Always start in </em><strong><em>Audit Mode</em></strong><em>. This allows you to assess the impact of policies without breaking existing developer workflows. Once you have sanitized the environment, flip the switch to </em><strong><em>Enforce Mode</em></strong><em>.</em></div>
</div>

## **Your First Policy: Ban the default namespace**

Isolating workloads is the first step toward maturity. Kubernetes ships with a static admission controller called `NamespaceLifecycle` that acts as a basic safeguard. It prevents the accidental deletion of three critical system-reserved namespaces: `default`, `kube-system`, and `kube-public`.

However, true governance requires moving beyond defaults to enforce **ResourceQuotas** and custom labels. This prevents one team from monopolizing node resources. From there, follow the experimental insights from S&P 500 deployments to harden your `securityContext`:

* **Enforce Rootless Mode:** Prohibit deployments where `runAsNonRoot` is false.
    
* **Identity Mapping:** Explicitly define `runAsUser` and `runAsGroup` (e.g., set to 1000) to ensure workloads never run under a root identity.
    
* **Immutable Filesystems:** Enforce `readOnlyRootFilesystem: true` to prevent attackers from persisting malicious scripts or exfiltrating data.
    

## Conclusion: The Future of Sovereign Clusters

The evolution of Kubernetes is moving toward Zero Trust and "Sovereign Clusters"—environments where an enterprise maintains absolute sovereignty over its standards across multi-cluster platforms. By implementing these gatekeeping rules today, you lay the foundation for AI-driven threat detection and automated compliance.

<mark>If your API server disappeared tomorrow, would your policy engine know how to rebuild the trust?</mark>

<div data-node-type="callout">
<div data-node-type="callout-emoji">💡</div>
<div data-node-type="callout-text"><strong><em>If you liked this article follow for more, and wait for the rest of the series, I will write more about each policy type and more…</em></strong></div>
</div>