The Kubernetes Noisy Neighbour Problem Is Actually a Permissions Problem

I've had a version of this conversation more times than I can count with platform teams at large enterprises, and it always starts the same way. One team wants to build something that behaves like a custom Kubernetes controller: a messaging system with its own lifecycle, a database operator, something that needs to watch the cluster and react. To do that properly, they need real Kubernetes API access. And the platform team's next sentence is almost always some version of: I don't want to give you API access and turn you into a noisy neighbour for everybody else who isn't asking for it.

That's not a hypothetical worry and is absolutely the correct instinct. The question is what you do about it because just denying access to the power of the Kubernetes API can't be the only answer.

The permissions version of a familiar problem

Most people know the noisy neighbour problem from compute: one workload hogs CPU or I/O and everyone sharing that node feels it. The permissions version is quieter, and arguably worse. 

At its worst, broad API access is a genuine security hole, another way into the cluster that didn't strictly need to exist. But even well short of that, it's a tax on the platform team's ongoing work: whatever bespoke permissions you granted for one team's controller are now something you have to account for on every future Kubernetes upgrade, checking that nothing you loosened breaks, or gets silently tightened back out from under them. Give one team broad API access so they can run their operator, and you've expanded two things at once: the set of things that can go wrong for every other tenant on that cluster, and the amount of re-verification work waiting for you on the next upgrade, whether or not that team's operator was ever actually the problem.

Platform teams know this. It's why the request for API access gets treated so carefully, and why so many of these conversations stall out exactly there despite how much value they can unlock.

Three ways teams cope today, and why none of them is quite right

The first option is to just grant the access and accept the risk. It works, until it doesn't. The scale of people within the industry, let alone a single company, that know how to write good-quality Kubernetes controllers is limited and that then limits the outcomes. And for those that do get deployed, when it doesn't work, it is a 2 am alert with the on-call engineer managing a blast radius nobody scoped properly in advance.

The second is to refuse, and push the team toward "just use Helm." This sounds safer, but it isn't really an answer. Helm can template YAML. It can't watch cluster state and react to it, it can't offer something as a request with an approval workflow behind it, and it can't stop mid-rollout if something needs to pause and wait for an external system to sync. The team still needs the controller behaviour they originally asked for; you've just made them build the request-and-approval layer around it themselves, usually badly, usually with a CI/CD system patched on afterwards that was never made for ongoing reconciliation.

The third is to build a bespoke internal abstraction from scratch that mediates access on the team's behalf. This can work, but now the platform team owns a permanent, growing maintenance burden: every new use case is another one-off to build and support forever. The question is, can we reduce the cost burden while getting the outcomes of this solution?

Buy the access-limiting abstractions. Build freely within safe boundaries.

The thing that needs broad Kubernetes API access is the thing that runs the logic, not necessarily the person who is writing the logic. This is why Kratix acts as a control plane, with the Promise domain object defining the logic. This means Kratix demands direct Kubernetes API access, but the person authoring the capability your teams will consume does not.

First, it is important to acknowledge that Kratix requires pretty broad permissions to be installed. The reality is that it needs to create and manage CRDs and jobs (the full breakdown is in our RBAC documentation if you want the specifics). While that is a real requirement, it doesn't have to be insecure. Kratix is self-hosted and only requires standard Kubernetes resources, so it can be run easily on independent clusters (even air-gapped ones!) and virtual clusters to enable secure sandboxing.

Managing K8s access and permissions: Kratix needs the access; Promise authors don't

By offloading Kubernetes extensions to Kratix, your platform now has a specific scope that it can wrap in permissions. Through simple admission controllers or more complex Policy as Code solutions such as Kyverno and Open Policy Agent (OPA), your platform team can secure access to writing Kubernetes controllers. The person writing a Promise, the "database" or "messaging service" or "application" capability that other teams will request, never touches the Kubernetes API directly to do that. Their pipeline runs scoped to its own namespace, separate from the centralised Kratix control logic, and it produces a declarative output. The API access lives in one place, held by Kratix itself, not scattered across every team that wants to offer a capability to the rest of the org.

That's the actual abstraction. It's not "here's a nicer YAML templating tool." It's: your organisation needs exactly one thing with broad cluster permissions, instead of one thing per team that wants to build a controller-like capability. Everyone else works through Promises, requests, and approvals, none of which require them to hold a Kubernetes credential with real teeth. 

This is also why we talk about platform orchestration as its own layer: it sits between raw infrastructure access and the applications consuming it, and permissions are exactly the kind of concern that belongs at that layer instead of being pushed down to every team individually.

The isolation patterns we actually see

Because I know "pretty broad permissions" doesn't fully settle anyone's nerves on its own, it's worth being specific about what organisations do with that access once Kratix has it. We see three patterns in practice, and which one an organisation picks comes down to their own security posture, not ours.

Some run Kratix inside a virtual cluster (using vCluster) specifically to sandbox those permissions further, adding a layer of isolation between the control plane and the rest of the cluster. Others run it on a dedicated platform cluster, one that's explicitly set aside to host a small number of privileged, trusted applications, and nothing else. And some organisations run it on a perfectly generic shared cluster, because that already matches how they think about risk elsewhere in their environment. All three are legitimate. None of them requires you to grant that same level of access to every team building a capability on top.

The Kratix/Kubernetes isolation patterns we actually see

Final thoughts

The desire to avoid handing out Kubernetes API access and creating a permissions version of noisy neighbours is a good reason to slow these conversations down. Where I think there's room to improve isn't in reducing that caution. It's in not assuming that the only way to let a team build controller-like behaviour is to hand that team the access directly. 

An abstraction for defining controller behaviour lets you hold the access centrally instead, so your capability providers never need it themselves, and you get to choose how much further to isolate that single point of privilege: a virtual cluster, a dedicated platform cluster, or the generic one you already run. 

This is exactly the kind of thing that matters for your platform but doesn't differentiate your business, which is why we built Kratix to provide it, so you don't have to define and maintain that abstraction yourself. The organisations I've talked to land on very different answers about how isolated they want to be, but they all get to skip the part where every team needs its own slice of cluster admin.

If you're keen to learn more about why we built Syntasso Kratix Enterprise (SKE) and Syntasso Kratix Agentic (SKA) to address these challenges, check out the rest of the website or reach out to us.