Not long ago, Kubernetes teams were wrestling with cluster sprawl: they had too many clusters, each one was managed a different way, and it was making platform engineers’ lives a nightmare. While that problem never quite disappeared, in the meantime, we’ve also seen the rise of its sinister cousin: policy sprawl.
The way teams create and enforce policies is often inconsistent and frustrating because they’re fundamentally not speaking the same language. That’s making everybody’s life much harder than is needed, and certainly causing slowdowns in production pipelines. Red Hat’s 2024 State of Kubernetes Security Report shows that 67% of organizations reported that they delayed or slowed down deployment due to Kubernetes security concerns, with 54% reporting that they had experienced inconsistent policy enforcement in the past 12 months.
Spectro Cloud’s 2024 State of Production Kubernetes Report tells a similar story. 48% of respondents said it’s difficult to decide which stack components to use from the cloud-native ecosystem, which suggests that – while it’s great for everyone to be able to choose the languages and tools they’re most comfortable with – it’s having a harmful effect on velocity and organizational cohesion.
Two Languages, One Problem
YAML is often called the language of cloud-native, defining – as it does – nearly everything in Kubernetes: from pods and services to NetworkPolicies, but it’s not alone. Rego, the policy language for Open Policy Agent (OPA), is just as important. Rego has become deeply integrated across open-source and commercial tools, from CI/CD to service meshes.
The issue isn’t that multiple languages exist – or even that there are fundamental incompatibilities between them – it’s that teams pick different ones without a shared strategy. One uses Rego in OPA Gatekeeper, another relies on Common Expression Language (CEL) in Kyverno, and a third adopts their own frameworks across registries and pipelines.
Where does that leave your engineers, I hear you ask? The answer is elbow-deep in translation. They end up having to re-learn languages, work out why people phrased a policy the way that they did, rewrite enforcement logic, and reconcile conflicts between tools that don’t play together nicely.
Lost in Translation
Think of it this way: you need the same report from Finance, Security, and Ops. Except everybody in the Finance Department speaks German, Security speaks Spanish, and Ops speaks Italian. Frankly, it’s a recipe for disaster. That’s exactly what’s happening when every team uses a different policy language. You can’t be sure that policies are enforced consistently across the stack, because there is no consistency across the stack.
What’s worse, for each minor change – based on a new compliance requirement, for instance – prompts everyone to dive into a gruelling series of redundant tasks. Each group reinterprets and re-implements the policy in their own language, increasing the likelihood of divergence, and potentially leading to operational blind spots. These might be policies that appear to be the same on paper but look very different once you push them into production. All this could be avoided if we brushed off our phrasebooks and agreed on a shared language.
The Case for Standardization
Policy-as-code is already the modern answer to “ClickOps.” But for it to deliver on its promise, teams need a shared language that can easily be automated in projects such as Terraform. Rego has a good claim as the closest thing the ecosystem has to a lingua franca – a de facto common tongue. It’s already embedded in tooling across the stack and everyone knows what it is, even if they don’t use it regularly.
Standardizing on a single policy language doesn’t mean you have to rewrite everything overnight. But it does help you cut down on duplication, simplify testing, and make enforcement more predictable. Rego policies can be version-controlled and shared across different teams easily, which removes a lot of the friction that usually comes with trying to keep governance consistent at scale.
The result is fewer surprises, faster deployment, and less time your engineers have to spend rewriting the same logic in three different places. It also puts security and platform teams on the same footing, because they’re working from the same source of truth.
Who really wants to spend hours thinking about policies?
As Kubernetes workloads expand into AI and GPU-heavy territory, this type of sprawl will only deepen if teams stick to their own dialects. Kubernetes doesn’t just need policy-as-code, engineering teams are looking for a common policy language that they can use between different tools and software vendors.
Standardization turns your policies from bottlenecks into another layer of validation, giving development teams the speed to innovate without creating blind spots in security or governance. To make that happen, all we need to do is get on the same page.
KubeCon + CloudNativeCon North America 2025 is taking place in Atlanta, Georgia, from November 10 to 13. Register now.
##
ABOUT THE AUTHOR
Nigel Douglas, Head of Developer Relations, Cloudsmith
Nigel Douglas is the Head of Developer Relations at Cloudsmith. He champions Cloudsmith’s developer ecosystem by creating compelling educational content, engaging with developer communities, and promoting Cloudsmith as the go-to solution for artifact management and supply chain security. Working closely with product, engineering, and marketing teams, Nigel helps build and shape the DevOps community through events, tutorials, and innovative programs.
Before joining Cloudsmith, Nigel held similar roles in cloud-native OSS projects, including the CNCF Graduate Project Falco at Sysdig and Project Calico at Tigera. He earned a Master of Science in Cybersecurity, Privacy, and Trust from South East Technological University in Ireland.
