A namespace is not a security boundary until you make it one

Teams reach for namespaces to carve a shared cluster into tenants (one per team, one per customer, one per environment) and then quietly assume the namespace is the wall. It is not. A namespace is a scope for names and a hook for policy. It becomes a security boundary only when RBAC, network policy, and admission control are configured to make it one. The operators and controllers running cluster-wide are where that assumption most often fails, and this week's Camel K disclosure is a clean example.

CVE-2026-45760: the controller honored the wrong namespace

CVE-2026-45760 (CVSS 8.1) is in Apache Camel K, a framework for running integration workloads on Kubernetes. The advisory pairs two weakness classes: an externally controlled reference to a resource in another sphere (CWE-610), and an authorization bypass through a user-controlled key (CWE-639). In plain terms: a user authorized to create a Build resource in their own namespace can control where the resulting build Pod is generated, in a namespace of their choosing, including the operator's namespace.

The user-controlled key is the target namespace. The controller acts on it without confirming the requester is entitled to schedule there. Affected ranges are 2.0.0 before 2.8.1 and 2.9.0 before its fixed release. The consequence is the dangerous part: the operator namespace typically holds more powerful service accounts, secrets, and config. A tenant who should be confined to team-a can land a workload (whose image and command they influence) next to those privileged objects. That is the seam an attacker rides from “one tenant” to “the cluster.”

Why operators are the soft underbelly

Operators and controllers run with broad, cluster-wide permissions because their job demands it: they reconcile resources across namespaces on everyone's behalf. That makes them a confused deputy waiting to happen: a low-privilege user asks the high-privilege controller to do something, and if the controller does not check that the requester (not the controller) is authorized for the target, the user has borrowed the controller's power. Camel K's build-placement bug is exactly this. The controller could schedule into the operator namespace; the user could not; the controller did the user's bidding without checking.

This is not a Camel-specific flaw so much as a Kubernetes-ecosystem pattern. Any controller that takes a user-supplied target (a namespace, a secret reference, a service account name, an image pull source) and acts on it with its own elevated identity must validate that the requesting principal is allowed to name that target. The ones that do not are tenancy bypasses waiting for a researcher.

Making the namespace into a boundary

You cannot rely on the controller alone; you defend in depth so a single controller bug does not become a cluster compromise:

• Least-privilege RBAC. Confine each tenant's Role/RoleBinding to its own namespace. Audit what custom resources (like Build) a tenant can create. Powerful CRDs are privilege grants in disguise.
• Admission policy that enforces alignment. A validating admission policy (built-in ValidatingAdmissionPolicy, or a policy engine) should reject any resource whose target namespace differs from the requester's, independent of what any controller believes.
• Scope the operator. Where the framework supports it, run the operator namespace-scoped rather than cluster-scoped, so a placement bug cannot reach beyond its blast radius.
• NetworkPolicy and PodSecurity per namespace. Default-deny network policy and a restricted Pod Security Standard turn the namespace into a real isolation unit instead of a label.

The defensible test is an RBAC-and-admission audit, performed read-only, that confirms a confined identity genuinely cannot act across the boundary:

# Can a confined tenant act outside its namespace via a controller? (read-only)
# Enumerate what a tenant SA can create, and whether admission blocks cross-ns targets.
kubectl auth can-i create builds.camel.apache.org \
  --as=system:serviceaccount:team-a:default -n team-a
kubectl get validatingadmissionpolicy,validatingadmissionpolicybinding 2>/dev/null
# Confirm the operator image is on a fixed train (2.8.1+ / patched 2.9.x):
kubectl get deploy -n camel-k-operator \
  -o jsonpath='{.items[*].spec.template.spec.containers[*].image}'
# FINDING = a confined SA can influence placement outside its namespace on a
# pre-fix operator with no admission backstop. Defense-in-depth present = PASS.

The takeaway

Patch Camel K to its fixed train, but treat the CVE as a prompt to ask the broader question of every operator in your cluster: does this controller act on a user-supplied target with its own elevated identity, and does it check that the user was allowed to name that target? The namespaces in your cluster are doing exactly as much isolation as your RBAC and admission policy make them do, and not one byte more.

How Celvex Sentry tests for this

Our continuous-monitoring suite audits Kubernetes RBAC, admission policy, and operator versions for the cross-namespace / confused-deputy class, confirming whether a confined identity can provably influence resources outside its namespace, and whether an admission backstop exists. When a tenant boundary is bypassable, we mint a Proof Capsule with the can-i evidence, the missing-control finding, and the RBAC + admission-policy + fixed-version remediation attached. When the boundary holds at multiple layers, we record a PASS.