A sovereign Kubernetes container registry is a self-hosted, jurisdiction-controlled image store that allows a regulated organisation to pull, sign, scan and admit container images without creating a dependency on US-controlled infrastructure. For public-sector bodies, financial institutions, healthcare providers and legal organisations operating under the NIS-2 Directive, DORA and the Cyber Resilience Act, the registry is not a DevOps convenience: it is a compliance boundary.
The Jurisdictional Exposure Hidden in Every Image Pull
Every time a Kubernetes node pulls an image from Docker Hub, GitHub Container Registry or Amazon ECR, the organisation establishes a live dependency on a US-headquartered company subject to the CLOUD Act (18 U.S.C. § 2713) and FISA Section 702. Those statutes authorise US authorities to compel disclosure of data held on or transiting through that infrastructure, with no obligation to notify the affected European organisation or its national supervisory authority.
The risk is not hypothetical. ENISA’s Threat Landscape 2023 found that supply-chain attacks accounted for 17 percent of intrusions analysed, up from 1 percent in 2021, making the software supply chain one of the fastest-growing attack surfaces in European critical infrastructure. Beyond the threat of hostile actors, the jurisdictional problem is structural: a competent authority under NIS-2 or a DORA Joint Examination Team can ask an essential entity to demonstrate that no artefact in its production pipeline transits foreign-jurisdiction infrastructure. An organisation pulling images from a US-operated registry cannot give that assurance.
The Cyber Resilience Act (Regulation (EU) 2024/2847), which entered into force in December 2024, adds a further obligation through Article 13: manufacturers of products with digital elements must draw up a Software Bill of Materials (SBOM) covering all top-level dependencies. A container image is, by definition, a product with digital elements if it is placed on the EU market. Pulling a base image from Docker Hub without recording its full dependency tree in a machine-readable SBOM (CycloneDX or SPDX format) means the CRA SBOM obligation cannot be met.
Designing a Self-Hosted, Air-Gapped Registry Under NIS-2 Article 21
NIS-2 Article 21(2)(d) requires essential and important entities to address supply-chain security, including the security of relationships with direct suppliers and service providers. For containerised workloads, this requires a registry architecture that enforces provenance verification before any image reaches a production cluster.
Harbor as the Sovereign Registry Foundation
Harbor, a CNCF graduated project, is the most widely deployed self-hosted container registry in regulated environments. It provides role-based access control, project-level isolation, vulnerability scanning integration (via Trivy or Clair), and native support for image signing through its integration with Cosign. Crucially, Harbor can operate in a fully air-gapped mode: it serves images from its own local storage without any outbound connection to Docker Hub or any other public registry. For Swiss-hosted sovereign infrastructure, Harbor deployed on bare-metal servers under Swiss law eliminates US jurisdiction exposure at the registry layer entirely.
The Harbor project and replication policy model maps directly to NIS-2 Article 21 audit evidence requirements. Each project within Harbor maintains an immutable audit log of push, pull, delete and replication events. Those logs, exported to a sovereign SIEM, provide the time-stamped, tamper-evident record that a NIS-2 competent authority or a DORA third-party risk assessor will expect to see.
Image Signing with Sigstore and Cosign
Cosign, part of the Sigstore project under the OpenSSF and CNCF, signs container images using cryptographic keys and records signatures in an append-only transparency log called Rekor. In a sovereign deployment, both the Cosign signing keys (stored in a self-hosted Vault instance or an HSM) and the Rekor transparency log must be self-hosted. Relying on the public Sigstore infrastructure operated in the United States re-introduces the jurisdictional dependency that the sovereign registry was designed to eliminate.
The signing workflow should be enforced at the CI/CD pipeline level: no image may be pushed to Harbor unless it carries a valid Cosign signature from the organisation’s own key material. This produces a chain of custody from source code commit to running container that can be presented as audit evidence under both NIS-2 Article 21 and DORA’s ICT third-party risk framework.
Runtime Controls: OPA, Gatekeeper and Admission Controllers
Storing signed images in a sovereign Harbor registry is necessary but not sufficient. A Kubernetes cluster must be configured to reject any image that did not originate from the sovereign registry or does not carry a valid Cosign signature. This is where Open Policy Agent (OPA) and its Kubernetes-native integration, Gatekeeper, become essential.
OPA/Gatekeeper functions as an admission controller: every API server request to create or update a workload passes through Gatekeeper before it is admitted to the cluster. Policies expressed in Rego (OPA’s policy language) can enforce rules such as “all images must originate from registry.sovereign.example.eu” and “all images must carry a Cosign signature verifiable against key ID XYZ”. A violation causes the admission to be denied and logged. Those denial logs constitute the audit evidence that a NIS-2 competent authority needs to verify that tampered or externally sourced images cannot enter the cluster.
Sysdig’s 2023 Cloud-Native Security and Usage Report found that approximately 10 percent of publicly available container images on Docker Hub contained malicious content such as cryptominers or embedded secrets, underscoring why unsigned, unverified images from public registries represent a concrete rather than theoretical risk.
RBAC, Namespace Isolation and Zero-Trust East-West Control
Kubernetes Role-Based Access Control (RBAC), namespace isolation and NetworkPolicy objects are the three mechanisms that translate zero-trust microsegmentation principles into enforceable cluster configuration. For a DORA Joint Examination Team inspection, each of these must be documented, version-controlled and continuously reconciled against a known-good baseline.
| Control | Zero-trust function | DORA audit evidence required |
|---|---|---|
| RBAC policies | Limits which human users and service accounts can read, modify or delete workloads | Role bindings exported to SIEM; quarterly access review sign-off |
| Namespace isolation | Separates workloads by classification (e.g., production, staging, PII) at the API level | Namespace inventory with data-classification labels; change log |
| NetworkPolicy | Enforces default-deny east-west traffic; permits only declared service-to-service flows | NetworkPolicy manifests in version control; traffic flow logs from CNI plugin |
| OPA/Gatekeeper constraints | Prevents privileged containers, host-network access and image policy violations at admission | Constraint audit reports; admission denial logs with timestamps |
Sovereign Infrastructure Versus US Hyperscaler Managed Kubernetes
The control-plane data residency problem is the decisive compliance difference between self-managed Kubernetes on sovereign bare-metal or Swiss-hosted infrastructure and a managed service such as Amazon EKS, Google GKE or Azure AKS.
On a US hyperscaler, the Kubernetes API server, etcd (which stores all cluster state including secrets), and the control-plane audit logs run on infrastructure subject to US jurisdiction, regardless of which AWS or Azure region hosts the worker nodes. DORA Article 28 requires financial entities to ensure that ICT third-party service providers maintain data within agreed jurisdictions and that the entity retains full audit and inspection rights. An API server audit log stored in an AWS region in Frankfurt is still an AWS asset: it can be compelled under the CLOUD Act. Self-managed Kubernetes on sovereign infrastructure, whether on-premises or with a Swiss hosting provider operating under the revised Federal Act on Data Protection (revFADP), places the control plane entirely outside US jurisdiction. The IBM Cost of a Data Breach Report 2023 recorded an average total breach cost of USD 4.45 million, the highest figure in the report’s 18-year history, reinforcing the financial materiality of infrastructure decisions that affect breach exposure.
Sovereign DevSecOps: Scanning, SBOM Generation and CRA-Compliant Disclosure
A sovereign CI/CD pipeline must perform vulnerability scanning and SBOM generation without routing artefacts through US-controlled SaaS services such as Snyk (US-incorporated) or GitHub Advanced Security. Self-hosted alternatives that satisfy this requirement include Trivy (open-source, CNCF sandbox project) for vulnerability scanning and Syft (open-source, Anchore) for SBOM generation in CycloneDX or SPDX format.
The pipeline sequence for a CRA-compliant sovereign build is: source code committed to a self-hosted Gitea or GitLab instance; container image built in a self-hosted runner; Trivy scan run against the image before it is pushed; Syft SBOM generated and attached to the image as an OCI attestation; Cosign signature applied using HSM-backed key material; image pushed to Harbor along with its SBOM attestation and vulnerability scan report; OPA/Gatekeeper policy verified before the image may be deployed to any cluster namespace. The SBOM and scan report stored in Harbor constitute the documentary evidence required by CRA Article 13 and are available to competent authorities on request without any intermediary US-controlled SaaS platform being involved.
ENISA’s guidance on supply-chain security notes that “organisations that cannot verify the provenance of every artefact they deploy are operating with a blind spot that adversaries actively exploit.” The European Commission’s explanatory memorandum to the CRA reinforces this: “without a software bill of materials, you cannot manage what you cannot see.” Both statements point to the same operational conclusion: provenance verification must be automated, cryptographically enforced and stored in sovereign infrastructure.
FAQ
Why does pulling a container image from Docker Hub or Amazon ECR create a legal risk for a European regulated organisation?
Docker Hub is operated by Docker Inc. and Amazon ECR by Amazon Web Services Inc., both US companies subject to the CLOUD Act (18 U.S.C. § 2713) and FISA Section 702. These statutes can compel disclosure of data stored on or transiting through their infrastructure to US authorities without notifying the affected organisation or its national supervisory authority. Every image pull is a live dependency on US-controlled infrastructure, and any metadata generated during that pull may fall under US jurisdiction.
What exactly does NIS-2 Article 21 require for container workloads?
Article 21(2)(d) of Directive (EU) 2022/2555 requires essential and important entities to implement supply-chain security measures covering relationships with direct suppliers and service providers. For containerised workloads, this means verifying the integrity and provenance of every image deployed, maintaining a record of approved image sources, and demonstrating to the competent authority that untrusted or unsigned images cannot be admitted to the cluster.
What is an SBOM and what does the Cyber Resilience Act require for container images?
An SBOM is a machine-readable inventory of all software components, libraries and dependencies in a product or artefact. CRA Article 13 requires manufacturers of products with digital elements to produce an SBOM covering at least top-level dependencies. For container images, this means generating an SBOM at build time using a tool such as Syft, storing it alongside the image in Harbor as an OCI attestation, and making it available to competent authorities on request.
Can a regulated organisation use Amazon EKS or Azure AKS and still meet DORA requirements?
It is structurally difficult. The Kubernetes control plane of a managed US hyperscaler service, including the API server and etcd, resides on infrastructure subject to US jurisdiction. DORA Article 28 requires financial entities to ensure that ICT third-party providers maintain data within agreed jurisdictions and that full audit rights are retained. A DORA Joint Examination Team can require proof that control-plane access logs cannot be accessed by a non-EU authority. Self-managed Kubernetes on sovereign bare-metal or Swiss-hosted infrastructure provides a structurally cleaner answer to that requirement.
What is the role of Sigstore and Cosign in a sovereign registry and how does it differ from Docker Content Trust?
Cosign, part of the Sigstore project under the OpenSSF and CNCF, signs container images and records signatures in an append-only transparency log (Rekor). Unlike Docker Content Trust (Notary v1), Cosign can use short-lived OIDC-based certificates rather than long-lived private keys, reducing key-compromise risk. In a sovereign deployment, both the signing keys (in an HSM or self-hosted Vault) and the Rekor instance must be self-hosted to avoid re-introducing a dependency on the public Sigstore infrastructure operated in the United States.