Data scope
All data flowing through EZ is tagged with a corresponding data scope, a structure holding metadata that tracks data type, ownership, and other properties informing policy decisions. Every data scope must be assigned a specific data type, which determines basic egress rules. Data types are one of the following enumerated (ordered) constants, from least to most restrictive:
PUBLIC: Data that EZ can safely egress as plaintext, without any enforcement.DOMAIN_OWNED: EZ restricts this to a specific domain owner if egressed (e.g., to protect proprietary information when transiting corporate domains).USER_PRIVATE: User data that EZ will only egress with end-to-end encryption to the owning user.MULTI_USER_PRIVATE: Multiple user data, which EZ will only egress encrypted with key material that does not leave EZ.SEALED: Data with untracked ownership, which EZ will only egress encrypted with key material that does not leave EZ.
Opaque isolates inherit the scope of their inputs and cannot arbitrarily downgrade them, ensuring sensitive data remains protected.
Egress
Data leaving the EZ trust boundary via any means other than an end-to-end secure
channel to a user who owns the data is considered to be an egress event. Data
with a PUBLIC data scope type can be egressed freely as plaintext, but all other
data types will be encrypted by the enforcer prior to egress. Ratified isolates
can always choose to move data into the PUBLIC scope, regardless of its scope
upon entry to the ratified isolate.
Endorsement
An endorsement is a special "observable" form of digital signature issued by a publisher, typically authenticated with a certificate-based PKI. In an externally auditable deployment, all such endorsements must be verifiably placed into public view on an external transparency log.
SigStore Fulcio is one way to provide such public endorsements; it publishes all signing events to the SigStore Rekor transparency log and provides a certificate-based PKI. Before accepting a package for endorsement, Fulcio verifies the publisher identity using the OIDC authentication standard, which is supported by standard cloud providers and can also be used from GitHub Actions.
EZ enforcer
The open-source, heavily audited gatekeeper operating within the TEE. It acts as the container manager and strictly enforces all privacy policies and networking rules.
The enforcer is a Rust binary that is intended to be portable across common Linux environments, particularly in various cloud service TEEs such as confidential computing platforms. The enforcer runs on every EZ node, and is responsible for applying data flow policy throughout the deployment.
Enforcer plugin
The enforcer has a collection of standard microservices installable at runtime using ratified isolates. During initialization, the enforcer installs an initial setup plugin to determine its configuration, enabling a single enforcer binary to have specialized, externally verifiable configurations.
Other plugins handle functionality such as package management (including verification of isolate manifests), cryptographic key management, observability, etc.
EZ cloud proxy
This is a proxy that sits outside the TEE trust boundary and adapts the EZ node
communications to the particular cloud environment that EZ is running within. It
routes traffic to and from the EZ enforcer (which sits inside the TEE trust
boundary). In particular, it routes encrypted traffic flowing between two EZ
enforcers, as well as unencrypted ingress or egress traffic through
EzPublicApi.
EZ SDK
This is a software development kit that provides tooling, libraries, and build environments for various programming languages. The aim of the SDK is to allow developers to continue using their existing development practices, and even their legacy code, when they develop servers to run in EZ as isolates. The SDK can be extended to encompass custom requirements for specialized setups.
EzPublicApi
This is the primary call interface for non-EZ systems to make requests to the EZ
enforcer. It is a generic API that allows calling into any RPC service
methods on EZ isolates. Replies returned using the EzPublicApi are
considered a form of egress traffic.
IPC Bridge
EZ defines an inter-process communication bridge (IPC bridge) that carries data speed communications between the enforcer and isolates. It is implemented using a mix of techniques, including unix domain sockets and shared memory maps. Isolate code should rely on the EZ SDK to abstract away the details of the IPC bridge.
Isolate
An isolate is an OCI compatible container image intended to run within EZ. The
container's configuration requests (e.g. config.json) will be ignored in favor
of EZ's privacy enforced configuration: no external network interfaces, a
read-only rootfs from the container (with a writable tmpfs), etc.
Isolates are stripped of standard network interfaces and must communicate exclusively through the enforcer’s IPC bridge.
Opaque isolate
Any isolate image that is not endorsed by EZ's trusted publisher. Opaque isolates are treated as untrusted, and will be "sandboxed" by EZ.
Opaque isolates contain closed-source business logic and run in an isolated environment where they are structurally prevented from bypassing privacy policies or egressing any private data on their own (though they may send requests to a ratified isolate in order to do so).
Ratified isolate
Any isolate image that is endorsed by the trusted publisher that EZ uses to define its current policy. EZ trusts ratified isolates to modify data scopes arbitrarily (also known as declassification in information flow control theory).
Ratified isolates are publicly verifiable, open-source microservices. Because
they are transparent and auditable, ratified isolates are often used to safely
transmute privately scoped data types to PUBLIC scope for egress.
Manifest
An EZ manifest describes the contents of a package, or a bundle of packages, to be installed in a particular EZ isolate or bundle of co-resident isolates (isolates co-reside if they must be installed and run together on the same EZ node for efficiency reasons).
Manifests must be signed or endorsed by a publisher as appropriate, and that publisher's identity determines the trust that EZ will assign to the corresponding isolate. For each isolate binary specified in the manifest, the manifest must explicitly enumerate any RPC service methods that the binary exposes as well as any backend RPC service dependencies that it might want to call.
Each exposed RPC service method can also indicate the set of allowed data scopes it accepts on inputs—this helps EZ to avoid sending inappropriate data to an isolate, ensuring that isolate outputs can be safely routed as intended. Manifests also contain other useful metadata, possibly including additional provenance information, configuration requirements, etc.
Operator domain
The web domain of the service provider who is responsible for operating a server deployment. For example, this refers to the company paying for its service to be hosted by a cloud platform, not the cloud platform provider itself.
The operator domain is used to determine data flow policy for proprietary concerns, such as which deployment configurations to accept, or where to transmit or store proprietary data. Explicit trust decisions between operator domains can enable proprietary data to cross operator domain boundaries. Unlike other proprietary data, user data is subject to more stringent policy rules, which are typically focused on user privacy considerations.
OpenID Connect (OIDC)
OIDC is a secure authentication protocol that allows applications to verify a user's identity without managing passwords.
Publisher
An individual or organization (perhaps a specific team within a corporation) that releases software packages, which need not be authored by the publisher. The role of the publisher is to certify which software packages they consider to be trustworthy, enabling their published packages to establish mutual trust.
Furthermore, the specific publisher trusted to govern an EZ deployment can create ratified isolates by releasing the software packages to be ratified and then producing a full endorsement of the release. EZ explicitly decouples the publisher from the operator domain to ensure the service operator cannot tamper with the software's provenance.
RPC Service
This is a traditional definition of remote procedure call service, such as a gRPC service, which contains one or more remotely callable methods. When isolates expose an RPC service, the service is actually proxied using a local IPC bridge to the enforcer so that it can properly police all data flows for the service.
Trusted Execution Environment (TEE)
A hardware isolated part of a processor that also allows for remote attestation. EZ both depends on this foundational hardware security, and helps extend it to make privacy claims.