Achieving data sovereignty for SaaS with confidential containers and quantum-safe networking

Independent software vendors (ISVs) that host services in the public cloud face growing scrutiny from customers who need assurance that their data remains secure when processed outside their direct control. This often leads customers to demand that vendors deploy services on premise, within infrastructure the customer owns and controls. However, this creates additional maintenance, scalability issues, intellectual property protection concerns, and increased complexity for the vendor.

A better approach is for the vendor to keep the service in the cloud while giving customers stronger security guarantees through cryptographic controls. Confidential computing is 1 example of a privacy-enhancing technology (PET) that protects sensitive data while it’s processed in an untrusted environment. Existing solutions provide hardware-backed security across central processing unit (CPU) and graphics processing unit (GPU) infrastructure, with cryptographic verification through attestation. This makes them suitable for use cases such as AI model training or processing sensitive data like personally identifiable information (PII) and protected health information (PHI).

Confidential computing is part of the solution, but other technologies are needed to provide full control over data security in the cloud:

• Data entering and leaving the trusted execution environment (TEE) must be safeguarded in transit, both between services and as it ingresses and egresses the environment.
• To be trusted, the confidential computing environment must be attested, or cryptographically verified, by an external authority.

In this blog post, Red Hat and Arqit present a confidential containers deployment with an external trust provider and quantum-safe networking. We demonstrate the architecture by applying it to Arqit Encryption Intelligence (EI), a multitenant Software-as-a-Service (SaaS) platform for automated cryptographic discovery and inventory (ACDI) running in a public cloud tenant. By isolating EI services and data from the underlying host, we keep customer data under the customer’s direct control and protect the vendor’s intellectual property, achieving data sovereignty on untrusted infrastructure.

A scalable architecture for confidential containers in public cloud

Arqit uses the Red Hat validated pattern for confidential containers as a base. It runs on Red Hat OpenShift with hardware that supports confidential computing. The deployment has 2 separate infrastructure environments:

• Arqit’s trusted on-premise environment, which hosts the root of trust and allows trust to be distributed to other environments.
• An untrusted environment with confidential computing hardware, running Red Hat OpenShift, confidential containers, the customer trustee, and associated services.

In the untrusted environment, we run 3 separate clusters:

• A central Arqit management cluster, which hosts management services and the administration user interface (UI).
• An Arqit customer trustee cluster, which contains trustee services such as the key broker service, reference value provider service, and attestation service.
• The customer-owned environment, where customers run their own workloads and an Arqit service.

The clusters are connected using hybrid Transport Layer Security (TLS) with quantum-safe cryptography, providing quantum-safe connectivity between them.

Figure 1: An overview of the architecture showing the different clusters and the infrastructure they run on. The 3 clusters on the left all run on confidential computing hardware and are, therefore, isolated from the host environment. The Arqit root-of-trust cluster on the right runs in a trusted on-prem environment.

Centralized management services for multiple customer environments

The Arqit management cluster contains essential services for end customers, including a UI for overseeing managed containers and viewing attestation information about running containers. This reassures customers about the confidentiality of their environment and supports ongoing monitoring and controls, such as killing containers that drift from policy.

Providing trust to a trustee hosted in the cloud

In a traditional deployment of confidential containers, there’s a single trustee service that provides several important services for the cluster:

• An attestation service that can prove a container is running in a TEE
• Management of policies including attestation and resource policies
• Management of secrets, controlling which services may access them
• Storage of reference values used to determine the authenticity of a TEE

This service helps make sure only properly instantiated confidential environments run sensitive workloads or process sensitive information. However, if the trustee runs on untrusted infrastructure, it must also run inside a TEE to safeguard its integrity. This creates a cyclic dependency as the trustee can’t attest its own TEE.

We solve this problem by introducing an inner and outer trustee. The outer trustee runs outside confidential computing on trusted infrastructure in Arqit’s on-premise environment. This provides a trusted anchor point that distributes trust to the inner trustee running in the cloud. As a result, we can host most management services in the public cloud while still providing an independent source of trust.

Quantum-safe networking protects data in transit

To prevent data being decrypted to plaintext at the container boundary, we use network security based on quantum-safe cryptography. A hybrid TLS implementation—classical Elliptic Curve Diffie-Hellman (ECDH) with additional Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) post-quantum cryptographic (PQC) key exchange—terminates the transport layer within the TEE boundary, making sure data is never available in plaintext to the host environment. This protects data between containers and clusters, and between the on-premise and cloud environments.

Use case: Encryption Intelligence (EI) SaaS platform

To demonstrate the feasibility of this architecture in a real-world deployment, we apply it to Arqit EI, a multitenant SaaS application deployed on public cloud Platform-as-a-Service (PaaS) where both Arqit and its customers need to isolate workloads and data from the cloud host. EI discovers, classifies, and analyzes encryption usage and vulnerabilities within enterprise traffic flows, helping customers understand and remediate cryptographic risk, particularly post-quantum vulnerabilities. A locally deployed probe in the user’s network collects data and sends it to a centralized cloud platform running in a cloud service provider. The data is highly sensitive and an important asset that both Arqit and its customers need to protect.

Customers need assurance that sensitive network information, such as IP addresses and ciphers, remains under their control while it’s sent to the cloud and processed. Instead of deploying a separate EI instance on each customer’s premises, Arqit can use the architecture outlined in the previous paragraph to run a single cloud instance while still providing data sovereignty assurance. The following steps outline how data is protected during the platform’s build, deployment, and management:

1. When the EI SaaS platform is first instantiated, services such as the UI and database are deployed as confidential containers. As part of confidential containers, images from the container registry are verified as properly encrypted and decrypted only inside confidential containers. This protects Arqit’s intellectual property by preventing the cloud service provider from accessing the keys used to encrypt and decrypt the images or the running workload.
2. The platform services boot within the TEE and submit attestation evidence to the trustee. Secrets are released to a container only after the trustee verifies that it’s running as a confidential workload.
3. As part of the service deployment, an Arqit service is created inside a confidential container in the customer-owned cluster. It communicates with the Arqit management cluster and shares information about the state of containers in the customer-owned cluster. In the future, this service could support additional functions such as policy enforcement or activating a kill switch on running containers if they drift from policy.
4. The local network probe collects data from the customer’s local network environment and encrypts it using a quantum-safe, hybrid TLS tunnel.

Figure 2: A step-by-step overview of how data is protected during the platform’s build, deploy, and manage stages. Step 1 shows images from the container registry being sent encrypted to the cloud environment and decrypted only within the secure enclave. Step 2 shows the trustee services releasing secrets to the services only once they’ve been attested. Step 3 shows the Arqit agent, deployed within the confidential containers environment, sharing information with the trustee about the state of the cluster. Step 4 shows local probes from Arqit EI transmitting data to the cluster using a hybrid-TLS tunnel that’s terminated within the enclave boundary.

Together, these steps keep customer data encrypted from the moment it leaves the customer’s environment using keys that remain under the customer’s control. They also protect the vendor’s service by isolating it from the underlying host.

Maintain cloud functionality without ceding sovereignty

We have shown how the Red Hat validated pattern for confidential containers can be applied to SaaS running in a public cloud. Adding quantum-safe networking between the customer’s environment and the cloud helps keep data from being visible to the infrastructure provider and remain under the customer’s control. This benefits both the vendor and the customer: The vendor can retain public cloud functionality, protect its intellectual property, and scale to multiple tenants, while the customer maintains data sovereignty.

This practical implementation of confidential containers, combined with quantum-safe protection for data in transit, offers a viable alternative to on-premise deployment. It gives vendors and end customers strong assurance over the security and sovereignty of their data and workloads.