Kubernetes across security enclaves: multi-classification clusters

Defense programs rarely operate at a single classification level. The same mission software that ingests open-source feeds in an Unclassified enclave often has a Secret variant fusing it with sensitive collection, and sometimes a Top Secret variant on top of that. The instinct of an engineer used to commercial Kubernetes is to model these levels as namespaces, tenants, or virtual clusters inside one platform. That instinct is wrong for classified work, and getting it wrong is expensive to undo. In a multi-level secure (MLS) environment, the Kubernetes cluster – and the network it sits on – is the classification boundary, not a tenancy detail inside it. This article walks through how to run Kubernetes across security enclaves: one accredited cluster per classification level, strict policy isolation inside each, verifiable image provenance, and controlled, one-way promotion of artifacts between domains.

The boundary is the cluster, not the namespace

Kubernetes gives you several mechanisms that look like isolation: namespaces, NetworkPolicies, RBAC, resource quotas, and admission control. Every one of them is a tenancy control operating inside a single trust boundary. They all share the same API server, the same etcd datastore, the same Linux kernel on each node, and the same container runtime. A container escape via a kernel vulnerability, a flaw in the API server's authorization path, or a single over-broad ClusterRoleBinding can cross every one of those soft boundaries at once.

An accreditor looking at an MLS system asks a simple question: what physically or cryptographically prevents Secret data from reaching the Unclassified side? "A NetworkPolicy" is not an acceptable answer, because a NetworkPolicy is enforced by the same CNI plugin and kernel that the workloads themselves run on. The accepted answer is separation: separate clusters, separate networks, separate hardware or separate cryptographically isolated partitions, each accredited to process exactly one level. Namespaces remain useful – but only as administrative compartments within a single enclave, never as the line between Unclassified and Secret.

This is the same principle that underlies cross-domain solutions for defense: data only moves between levels through an accredited guard, never through a shared software control that both sides can reach. Multi-enclave Kubernetes simply applies that principle to the orchestration layer.

One cluster per enclave: the reference topology

The reference topology for a three-level program is three fully independent Kubernetes deployments, one per enclave:

Unclassified / development enclave. This is where most engineering happens. It has the broadest connectivity (often a path to the internet through a proxy for pulling upstream dependencies), the most permissive change cadence, and the build pipeline that produces the artifacts the higher enclaves will eventually consume. It is still hardened – default-deny networking, signed images, no privileged pods – but it is the only enclave where new images are born.

Secret enclave. Disconnected from the public internet, this cluster runs the Secret variant of the mission software. It pulls images only from its own in-enclave registry, which is populated exclusively by promotion from below. Its change cadence is slower and every deployment is tied to an accredited release. The operational discipline here resembles an air-gapped Kubernetes deployment – offline registries, no live upstream pulls, and an upgrade process that has to survive accreditation.

Top Secret enclave. The most restricted cluster, on the most isolated network, with the strictest personnel and physical controls. It receives a curated subset of artifacts from the Secret side, again only through an accredited transfer.

Each enclave is a complete, self-sufficient Kubernetes universe: its own control plane and etcd, its own CNI and storage classes, its own image registry, its own identity provider and RBAC, its own GitOps controller, and its own observability stack. Nothing in a higher enclave depends on a service in a lower enclave being reachable at runtime. That independence is what lets each cluster be accredited on its own terms.

Why federation across levels is a covert channel

The tempting shortcut is to federate identity, image distribution, or GitOps across the enclaves so operators have one console. Resist it. A live authentication federation that issues a token usable on both the Unclassified and the Secret side is, by definition, a real-time channel between the two levels – exactly the thing the separation is meant to prevent. The presence or absence of a successful login, the timing of token refreshes, even error codes can encode information across the boundary. The same logic rules out a shared registry that both sides write to, or a single GitOps controller reconciling clusters at different levels. Anything that maintains a synchronous connection across the boundary is a potential covert channel and will not pass review.

Policy isolation inside each enclave

Separation between enclaves is necessary but not sufficient. Inside each cluster you still need rigorous compartmentation, because an enclave hosts many workloads, services, and teams that should not freely reach one another. This is where Kubernetes-native controls earn their place.

Start with admission control. A policy engine such as Kyverno or OPA Gatekeeper enforces non-negotiable rules at the moment a workload is admitted: only signed images from the enclave's own registry may run; no pod may request privileged mode, host networking, or host path mounts; every container runs as a non-root user with a read-only root filesystem and a dropped capability set; and every namespace meets the Pod Security Standards restricted profile. These are the same hardening controls covered in depth in Kubernetes hardening for defense workloads, applied identically in each enclave so that the baseline does not drift between levels.

Networking inside the enclave is default-deny. Every namespace starts with a NetworkPolicy that drops all ingress and egress, and connectivity is granted explicitly per service pair. East-west traffic between sensitive compartments runs over mutual TLS, typically through a service mesh, so that a workload's identity – not just its network position – gates access. Resource quotas and limit ranges prevent a single compromised or misbehaving workload from starving the cluster.

RBAC and the break-glass discipline

RBAC inside each enclave follows least privilege without exception. Day-to-day operators get namespace-scoped roles; nobody holds standing cluster-admin. The cluster-admin capability lives behind a break-glass procedure: a credential that is sealed, whose use triggers an alert, and whose every action is recorded to immutable audit storage. Because the enclaves are independent, the break-glass procedure is independent too – using it in the Secret enclave grants nothing in the Unclassified one. Service accounts are scoped to a single namespace, their tokens are short-lived and bound to a specific workload, and none of them is ever reused across clusters.

Image provenance: trust earned at build, verified at run

In a multi-enclave architecture the supply chain is the most attractive attack surface, because an image built once on the low side may eventually run at Top Secret. Every image must therefore carry verifiable provenance that the highest enclave can check without trusting any lower enclave at runtime.

The discipline is: build in the lowest enclave that can build the image, generate a complete software bill of materials (SBOM) in SPDX or CycloneDX format, scan it against a vulnerability database mirrored into that enclave, and sign both the image and the SBOM with a Sigstore Cosign key. The signature binds the image digest to a known build process. Each enclave runs its own registry – Harbor and zot are the common choices for disconnected operation – and each cluster's admission controller verifies the Cosign signature against an enclave-specific public key before allowing the image to run. An unsigned image, or one whose digest does not match the promoted record, never starts.

This matters across the boundary because the high-side cluster does not trust the low-side registry; it trusts the cryptographic signature and the digest recorded during promotion. Even if the low-side registry were compromised after an image was promoted, the high side would reject any substitute whose digest differs from the one it recorded.

Controlled promotion between domains

Promotion is the only sanctioned way an artifact crosses an enclave boundary, and it is strictly low-to-high. The path runs through an accredited cross-domain solution or, for the strictest links, a hardware data diode that physically permits transfer in one direction only.

The transfer guard does real work, not just a copy. It validates the image digest and Cosign signature against an allowlist of approved artifacts; it inspects the SBOM and rejects any image containing a prohibited component, an unapproved license, or a known-vulnerable package above the program's threshold; it strips or normalizes metadata that could carry hidden data; and it logs the transfer with the operator identity, timestamp, and artifact digest to an audit record on both sides. Only after every check passes is the artifact written to the high-side registry, where the high cluster can pull it.

High-to-low movement is the dangerous direction and is treated accordingly. Pulling logs, metrics, or build telemetry down from a Secret enclave to an Unclassified one is a potential spill, so it is either prohibited outright or routed through a separate, far stricter review with human adjudication of every record released. The default posture is that data flows up and stays up.

GitOps and operations without crossing the line

Each enclave runs its own GitOps controller – Argo CD or Flux – reconciling against a Git repository that lives inside that enclave. The desired-state manifests for the higher enclave are themselves artifacts that get promoted up through the cross-domain solution, reviewed the same way images are. This preserves the audit trail (the high-side repository records exactly what was promoted and by whom) without ever connecting a controller across the boundary.

Observability follows the same rule. Falco for runtime threat detection, the Kubernetes audit log, Prometheus metrics, and centralized container logs all run inside each enclave and feed an enclave-local SIEM. Telemetry never streams out of a high enclave to a low-side dashboard; if a fused, cross-level operational picture is genuinely required, it is built by exporting reviewed summaries up to the highest enclave, not by pulling raw telemetry down. Audit retention is set per enclave to meet that enclave's accreditation requirement, and continuous monitoring – vulnerability rescans against the in-enclave mirror, drift detection, periodic re-verification of image signatures – runs independently in each cluster.

What this costs, and why it is worth it

Running three independent clusters instead of one multi-tenant cluster is genuinely more work: three control planes to patch, three registries to populate, three identity providers, three GitOps pipelines, and a promotion process between them. Engineers feel the friction every time an image that works on the low side has to be promoted before it can run higher. But that friction is the security property, not a defect of it. The promotion gate is where provenance is verified, prohibited components are caught, and a complete, immutable record of what crossed the boundary is created. Collapsing the enclaves into one cluster to save effort would trade an accreditable, defensible architecture for a single shared kernel and API server standing between Unclassified and Secret – a trade no accreditor will accept and no program should want.

For teams that also have to keep the higher enclaves disconnected, the operational patterns pair naturally with an air-gapped Kubernetes practice: offline registries, mirrored dependencies, and an upgrade discipline that does not assume a live path to the outside world.