Confidential computing, a concept starting to make its way from academia into software practice, promises enhanced security for cloud applications through hardware-based encryption and isolation. While powerful, its adoption faces challenges including hardware requirements, compatibility issues, and performance costs. Edera offers a complementary approach with strong isolation ensuring no shared kernel state between workloads using a container-native type 1 hypervisor, providing robust security without specialized hardware. This article explores both technologies, their different threat models, and how combining them can offer the best security protections for different organizational needs.
Given that most users trust their clouds but not every application or open source library running on them, Edera’s workload isolation provides needed protection for these users. For those worried about nation state actors compromising their cloud provider, confidential computing can be used with Edera for the addition of hardware-backed trust.
What is confidential computing?
According to the Linux Foundation’s Confidential Computing Consortium, confidential computing is “the protection of data in use by performing computation in a hardware-based, attested Trusted Execution Environment.”
These Trusted Execution Environments (TEEs) are secure areas within a CPU that can run applications. While implementations vary considerably across hardware and software configurations, confidential computing generally uses a hardware-backed TEE (such as Intel SGX, AMD SEV, or Arm TrustZone) to achieve:
- Cryptographic integrity of code and data
- Data encryption in memory and in use
- Remote attestation that the expected runtime environment is running in a TEE
- Moving trust out of software into hardware
How it works
Very briefly, confidential computing runs applications on trusted hardware (the TEE). This trusted hardware may be in an untrusted environment, and if so the process of remote attestation can be used to cryptographically verify that the application is what you expect, and that it’s running in a particular TEE.
By running code in a TEE, applications can reduce their trusted computing base (TCB). A TCB is all of the hardware and software you have to trust to run an application. This may include the operating system, device drivers, and hardware. If any element in the TCB is compromised, the application may also be vulnerable. By placing just the application in a TEE, the application can be run without the operating system, device drivers, or infrastructure in the TCB, reducing the amount of code, and thus the likelihood of a compromise within the TCB.
The confidential computing threat model
Confidential computing is designed for running workloads in environments you don't trust. In cloud environments, this protects against potentially malicious cloud service providers (like AWS, Azure, etc.) or compromised on-prem machines hosting your workloads.
However, it's important to note that confidential computing is still emerging as a production-ready technology. Few organizations run it at scale in production environments, and several technical gaps remain. Additionally, confidential computing doesn't protect the host machine from compromised workloads, such as an application with a malicious dependency or an unknown user-supplied application. If a malicious workload achieves privilege escalation, confidential computing alone won't prevent the attack.
Costs and limitations of confidential computing
Confidential computing involves several tradeoffs:
Hardware requirements: You need host machines with hardware TEEs built into specific CPUs. This often means paying premium rates to Cloud providers for bare metal instances with such hardware, subject to availability constraints, replacing incompatible machines you already own, and leading to lock-in to specific hardware platforms.
Application modifications: Confidential computing trades off drop-in compatibility with minimizing the trusted computing base (TCB). Intel SGX's resource constraints mean only critical elements run in the TEE, requiring applications to be re-written to work with the SGX API. AMD SEV supports entire containers inside the TEE but increases the TCB and attack surface. In many cases the entire Linux kernel is running inside a SEV TEE, meaning that any kernel compromise will violate the confidentiality of data in the TEE.
Security compromises: Several security bugs have been found in TEEs. These bugs are particularly challenging to patch in running systems because they are in hardware components rather than in software.
Resource limitations: All TEEs restrict the number of confidential VMs, encrypted memory capacity, hardware encryption keys, and other resources, potentially limiting large-scale deployments.
Enter Edera Protect
Edera Protect takes a different approach to cloud security. As a container-native type 1 hypervisor, it provides strong isolation between workloads by running them in “zones” backed by isolated virtual machines. Edera achieves this while avoiding common hypervisor performance limitations and maintaining full Kubernetes compatibility. For more information, see this post.
Comparing isolation models: Edera vs. confidential computing
Edera's threat model:
- Assumes a trusted host machine (the Edera hypervisor)
- Protects against untrusted applications or multi-tenant scenarios
- Isolates the hypervisor from workloads and workloads from each other
- Prevents container escapes or privilege escalation from affecting other workloads
Confidential computing's threat model:
- Assumes an untrusted host machine
- Protects against malicious cloud providers or compromised infrastructure
- Isolates applications from each other and the host machine
Most container environments can reasonably trust their cloud providers not to be malicious. Cloud providers are in the business of providing a platform for their customers to run applications, and messing with these applications would be bad for business. However, many companies do not trust all of the code that they run. They may be running arbitrary code from customers, have software dependencies on code they don’t control, or perform computation on untrusted user input. In all these cases, applications (and any potential vulnerabilities) need containment. Specifically, the underlying infrastructure needs isolation from the applications. While confidential computing can ensure a cloud provider cannot view or influence an application, Edera can ensure an application cannot influence the host machine.
Real-world application scenarios
Combining strengths: Edera and confidential computing
We saw above that confidential computing secures trusted workloads running in untrusted environments, and Edera secures untrusted workloads (or those that might have vulnerabilities)—highly complementary threat models. How can we get the best of both worlds? Two approaches emerge:
1. Maximum security: Edera zones inside TEEs
Running Edera Protect zones inside hardware TEEs utilizes confidential computing best practices like remote attestation and memory encryption. This achieves:
- Hardware-backed confidentiality and integrity from confidential computing
- Strong protection against container escapes from Edera Protect
- Combined threat model addressing both untrusted hosts and untrusted workloads
However, this approach carries all the costs and limitations of confidential computing mentioned earlier.
2. Pragmatic security: Edera with software-based memory encryption
For organizations that aren’t worried about nation state actors compromising their cloud provider, but want to protect sensitive data, like user data, credit card information, or credentials inside containers, we propose a hybrid approach:
Combining Edera Protect with software-based memory encryption allows:
- Encrypted memory sections containing secrets, inaccessible to other containers
- Encryption key management either in the hypervisor or via remote service such as a software TPM
- No specialized hardware requirements
This design delivers:
- Data integrity
- Memory encryption
- Isolation from other workloads (prevents lateral movement)
- Isolation of hypervisor from workloads (prevents privilege escalation)
- Portability with no hardware requirements
It does not provide some of the stronger guarantees required by the strictest security models:
- Hardware-backed trust
- Code integrity through remote attestation
- Encryption during processing
Choosing the right security model
When running an application in a non-malicious environment, such as on-prem or using a trusted cloud provider, Edera can provide most confidential computing benefits without hardware limitations or added costs.
For organizations with the strictest security requirements who need protection against nation states, full confidential computing (ideally combined with Edera) remains necessary.
We believe most users trust their clouds but can't trust every application or open source library running on them. Edera provides strong security boundaries around containerized applications to protect customer data without specialized hardware or complex configurations.
Let’s Compute Together
Ready to strengthen your container security? Contact us to learn more about how Edera Protect can secure your cloud workloads today. In our next article, we'll dive deeper into performance comparisons between traditional confidential computing and Edera's approach.
