Sovereign cloud for defense ministries: data residency, control planes and national cloud architecture

By Corvus Intelligence Engineering Team · About the team →

June 25, 2026 Updated: June 25, 2026 12 min read

Every defense ministry that has moved workloads to the cloud eventually confronts the same tension: commercial hyperscalers provide capabilities — managed databases, AI/ML platforms, global networking — that no national provider can match, yet the same hyperscalers are foreign corporations subject to their home government's legal process, export controls, and intelligence community access demands. The term "sovereign cloud" describes the attempt to resolve that tension without accepting either extreme: neither full hyperscaler dependency nor a technology-frozen national mainframe. The architecture that results is never simple, and the tradeoffs are rarely obvious until they have already been made in production.

This article examines the technical architecture of sovereign cloud for defense ministries — not as a procurement checklist but as an engineering problem. We cover what sovereignty actually means in each of its three dimensions, how to design a national control plane that survives vendor disruption, which hyperscaler components introduce unacceptable sovereignty risk, what the open-source sovereign stack looks like in production, and how to balance sovereignty constraints with the operational capability demands of modern defense. For context on the broader workload security requirements, see our guide on military workload cloud security.

1. What cloud sovereignty means for a defense ministry

The phrase "sovereign cloud" is used by vendors to mean almost anything — an in-country datacenter, a contractual data residency commitment, a local legal entity — and almost nothing it means in vendor marketing is sufficient for a serious defense ministry architecture review. Genuine cloud sovereignty for defense encompasses three distinct requirements that must be evaluated independently because satisfying one does not imply satisfying the others.

Data residency is the guarantee that classified or sensitive data is stored, processed, and transmitted exclusively within national territory or an approved jurisdictional boundary — and that the ministry, not the cloud vendor, controls the encryption keys that protect it. Data residency is the most commonly discussed sovereignty requirement and the easiest to fake: a contractual commitment that data will remain in-country is legally unenforceable against a foreign government's intelligence subpoena and provides no technical protection against a misconfigured replication job that copies data to an out-of-country availability zone.

Operational sovereignty is the ability to continue operating the cloud platform without the continued cooperation of any foreign vendor — including the ability to survive vendor bankruptcy, commercial sanctions, export control changes, or a foreign government compelling the vendor to deny or degrade service. Operational sovereignty requires that the ministry can operate every component of the platform from documentation and source code alone, with no ongoing dependency on proprietary vendor support that could be withdrawn.

Supply-chain sovereignty is control over the software and hardware components used to build and operate the cloud. A platform built on auditable open-source software running on servers from a non-allied manufacturer satisfies neither dimension: the software layer may be auditable but the hardware firmware may not be. A complete supply-chain sovereignty analysis covers processor firmware, network device operating systems, storage controller firmware, and the software library dependencies of every component in the sovereign stack.

Most defense ministry sovereign cloud architectures today satisfy data residency partially, operational sovereignty partially, and supply-chain sovereignty minimally. The purpose of making the three dimensions explicit is to enable honest risk assessment rather than false assurance from a "sovereign cloud" certification that addresses only the most visible dimension.

2. Data residency enforcement

Technical data residency controls operate at three layers: encryption key residency, data location policy enforcement, and audit and verification. All three are required; any one alone is insufficient.

Encryption key residency is the most important technical control because it determines whether data can be decrypted outside the approved boundary even if it is physically exfiltrated. The requirement is that the hardware security module (HSM) or key management service (KMS) holding the data encryption keys must be physically located within national territory and under the operational control of the ministry or a nationally accredited organization — not a foreign cloud provider's managed KMS where the ultimate key material is held in hardware the provider controls. In practice this means:

On-premises HSM (Thales Luna, Utimaco SecurityServer, or equivalent) for the highest classification tiers, with the HSM physically secured and audited under ministry physical security policy
National cloud provider KMS backed by in-country HSM hardware for lower classification tiers where managed key services are acceptable
Envelope encryption: data encryption keys (DEKs) are generated per-object or per-volume and encrypted with key encryption keys (KEKs) held in the HSM — the HSM never holds raw data, only key material
Key access logging that is separate from and independent of the storage system audit log, so that unauthorized key access attempts are visible even if the storage layer is compromised

Data location policy enforcement requires that storage services — object storage, block volumes, database instances — are constrained to in-country availability zones at the platform configuration level, not merely by policy statement. In an OpenStack deployment, this means configuring availability zone affinity rules in Cinder and Swift that prevent replica placement outside the defined zone. In a hyperscaler deployment, this means using service control policies (AWS) or Azure Policy definitions that deny any storage resource creation in out-of-country regions, applied at the management account or management group level so that individual workload teams cannot override them.

Audit and verification is the continuous operational process that confirms data residency controls are functioning as designed. The audit layer must be independent of the storage layer — the entity that stores data cannot be the only entity that verifies where data is stored. Required components:

Automated daily verification that all storage endpoints in use by workloads resolve to in-country IP addresses, with alerting on any new endpoint
Network flow monitoring that flags any egress traffic to out-of-country IP ranges from storage services
Quarterly third-party technical audit of data residency controls, with findings reported to the ministry's security authority
Configuration-as-code for all data location policies, version-controlled in an immutable repository, so that policy changes generate a detectable diff before taking effect

Contractual controls — data processing agreements, data localization clauses — are a necessary complement to technical controls but should never be the primary mechanism. Contracts constrain what a cooperative vendor will do; they do not constrain what a vendor does under legal compulsion from their home government, and they provide no protection against technical misconfiguration.

3. National control plane design

The control plane of a cloud platform — the set of services that manage orchestration, identity, and secrets — is where the highest-impact sovereignty risk lives. In a Kubernetes environment, the control plane components are the API server, etcd cluster, scheduler, controller manager, and the admission webhooks that enforce policy at workload creation time. If any of these components runs on infrastructure managed by a foreign hyperscaler's operations staff, those staff have the technical ability (even if contractually prohibited) to modify workload configurations, extract secrets from etcd, or disrupt scheduling at the instruction of their home government.

A national control plane design places all of these components on infrastructure that is physically and organizationally under the ministry's control. The practical architecture:

Kubernetes API server and etcd. Deploy a self-managed Kubernetes distribution — kubeadm for maximum flexibility, k0s for simplified operations, or Talos Linux for an immutable OS approach — on baremetal or VMs running on ministry-controlled hypervisors. The etcd cluster requires three or five nodes for quorum, running on dedicated hardware that is not shared with workload nodes. Etcd data must be encrypted at rest using the KMS provider plugin connected to the national HSM. Back up etcd snapshots to encrypted in-country object storage with automated restoration testing.

# Example kube-apiserver flag for national KMS encryption provider
--encryption-provider-config=/etc/kubernetes/encryption-config.yaml

# encryption-config.yaml (excerpt)
resources:
  - resources: [secrets, configmaps]
    providers:
      - kms:
          name: national-hsm-kms
          endpoint: unix:///var/run/kmsplugin/socket.sock
          cachesize: 1000
          timeout: 3s
      - identity: {}

Identity provider. Keycloak is the standard open-source OIDC/SAML identity provider for sovereign cloud deployments. Deploy Keycloak on dedicated national infrastructure, integrated with the ministry's existing directory (Active Directory or LDAP via Keycloak's federation connectors). Configure the Kubernetes API server to use Keycloak as its OIDC authenticator:

# kube-apiserver OIDC flags
--oidc-issuer-url=https://keycloak.national.mil/realms/defense
--oidc-client-id=kubernetes
--oidc-username-claim=preferred_username
--oidc-groups-claim=groups
--oidc-ca-file=/etc/kubernetes/pki/keycloak-ca.crt

Keycloak's availability is now critical-path for cluster authentication. Deploy in high-availability mode (minimum three Keycloak instances behind an internal load balancer, with a distributed cache for session state) and document the emergency break-glass procedure for API server access when Keycloak is unavailable — typically a local kubeconfig with a client certificate for emergency cluster-admin access, stored in a physically secured location.

Secrets management. HashiCorp Vault (or its open-source fork OpenBao) deployed on national infrastructure provides the secrets management layer. Vault auto-unseals using the national HSM, eliminating the manual unseal process that would otherwise be a single-point-of-failure for control plane recovery. Vault's audit log — every secret read and write — is shipped in real time to the national SIEM, outside the blast radius of a compromised Vault deployment.

4. Hyperscaler dependency assessment

Most defense ministry cloud environments use at least one hyperscaler for some tier of their infrastructure — whether for a sovereign-connected topology, a disaster recovery zone, or legacy workloads not yet migrated. Understanding which hyperscaler components introduce sovereignty risk is essential for making the managed-vs-self-operated decision for each component.

High sovereignty risk — should be replaced or operated independently:

Managed Kubernetes control planes (EKS, AKS, GKE) — the API server and etcd are operated by hyperscaler staff with privileged access; replace with self-managed Kubernetes on IaaS primitives
Managed identity providers (AWS IAM, Azure Active Directory as primary IdP) — authoritative identity assertions made by foreign-operated services; replace with Keycloak or equivalent on national infrastructure
Managed secret stores (AWS Secrets Manager, Azure Key Vault with hyperscaler-controlled HSMs) — key material held in foreign HSMs; replace with self-managed Vault on national HSM
Global CDN and edge networks — traffic routed through out-of-country points of presence; disable or restrict to in-country edge nodes only

Medium sovereignty risk — acceptable with additional controls:

Hyperscaler object storage in an in-country availability zone — acceptable if encrypted with ministry-controlled keys from a national HSM, with replication locked to in-country zones
Hyperscaler managed databases in in-country zones — acceptable for unclassified data if encryption key management is national, with cross-region replication disabled
Hyperscaler virtual networking — VPCs, subnets, security groups are low-risk IaaS primitives; the sovereignty risk is in the control plane that manages them, not the primitives themselves

Lower sovereignty risk:

IaaS compute (VMs) with no managed agent frameworks — hyperscaler provides the hardware; ministry operates the software stack and controls all encryption
Block storage with customer-managed keys from a national KMS — the hyperscaler holds encrypted blocks that cannot be decrypted without the ministry-held key

The assessment outcome is a component-level risk map, not a binary "use hyperscaler" or "don't use hyperscaler" decision. Most sovereign cloud architectures will retain some hyperscaler components at the IaaS layer while replacing control plane and identity components with national alternatives. For a broader view of deployment models and their classification implications, see our article on classified cloud deployment models.

5. Architecture patterns: sovereign-connected vs air-gapped sovereign

Two primary architecture patterns exist for sovereign cloud deployments, with substantially different cost, capability, and operational complexity profiles.

Sovereign-connected topology uses a hyperscaler's in-country datacenter availability zone as the IaaS layer, with the ministry operating its own control plane (Kubernetes, Keycloak, Vault) on top of the hyperscaler's compute and storage primitives. The hyperscaler provides hardware refresh cycles, datacenter operations, and physical security; the ministry provides software operations, encryption key management, and all control plane components.

This topology gives the ministry access to the hyperscaler's economies of scale, hardware reliability, and managed storage and database services (with appropriate controls), while maintaining operational sovereignty at the software layer. The sovereignty gap is the physical hardware layer: the hyperscaler's datacenter technicians have physical access to the servers, and the hyperscaler's supply chain determines which hardware is available. For most defense ministries outside the highest-risk threat environments, this is an acceptable residual risk — provided the encryption and control plane architecture means that physical hardware access does not yield plaintext data or control plane access.

The sovereign-connected topology also enables burst capacity: when the ministry's national cloud infrastructure is at capacity, workloads can overflow to the hyperscaler's in-country zone without crossing jurisdictional boundaries. This makes it the practical choice for ministries that need to meet both sovereignty requirements and modern capability demands without the capital expenditure of sizing national infrastructure for peak load.

Fully national cloud eliminates the hyperscaler dependency entirely. All physical infrastructure — servers, networking equipment, storage arrays, and the datacenter that houses them — is procured, owned, and operated by the ministry or a nationally accredited organization. OpenStack provides the IaaS layer on top of this hardware; Ceph provides distributed storage; Kubernetes provides orchestration.

The tradeoffs are significant. Capital expenditure is substantially higher than a sovereign-connected topology. Procurement cycles for servers and network equipment are long — typically 12-24 months from requirement to operational capability. Hardware refresh requires new procurement cycles. Operational staffing requirements are much larger: running OpenStack, Ceph, Kubernetes, and Keycloak in production requires a team with deep expertise in all four components that is very difficult to staff at government compensation levels. And the capability gap relative to hyperscalers widens over time as hyperscalers invest heavily in managed AI/ML, data analytics, and serverless platforms.

Fully national cloud is the correct choice for the highest-classification workloads, workloads with hard air-gap requirements (no physical or network connection to commercial infrastructure), and capabilities where supply-chain sovereignty at the hardware layer is a firm requirement. It is not the right choice for the general workload portfolio of a modern defense ministry — the operational complexity and capability gap are too high a cost to pay for sovereignty requirements that a well-designed sovereign-connected topology can satisfy.

6. Open-source sovereign stack

The canonical open-source sovereign cloud stack for defense is built on four components that together provide the full IaaS, storage, orchestration, and identity platform with no proprietary dependencies and fully auditable source code.

OpenStack is the IaaS layer: Nova for compute, Neutron for virtual networking, Cinder for block storage, Swift for object storage, Glance for image management, Keystone for service identity and catalog. OpenStack has a 15-year production history in telco, government, and scientific computing environments. The operational complexity is real — OpenStack deployments require a dedicated platform team and careful change management — but the ecosystem of operators, integrators, and documentation is mature. The Kolla-Ansible deployment tooling makes initial deployment manageable; the ongoing operational challenge is upgrade management, which must be planned carefully in a defense environment where change control processes are slow.

Ceph is the distributed storage backend. It provides block storage (RBD) for Cinder volumes, object storage (RGW) for Swift-compatible APIs, and a shared filesystem (CephFS) for workloads that require POSIX semantics. Ceph's architecture distributes data across all nodes in the cluster with configurable replication factors, providing resilience against individual node or disk failures without proprietary storage arrays. The operational complexity centers on performance tuning — Ceph requires careful hardware selection (NVMe SSDs for OSD journals, high-bandwidth networking between nodes) and ongoing performance monitoring to avoid the "slow OSD" cascades that can degrade cluster performance under heavy write load.

Keycloak is the identity provider. It supports OIDC, SAML 2.0, OAuth 2.0, and LDAP/AD federation, making it the integration point for all authentication in the sovereign stack: Kubernetes API server authentication, OpenStack Keystone identity federation, Vault JWT authentication, and human user authentication. Keycloak's administration UI and REST API provide the operational tooling for user management, group management, and client (application) registration. The high-availability deployment model — multiple Keycloak instances sharing an Infinispan distributed cache and a shared PostgreSQL database — is well-documented and production-proven.

Kubernetes is the container orchestration layer. Deployed with kubeadm or Talos Linux on OpenStack Nova compute instances, Kubernetes provides the workload scheduling, service discovery, and configuration management layer that application teams consume. The key architectural requirement for the sovereign stack is that the Kubernetes distribution must be upstream-compatible — not a managed hyperscaler variant — so that the control plane remains under ministry control. For container networking, Cilium is the preferred CNI for defense environments because of its eBPF-based policy enforcement and deep observability without a sidecar proxy. For storage integration, the Ceph CSI driver provides the integration between Kubernetes PersistentVolumes and Ceph RBD.

The operational complexity of this stack should not be underestimated. Running OpenStack, Ceph, Kubernetes, and Keycloak in production requires specialist expertise in all four components, which is difficult to recruit and retain in government organizations. Realistically, a ministry deploying this stack needs either a large internal platform team (20+ engineers for a medium-scale deployment) or a contracted sovereign integrator with deep expertise in all four components. The alternative — reducing operational complexity by adopting a managed hyperscaler service for some components — must be evaluated against the sovereignty requirements it compromises. For the security controls that must run on top of this stack, see our article on CSPM for defense cloud.

7. Balancing sovereignty with modern cloud capabilities

The hardest architectural problem for defense ministry sovereign cloud is not the sovereignty controls themselves — it is maintaining those controls while providing the modern cloud capabilities that defense organizations increasingly require: AI/ML model training and inference, real-time data analytics, serverless event-driven architectures, and global collaboration platforms. Hyperscalers have invested billions in managed versions of these capabilities that the open-source sovereign stack cannot match on a decade timescale.

IaC portability through Terraform provider abstraction is the most practical mechanism for managing this tension. The strategy is to define all infrastructure in provider-agnostic Terraform modules — internal abstractions that accept consistent inputs and produce consistent outputs regardless of whether the underlying provider is OpenStack, AWS, or Azure. The module interface for a "compute cluster" is the same whether it deploys to OpenStack Nova or AWS EC2; only the provider binding changes. This abstraction preserves the option to migrate workloads between the sovereign national stack and a sovereign-connected hyperscaler zone without re-architecting the application infrastructure.

# Example provider-agnostic compute module interface
module "compute_cluster" {
  source        = "internal/modules/compute-cluster"
  name          = "sensor-processing"
  instance_type = "c5.4xlarge"  # resolved per provider
  count         = 3
  subnet_id     = module.network.private_subnet_id
  security_groups = [module.security.workload_sg_id]
  user_data     = file("cloud-init/sensor-processor.yaml")
}

# Bind to provider via workspace variable
# terraform.tfvars.national:  provider = "openstack"
# terraform.tfvars.govcloud:  provider = "aws-govcloud"

Managed service alternatives for the most strategically important capability gaps:

AI/ML training: On-premises GPU clusters running Kubeflow or MLflow, procured from vendors with acceptable supply-chain posture; sovereign-connected burst to hyperscaler in-country GPU instances for training jobs that exceed on-premises capacity
Data analytics: Apache Spark on Kubernetes (via the Spark operator) replaces managed analytics services; ClickHouse or Apache Druid for real-time analytical query workloads
Managed databases: Operators for PostgreSQL (CloudNativePG), Redis (Redis Operator), and Kafka (Strimzi) provide managed-service-like operational experience on self-managed Kubernetes
Observability: Prometheus, Loki, and Grafana provide the metrics, logging, and visualization stack without proprietary managed observability dependencies

Capability roadmap for sovereign cloud must be treated as a living program, not a one-time deployment. The gap between sovereign stack capabilities and hyperscaler managed services is real but not static — the open-source ecosystem produces new sovereign alternatives to proprietary managed services continuously. A structured capability review every six months — comparing current sovereign stack capabilities against current operational requirements and current hyperscaler alternatives — allows the ministry to prioritize which gaps to close through open-source adoption, which to close through sovereign-connected access to hyperscaler in-country services, and which to accept as residual capability constraints in exchange for sovereignty guarantees.

Key insight: Sovereign cloud for defense ministries is not a product that can be purchased — it is an architectural posture that must be designed, built, operated, and continuously maintained. The ministries that succeed at it treat sovereignty as a first-class engineering requirement alongside performance, reliability, and cost, make explicit tradeoffs between sovereignty dimensions and capability, and build the operational capability to run the sovereign stack at production quality. Those that treat it as a compliance checkbox — acquiring a "sovereign cloud" vendor certification without assessing whether the technical controls actually deliver data residency, operational sovereignty, and supply-chain sovereignty — will discover the gap when a geopolitical disruption or vendor policy change exposes it.

Sovereign cloud for defense ministries is ultimately a risk management decision, not a technology decision. The architecture described here — national control plane, data residency technical controls, open-source sovereign stack, Terraform provider abstraction for portability — is a set of tools for managing a specific set of risks. The right architecture for any given ministry depends on which risks are most material in its threat environment, what operational capability is realistically maintainable with available staffing and budget, and where on the sovereignty-capability tradeoff curve its classified workload requirements land. Getting that calibration right requires honest threat assessment and engineering judgment — not vendor assurance.

Discuss Your Project

We design and build sovereign cloud architectures for defense ministries — from national control plane deployment and data residency enforcement to open-source stack operations and IaC portability.

Secure Cloud Services → Book a Briefing

This analysis was prepared by Corvus Intelligence engineers who build mission-critical software for defense and government organizations. Learn about our team →

Frequently Asked Questions

What is cloud sovereignty for a defense ministry?

Cloud sovereignty for a defense ministry encompasses three distinct but related requirements. Data residency is the legal and technical guarantee that classified or sensitive data is stored, processed, and transmitted exclusively within national territory or approved jurisdictions — and that the ministry, not a vendor, controls the encryption keys. Operational sovereignty is the ability to continue operating the cloud platform independently of any foreign vendor's continued cooperation, licensing, or service availability, including the ability to survive sanctions, vendor bankruptcy, or geopolitical disruption. Supply-chain sovereignty is control over the software and hardware components used to build and operate the cloud — ensuring that no foreign government can compel a vendor to insert backdoors or deny service. A genuinely sovereign cloud for defense must address all three dimensions simultaneously; architectural choices that satisfy data residency but sacrifice operational or supply-chain sovereignty provide weaker protection than they appear on paper.

What is data residency enforcement in a defense cloud context?

Data residency enforcement in defense cloud means implementing technical controls that make it physically and cryptographically impossible — not merely contractually prohibited — for data to leave the defined geographic or jurisdictional boundary. The key layers are: encryption key residency (the HSM or KMS holding the data encryption keys must be physically located in-country and under national control, so data encrypted with those keys cannot be decrypted outside the boundary even if physically exfiltrated); data location policies enforced at the storage layer (object storage, block volumes, and database replicas must be constrained to in-country availability zones); network egress controls (firewall rules and DNS policies that block data paths to out-of-country endpoints); and audit and verification (continuous monitoring that data-at-rest and data-in-motion controls have not been bypassed, with tamper-evident logs reviewed by the ministry's own security operations team rather than the vendor's).

What is a national control plane and why does it matter?

The control plane of a cloud platform is the set of services that manage workload orchestration, identity, and secrets — in a Kubernetes environment this is the API server, etcd, scheduler, and controller manager; in a broader cloud context it includes the identity provider, the secrets management system, and the management APIs. If the control plane runs on infrastructure managed by a foreign hyperscaler, the hyperscaler's operations staff have the ability — in principle — to modify workload configurations, extract secrets, or disrupt operations at the instruction of their home government. A national control plane runs these components on infrastructure that is physically and organizationally under the ministry's control, eliminating that dependency. Even when using a hyperscaler's in-country datacenter, a national control plane means the Kubernetes API server, etcd cluster, and identity provider run on ministry-owned or ministry-controlled hardware, with the hyperscaler providing only compute, network, and storage primitives.

Which hyperscaler components introduce the greatest sovereignty risk?

The highest-risk hyperscaler components for a defense ministry are: managed Kubernetes control planes (EKS, AKS, GKE) where the API server and etcd run on hyperscaler infrastructure and hyperscaler operations staff have privileged access; managed identity providers where the authoritative identity assertion is made by hyperscaler-controlled services; global CDN and edge caching layers that route traffic through out-of-country points of presence; cross-region replication features that may copy data to availability zones outside the approved jurisdiction; and managed secret stores whose key material is ultimately held in hyperscaler-controlled HSMs. Hyperscaler IaaS components — raw compute, block storage, and virtual networking with no managed control plane — introduce significantly lower sovereignty risk because the ministry operates the software stack on top of them and controls all encryption keys independently.

What is the difference between sovereign-connected and fully national cloud?

Sovereign-connected topology uses a hyperscaler's in-country datacenter with a ministry-controlled control plane running on top. The hyperscaler provides IaaS — compute, storage, networking — but all orchestration, identity, and secrets management layers are operated by the ministry or a trusted national integrator. This gives access to hyperscaler economies of scale and managed services at the cost of ongoing dependency on the hyperscaler's hardware operation and supply chain. A fully national cloud eliminates the hyperscaler dependency entirely — all physical infrastructure is procured, owned, and operated by the ministry or a national sovereign provider. The tradeoffs are significantly higher capital expenditure, longer procurement cycles, greater operational complexity, and a capability gap relative to hyperscaler managed services — but maximum operational and supply-chain sovereignty.

What open-source components form the core of a sovereign cloud stack?

The canonical open-source sovereign cloud stack consists of: OpenStack for IaaS (compute via Nova, object storage via Swift, block storage via Cinder, networking via Neutron, image management via Glance, identity via Keystone); Ceph as the distributed storage layer backing OpenStack Cinder volumes and Swift object storage; Kubernetes as the container orchestration layer deployed with an upstream distribution (not a managed hyperscaler variant) so the API server and etcd remain under ministry control; and Keycloak as the identity provider for both human users (via OpenID Connect and SAML) and workloads (via OAuth 2.0 client credentials). Together these four components provide the full cloud platform stack with no proprietary dependencies. The operational complexity is substantially higher than using managed hyperscaler services, and the ministry must maintain the expertise to operate and patch every component — but the sovereignty guarantees are absolute because every component's source code is auditable and no foreign vendor has privileged operational access.

How does Terraform support portability across sovereign cloud environments?

Terraform's provider abstraction allows infrastructure to be described in provider-agnostic modules, with provider-specific implementations swapped at the root module level. A sovereign cloud portability pattern defines internal module interfaces — a compute cluster module, a managed database module, an object storage bucket module — that accept the same inputs and produce the same outputs regardless of whether the underlying provider is an OpenStack deployment, a national cloud provider, or a hyperscaler in-country zone. When the ministry needs to migrate from one underlying platform to another because of vendor risk, regulatory change, or capability evolution, only the provider binding changes — the workload module definitions, deployment pipelines, and infrastructure tests remain unchanged. The practical limit of this portability is managed services: a module that wraps a hyperscaler-specific managed database service cannot be trivially ported to OpenStack without replacing the underlying service with an equivalent self-managed deployment.

What are the key risks of sovereign cloud for a defense ministry?

The primary risks are: capability gap (national cloud providers and open-source stacks often lag hyperscalers by several years in managed AI/ML services, serverless platforms, and global network performance — this constrains the modern capability roadmap); operational complexity (running OpenStack, Ceph, Kubernetes, and Keycloak internally requires deep expertise that is difficult to recruit and retain in government); supply-chain risk in hardware (servers, network equipment, and storage hardware sourced from non-national suppliers carry their own supply-chain sovereignty risks — even a fully national cloud can be compromised at the hardware layer); and false sovereignty (a cloud that satisfies data residency on paper but has hyperscaler operations staff with privileged access, or uses foreign HSMs for key management, provides weaker guarantees than its architecture documentation suggests). Risk management requires treating sovereignty as a spectrum with multiple independently verifiable dimensions rather than a binary certification.

How should classified and unclassified workloads be separated in a sovereign cloud?

Classified and unclassified workloads must be separated at the physical layer — separate Kubernetes clusters running on separate node pools with no shared etcd, no shared control plane, and no shared networking infrastructure between classification tiers. Logical separation within a single cluster (namespace isolation, NetworkPolicy) is insufficient for workloads at different classification levels because a control-plane vulnerability or container escape can cross namespace boundaries. In practice, this means separate OpenStack tenants with physically separate Ceph storage clusters for each classification tier, separate Keycloak realms or entirely separate identity providers, and separate CI/CD pipelines with separate signing keys so that a compromise of the unclassified build pipeline cannot introduce malicious images into the classified tier. Cross-domain data transfer between tiers must go through a formally evaluated cross-domain solution, not through network connectivity.

What should a defense ministry's capability roadmap for sovereign cloud look like?

A realistic sovereign cloud capability roadmap for a defense ministry has three phases. Phase 1 (years 1-2) establishes the foundation: deploy the national IaaS layer (OpenStack or equivalent), migrate workloads from commercial cloud to in-country infrastructure, implement data residency controls and national key management, and deploy the national Kubernetes control plane. Phase 2 (years 2-4) builds the platform layer: deploy Keycloak for federated identity, implement Terraform-based IaC with provider abstraction, build an internal container registry with supply-chain controls (image signing, vulnerability scanning), and establish a sovereign-connected topology with a hyperscaler in-country zone for burst and resilience. Phase 3 (years 4+) targets capability parity: build or procure sovereign managed database and analytics services, deploy on-premises AI/ML training infrastructure, implement zero-trust architecture across all tiers, and establish a continuous compliance automation framework covering all components of the sovereign stack.