Encrypted zone (EZ) is an end-to-end privacy-enhancing container framework designed to enforce rigorous security and data-flow policies for workloads running within a confidential computing (CC) trusted execution environment (TEE).
The primary goal of EZ is to decouple privacy enforcement from business logic. By doing this, developers can run proprietary, closed-source workloads (for example, a proprietary ML inference server) securely while external auditors can independently verify the system's privacy properties by solely examining the open-source enforcement mechanisms and declarative manifests.
The EZ enforcer: the trusted core
The EZ enforcer is a standalone, open-source Rust binary that acts as the platform's trusted core. Running inside the TEE, it serves as both a hardened container manager and the primary gatekeeper for all data flows. It provides three critical mechanisms:
- Container management: The EZ enforcer functions as a hardened container manager, loading OCI-compliant images and booting these isolates in highly restricted Linux namespaces (sandboxes). It validates cryptographic endorsements before execution to minimize the TEE measurement profile.
- Policy enforcement: To achieve a "fail-closed by default" model, the EZ
enforcer reads the
ez_manifest.jsonto strictly limit data flows based on tiered sensitivity levels (for example,PUBLIC,USER_PRIVATE,DOMAIN_OWNED). - IPC bridge: The "wiring" of the system, the IPC bridge brokers all communication between isolates and the other system components using high-speed inter-process communication (IPC) using unix domain sockets and shared memory.
Isolates: workload containers
Isolates are OCI containers running inside EZ, performing a workload. Isolates have no direct external network access. All I/O is forced through the enforcer. There are two types of isolates:
- Opaque isolates: These are untrusted, proprietary, closed-source
workloads. They operate within a strict sandbox. If they ingest sensitive
data (for example, user data marked
USER_PRIVATE), they are cryptographically and architecturally prevented at the network and IPC layers from egressing that data unless it is end-to-end encrypted directly to the user who owns the data, or routed through an approved declassification path using a ratified isolate. - Ratified isolates: These are trusted, audited workloads endorsed by a trusted publisher, which must be publicly verifiable (for example, open-source) to maintain trust transparency. They have the privileged ability to dynamically override the enforcer's default rules, manage cryptographic keys, or transmute data scopes (declassification). They form the imperative portion of the privacy policy.
Deployment and developer tooling
The system uses declarative and programmatic tools to manage the environment:
- EZ manifest: A JSON configuration declaring RPC interfaces, acceptable data scopes, backend dependencies, and interception rules. It ensures transparency for all allowed communication paths.
- EZ SDK: Allows "lift and shift" of existing gRPC services by providing a protobuf code generator that replaces the TCP layer with local IPC calls to the enforcer, requiring minimal source-code changes.
- Attestation-linked mTLS: The enforcer implements end-to-end encryption using mTLS. Critically, the system only issues certificates to enforcer nodes upon successful hardware attestation, ensuring that the network mesh consists exclusively of verified peer environments.
External support
These components sit outside the TEE trust boundary in the cloud provider's host environment.
- EZ launcher: Responsible for securely bootstrapping the TEE, verifying attestation measurements (using Project Oak or Stage0), and launching the EZ enforcer.
- Cloud proxy: Acts as the ingress and egress gateway. It routes encrypted client traffic to the EZ enforcer using EzPublicApi and facilitates the node-to-node mTLS service mesh, acting as an untrusted transport layer. It typically is hosted outside the TEE boundary, like a sidecar.