Confidential Computing and Edera

8 min read · Advanced

Overview

Confidential Computing protects data while it is being processed by using hardware-based Trusted Execution Environments (TEEs). It is designed to help protect workloads and their data from certain privileged infrastructure threats, including access by cloud administrators or a compromised host operating system.

Edera takes a different approach to workload security. By running workloads in isolated zones with independent kernels, Edera reduces reliance on a shared host kernel and limits the extent to which one workload can affect another. Both approaches address important security challenges, but they solve different problems. Another key distinction is that Edera protects the infrastructure itself, while Confidential Computing assumes the workload is inherently trusted.

Confidential Computing is particularly relevant when an organization needs to protect data in use from the infrastructure operator or establish cryptographic evidence about the environment in which a workload executes. Edera focuses on strong workload isolation, reducing cross-workload attack paths, and providing practical security for modern containerized environments without requiring every workload to run inside a hardware-backed confidential environment.

Depending on the threat model, Edera and Confidential Computing may be alternatives for particular isolation requirements, or complementary layers of a broader security architecture.

What is Confidential Computing?

Confidential Computing uses hardware-supported Trusted Execution Environments to protect sensitive code and data while a workload executes.

Traditional encryption protects data at rest, such as files on disk, and in transit, such as network traffic. Data must ordinarily be decrypted for a processor to work on it. Confidential Computing introduces hardware mechanisms designed to protect that data during execution from specified threats outside the trusted execution boundary.

At a high level, the process looks like this:

A workload starts inside a supported TEE.
The environment then establishes its security state.
Remote party verifies cryptographic evidence through remote attestation.
After validating evidence, the remote party releases secrets to the workload.
The workload processes that data inside the protected environment.

The precise guarantees depend on the processor architecture, TEE implementation, configuration, firmware, software stack, and attestation policy. Confidential Computing does not make an application invulnerable. Vulnerabilities in the application, unsafe data flows, compromised dependencies, and mistakes in key management can still expose sensitive information. Protection against the host or infrastructure operator also depends on the specific TEE’s security boundary and threat model.

How Edera approaches workload security

Edera isolates workloads using separate execution environments with independent kernels, rather than relying exclusively on operating-system-level isolation between containers sharing a host kernel. This changes the isolation boundary. A vulnerability in one workload’s kernel does not automatically provide the same direct access to other workloads that a shared-kernel architecture can permit.

Edera is designed to help organizations:

Isolate mutually untrusted workloads.
Reduce the impact of workload and kernel compromise.
Run containerized applications within a Kubernetes-oriented workflow.
Avoid making specialized confidential-computing hardware a prerequisite for isolation.
Apply isolation in supported environments without redesigning every app around TEE.

Edera’s isolation is not equivalent to encrypting workload memory against a privileged infrastructure operator. Whether it satisfies a particular security requirement depends on the adversary being considered and the guarantees of the deployed architecture.

Key Differences between Edera and Confidential Computing

Neither column represents a universal guarantee. You need to understand which threat a workload must withstand and which controls enforce that boundary.

Capability	Edera	Confidential Computing
Primary security objective	Strong workload isolation	Protect data in use within a hardware-defined trust boundary
Isolation Mechanism	Separate workload execution environments and kernels	Hardware-backed TEE protections
Protects against some shared-kernel risks	Yes, through its isolation architecture	Depends on the TEE boundary and workload architecture. Basically, to get this you have to combine a TEE with a microVM architecture
Cryptographic protection of memory from the host	Not inherently provided by workload isolation	A central goal of supported TEE designs
Remote Attestation	Our SPIFFE work actually does support a form of remote attestation { * }	Commonly used to establish trust in a TEE
Specialized hardware requirement	Does not require a TEE solely to provide Edera isolation	Requires compatible hardware and platform support
Application changes	Designed for integration with containerized workloads. So compatibility still matters	May require changes to deployment, secret delivery, or application architecture { * * }
Operational Considerations	Runtime integration, resource overhead, isolation policy, and workload compatibility	Hardware availability, attestation, firmware, key management, TEE limitations, and workload compatibility
Can the approaches be combined?	Yes, where supported and architecturally appropriate	Yes, as an additional layer of protection

{ * } In the case of remote attestations, we’ve even prototyped using this with a hardware root of trust for hardware-backed remote attestations. Without the hardware, the only difference is that your root of trust is the hypervisor instead of a TEE.
{ * * } This is probably too much detail for a table, but there’s an interesting tradeoff between architectural changes and security. Essentially, if you put a whole microVM into the TEE, it’s easier, but you’ve only gone and added a bunch of stuff to your trusted computing base. A better way is to create custom, small apps for the TEE, but people generally-speaking don’t tend to do this.

Why Confidential Computing can be complex

Confidential Computing introduces security properties that ordinary software isolation does not provide, but those properties come with additional requirements.

1. Hardware and Platform Compatibility

Confidential Computing depends on a supported processor architecture and its associated firmware, hypervisor, and cloud or on-premises platform capabilities. A workload cannot use a particular TEE merely because it runs in a virtual machine or container. The underlying hardware and platform must support the required technology, and the environment must expose it appropriately. This can constrain hardware selection, cloud instance availability, migration options, and deployment portability.

2. Attestation and Key Management

A TEE is only useful to a relying party if that party can establish that it is communicating with an acceptable environment. Remote attestation introduces questions about which measurements and configurations are trusted, how evidence is validated, how trust policies are maintained, and when secrets should be released. Organizations must also plan for certificate and key lifecycles, revocation, upgrades, recovery, and changes to the approved software configuration.

3. Choosing the Trust Boundary

The protected boundary matters as much as the hardware itself. Some architectures can protect selected portions of an application, while others place an entire confidential virtual machine inside the protected environment. Protecting an entire VM can simplify deployment, but it also means the guest operating system and applications remain part of the trusted computing base for the workload’s behavior. A compromised guest can still misuse data available to it, and vulnerabilities inside the protected boundary are not automatically prevented by the TEE.

4. Performance, Cost, and Operations

The total cost of Confidential Computing depends on the platform, workload, hardware availability, memory requirements, performance characteristics, and engineering effort. It is not accurate to assume that every confidential workload is prohibitively expensive. Some workloads may have modest overhead, while others may encounter meaningful cost or performance trade-offs. The operational cost of attestation, secrets management, debugging, monitoring, upgrades, and platform-specific deployment can also be significant.

When Edera might be a better fit than Confidential Computing

Edera may be a good fit when the primary requirement is to isolate workloads from one another or reduce the security risks associated with a shared host kernel. Examples include:

Platforms running customer-supplied plugins or jobs.
Development and CI environments executing untrusted code.
Agentic systems that execute code or tools from different sources.
Multi-tenant Kubernetes clusters running mutually untrusted workloads.
Workloads needing strong isolation without hardware-backed memory confidentiality.

For these use cases, introducing a TEE may add operational complexity without addressing the primary security concern any better than a properly designed isolation boundary. Edera still requires compatibility validation and security testing. It is not a guarantee that arbitrary code is safe, nor does isolation replace application-level security controls.

When Confidential Computing is necessary

Confidential Computing is relevant when the threat model includes a privileged infrastructure operator, host-level compromise, or another party that must not be able to inspect protected workload memory. Examples may include:

Protecting proprietary models, algorithms, or other intellectual property during execution.
Processing sensitive data on infrastructure operated by an orgs that are not fully trusted.
Deployments requiring remote attestation before secrets or sensitive data can be released.
Enabling data processing across organizational boundaries where hardware-backed confidentiality is a requirement.

Regulated organizations should distinguish technical safeguards from regulatory obligations. Confidential Computing does not, by itself, establish compliance with HIPAA, financial regulations, or other legal requirements. Likewise, the use of Edera does not by itself establish regulatory compliance. The complete architecture, access controls, contractual arrangements, policies, and operational procedures must meet the applicable requirements.

Can Edera and Confidential Computing work together?

Yes, where the selected Edera deployment, TEE platform, and integration architecture support the combination. Confidential Computing can help protect workload memory from threats outside a hardware-defined trust boundary. Edera can provide workload isolation within a broader execution architecture. Combining these controls may be useful when an organization needs both hardware-backed confidentiality and strong isolation between workloads. However, the combination does not automatically eliminate vulnerabilities inside the protected environment. Teams should explicitly identify which components are trusted, which parties can access secrets, and what happens when a workload or component is compromised.