Our strategic shift in confidential Kubernetes

At Edgeless Systems, we've made a significant strategic decision: we're discontinuing active development of Constellation and focusing our efforts entirely on Contrast, our confidential containers platform, and Privatemode, our confidential AI inference service that runs on top of it. This shift reflects a fundamental evolution in our understanding of how confidential computing can best serve the cloud-native ecosystem. In this post, we'll explain the technical reasoning behind this decision and why we believe the confidential containers approach better addresses the needs of modern cloud deployments.

Two approaches to combine confidential computing with Kubernetes

Both Constellation and Contrast leverage confidential computing to protect k8s workloads from the underlying infrastructure, but they take fundamentally different architectural approaches.

Constellation: Confidential Cluster

Constellation implements what we call "Confidential Cluster", a whole-cluster approach where the entire Kubernetes cluster, including the control plane and all worker nodes, runs inside Confidential Virtual Machines (CVMs). The three defining properties of this approach are:

1. Workload shielding: Runtime encryption for all workload-related data and code
2. Control plane shielding: Protection of the cluster's control plane, state, and workload configuration
3. Attestation and verifiability: Remote verification based on hardware-rooted cryptographic certificates

Constellation achieves this by:

• Running all Kubernetes nodes inside CVMs with runtime encryption
• Implementing transparent network and storage encryption
• Managing cryptographic keys inside CVMs
• Verifying the integrity of each new node using remote attestation
• Providing "whole cluster" attestation through a single hardware-rooted certificate

This creates a single, coherent confidential context that wraps the entire cluster. The infrastructure provider, including datacenter employees, cloud admins, and potential attackers coming through the infrastructure, are completely removed from the trusted computing base (TCB).

Contrast: Confidential Containers

Contrast takes a different approach, operating at the pod level rather than the cluster level. Built on the Kata Containers and Confidential Containers projects, Contrast runs individual pods inside confidential micro-VMs while the Kubernetes control plane remains in the standard infrastructure.

Key characteristics of Contrast's architecture:

• Pod-level isolation: Each confidential pod runs in its own isolated micro-VM with hardware-based protection
• Managed Kubernetes compatibility: Works with existing managed Kubernetes services like AKS, with future support for EKS and GKE
• Day-2 operations: Can be installed into existing clusters without requiring a complete cluster rebuild
• Heterogeneous deployments: Run confidential and non-confidential workloads side-by-side in the same cluster. Applications can choose which workloads require confidential computing protection
• Policy-based runtime enforcement: Uses OPA policies to control what can execute in each pod

The Coordinator component in Contrast acts as an attestation service that verifies all confidential pods and provides a unified attestation statement for the entire confidential deployment, despite the pods running on untrusted infrastructure.

Comparing the trusted computing base

The key differentiator between these approaches lies in what must be trusted, the TCB.

Constellation's TCB includes:

• The confidential computing hardware (CPU and microcode)
• The verified Constellation node images
• The entire Kubernetes control plane (running in CVMs)
• All cluster components and microservices

Contrast's TCB includes:

• The confidential computing hardware (CPU and microcode)
• The confidential micro-VM runtime environment
• The workload containers themselves
• The sidecar containers (initializer, service mesh)
• The runtime policies
• The Coordinator (also running in a confidential container)

Crucially, Contrast removes the Kubernetes control plane, the hypervisor, the host OS, and cluster administrators from the TCB. The cluster operators can manage the infrastructure without having access to the confidential workload data or code.

The reality of cloud-native deployments

Our shift to Contrast reflects several key insights about how organizations actually deploy and operate Kubernetes in production.

Managed Kubernetes is the default

The vast majority of organizations use managed Kubernetes services like AKS, EKS, and GKE. These services handle the complexity of control plane management, updates, and high availability. Constellation's whole-cluster approach requires organizations to forgo these managed services and take on the operational burden themselves: deploying, managing, and upgrading the entire Kubernetes control plane.

While this approach provides maximum security by including the control plane in the confidential context, it creates significant operational overhead. Organizations must:

• Manage their own control plane infrastructure
• Handle control plane upgrades and patches
• Ensure high availability of the control plane
• Deal with cloud-specific integrations (load balancers, storage, autoscaling) themselves

For many organizations, this tradeoff doesn't make sense. They want the security benefits of confidential computing without abandoning the operational advantages of managed Kubernetes.

Heterogeneous deployments

In practice, not all workloads in a cluster require confidential computing isolation. A typical application might have:

• Public-facing web frontends
• API gateways and proxies
• Backend services handling sensitive data
• Databases and stateful workloads with confidential information
• Batch processing jobs with regulated data

With Constellation, it's all-or-nothing: the entire cluster must run in CVMs. With Contrast, organizations can run confidential and non-confidential workloads side-by-side in the same cluster, enabling truly heterogeneous deployments. This provides:

• Cost efficiency: Confidential computing comes with a performance/cost overhead; apply it only where needed
• Heterogeneous deployments: Mix confidential and standard workloads in the same cluster, matching protection to each workload's needs

The fundamental limitation: Infrastructure vs. workload isolation

This brings us to the most critical distinction between Constellation and Contrast. One that fundamentally determines which use cases each approach can serve.

Constellation: Infrastructure isolation only

Constellation's architecture provides strong isolation from the cloud infrastructure. It protects against:

• Malicious cloud service provider (CSP) employees
• Infrastructure-level attacks and compromised hypervisors
• Co-tenant attacks from other cloud users

However, Constellation does not provide workload-level attestation or isolation. Within a Constellation cluster:

• All workloads share the same confidential context
• There's no mechanism to attest individual workloads
• Workloads cannot be isolated from each other or from cluster administrators
• All parties with cluster access have equal access to all workloads

This means Constellation serves one primary use case: organizations that trust themselves but need to isolate their entire infrastructure from the CSP. It's a "cloud migration" solution for moving on-premises workloads to the cloud while maintaining the same trust model.

Contrast: workload-level attestation and isolation

Contrast's pod-level architecture enables a fundamentally different trust model with per-workload attestation and isolation:

• Each pod runs in its own isolated confidential micro-VM
• Each pod can be individually attested by clients
• Workloads are cryptographically isolated from each other and from cluster operators
• The data owner can verify exactly which code is running before sending sensitive data

This enables a multi-party trust model where three separate, mutually distrusting parties can interact:

1. The container image provider: Who creates the application
2. The workload operator: Who runs the Kubernetes cluster (potentially a cloud provider or platform team)
3. The data owner: Who owns the protected data

Critically, Contrast protects against malicious workload operators, including Kubernetes administrators with full cluster access. The data owner can verify through remote attestation that:

• The correct container images are running (down to the exact digest)
• The runtime environment and policies are configured correctly
• The operator cannot access the confidential data or modify the workload

Use cases that require workload attestation

This architectural difference isn't just theoretical. It determines which real-world use cases are possible.

Provider exclusion requirements

One of the most prominent examples of provider exclusion is the Gematik VAU (Vertrauenswürdige Ausführungsumgebung) for ePA in Germany's electronic health record system. The VAU specification requires that even the service provider operating the system cannot access patient data. This is enforced by workload-level attestation, which verifies the exact code handling health data and cryptographically excludes the provider from accessing sensitive information.

Constellation cannot meet these requirements. There's no mechanism for clients to attest individual workloads or prove that operators can't access data. The whole cluster, including administrators, is part of the trusted context.

Contrast enables provider exclusion through per-pod attestation and isolation. Clients can verify the exact workload and cryptographically ensure that operators are excluded from data access, fulfilling the Gematik VAU requirements.

Confidential AI Services

Consider Privatemode, our end-to-end encrypted GenAI API service. The architecture requires:

• Users must attest the AI inference workload before sending prompts
• The service provider (Edgeless Systems) must be excluded from accessing user prompts
• The infrastructure provider (Scaleway) must be excluded from accessing prompts and models

This architecture is impossible with Constellation. There's no way to attest individual AI workers separately from the cluster. The cluster operator (Edgeless Systems) would be part of the TCB and could access user data, defeating the entire security model.

Contrast makes this architecture possible through its per-pod attestation and policy enforcement. Each AI worker runs in an isolated micro-VM, is individually attested by the Coordinator, and only receives decryption keys after successful verification.

SaaS with verifiable privacy

Modern SaaS platforms face increasing pressure to prove they cannot access customer data:

• Healthcare SaaS must comply with regulations
• Decentralized applications in the blockchain and Web3 space need zero-trust architectures
• Collaboration tools need a zero-knowledge architecture

Constellation doesn't help here because the SaaS provider operates the cluster and remains in the TCB. Customers have to trust the provider's access controls.

Contrast enables verifiable privacy where customers can attest the SaaS workload and cryptographically verify that even the SaaS provider cannot access their data: true zero-trust architecture.

Operational advantages of Contrast

Beyond the architectural benefits, Contrast offers several practical advantages:

Minimal integration burden

Contrast integrates into existing Kubernetes workflows with minimal changes:

• Deploy as a day-2 operation into existing clusters
• Use existing YAML files, Helm charts, or Kustomize configurations
• Add runtime class annotations to specify which pods should be confidential
• Leverage existing CI/CD pipelines

Constellation requires an entirely new cluster deployment with its own CLI and tooling.

Simplified Updates and Maintenance

With Contrast:

• The Kubernetes control plane is updated through the managed service
• Only the Contrast runtime and Coordinator need version management
• Workload updates don't affect the attestation of the deployment

With Constellation:

• The entire cluster, including the control plane, must be upgraded in a coordinated fashion
• Updates require careful coordination to maintain attestation
• Higher operational complexity

Technical Trade-offs

We should be honest about the trade-offs. Constellation does offer some advantages that Contrast sacrifices:

Control plane protection

Constellation protects the Kubernetes control plane itself within the confidential context. This means that even cluster state, configurations, and secrets stored in etcd are encrypted and protected. In Contrast, the control plane runs outside the confidential boundary.

However, Contrast mitigates this through:

• Policy-based verification of pod configurations
• Careful design to avoid trusting cluster-provided data (downward API, ConfigMaps, etc.)
• Encryption of all confidential data at rest and in transit
• The Coordinator provides a trusted configuration source

In most use cases, protecting workload data is more critical than protecting control-plane metadata.

Network and storage transparency

Constellation provides fully transparent network and storage encryption for the entire cluster. Every network packet and storage block is encrypted without application changes.

Contrast requires more careful attention to:

• Which volumes are mounted (prefer raw block devices with encryption in the pod)
• External service authentication (use certificates from the mesh CA)
• Persistent storage (encrypt sensitive data before writing)

This requires more developer awareness but provides greater flexibility and explicitly defines trust boundaries.

Unified attestation

Constellation's single attestation statement for the entire cluster is conceptually simpler than Contrast's composite device model. However, Contrast's Coordinator provides a similar unified attestation statement that encompasses all confidential pods in a deployment, verified against a manifest.

The path forward: Why Contrast

Our decision to focus on Contrast comes down to alignment with how the industry is evolving and the fundamental capabilities required for modern confidential computing use cases:

1. Workload attestation is essential: Most valuable use cases require the ability to attest and isolate individual workloads, not entire clusters
2. Provider exclusion is increasingly mandated: Regulatory frameworks like Gematik VAU explicitly require the separation between workload and data owner
3. Multi-party trust is the future: The most compelling use cases involve multiple distrusting parties, not just CSP isolation
4. Managed Kubernetes is the standard: Organizations want security without operational complexity
5. Heterogeneous deployments are essential: Not every workload justifies the overhead of confidential computing; Contrast enables mixing confidential and standard workloads in the same cluster
6. Standards-based approach: Building on Confidential Containers positions us to leverage ecosystem innovation

Constellation served an important role in exploring the "whole cluster" approach and demonstrated what's possible with confidential computing. However, we've learned that its limitation to infrastructure isolation, without workload-level attestation, fundamentally restricts its applicability.

The use cases that matter most today require workload attestation:

• Regulatory compliance: Provider exclusion mandates
• Confidential AI services: Like Privatemode, where users must verify AI workers
• Zero-trust SaaS: Platforms that can prove they don't access customer data
• Healthcare and finance: Industries with strict data access controls

While Constellation's vision of a fully confidential cluster is technically impressive, it solves primarily the "cloud migration from on-prem" use case. Contrast provides capabilities that unlock entirely new architectures and business models that were previously impossible.

What this means for users

For existing Constellation users: Constellation's code remains available as an open-source project. While we're no longer actively maintaining it, the repository and documentation remain available for archival purposes and community use. We encourage users to evaluate Contrast as an alternative that may better fit their operational requirements.

For those evaluating confidential computing: We recommend starting with Contrast. It provides strong security guarantees while integrating seamlessly with existing Kubernetes environments. The ability to selectively apply confidential computing to specific workloads makes adoption more practical and cost-effective.

Conclusion

Confidential computing is still evolving, and our shift from Constellation to Contrast reflects our deeper understanding of where this technology delivers the most value. The fundamental insight is this: workload-level attestation and isolation are more important than cluster-level isolation for the majority of confidential computing use cases.

Constellation demonstrated the technical feasibility of whole-cluster confidential computing and served an important role in our learning journey. It remains a valid approach for organizations that:

• Want to migrate on-premises clusters to the cloud while maintaining the same trust model
• Need to isolate from CSPs but not from internal administrators
• Can accept the operational overhead of managing their own Kubernetes control plane

However, we've learned that this use case is narrower than we initially anticipated. The use cases that truly unlock confidential computing's potential, provider exclusion, confidential AI services, and verifiable SaaS, all require workload-level attestation that Constellation fundamentally cannot provide.

Contrast enables these use cases while maintaining compatibility with managed Kubernetes, existing tools, and cloud-native architectures. It's the architecture that aligns with industry evolution, regulatory requirements, and the real-world needs we see from customers.

We're excited about this focus and the innovation it enables. Confidential computing is moving from "protecting against the cloud" to "enabling new trust models in the cloud," and Contrast is the right foundation for that future.

Learn more about Contrast in our documentation or reach out to discuss your confidential computing needs. For Privatemode, our confidential AI API built on Contrast, visit privatemode.ai.