Metrics: defeating covert exfiltration channels
To safely export operational telemetry from opaque isolates within a trust-minimized threat model, the system must either rely entirely on audited open-source data processors or structurally prevent compromised workloads from using high-fidelity observability pipelines as a covert exfiltration channel. The former approach traditionally requires routing all telemetry through complex, verified transformation proxies, which introduces significant development overhead and limits operational visibility.
To mitigate exfiltration risks without sacrificing standard observability,
the encrypted zone uses OpenTelemetry (OTLP) combined with a declarative,
manifest-driven metrics_policy. The process follows a specific sequence:
- Ingestion: The opaque isolate generates operational telemetry (OTLP metrics) during request processing.
- Interception: The EZ enforcer intercepts all telemetry payloads crossing the IPC bridge before they leave the secure enclave.
- Strict Allowlisting: The enforcer evaluates the payload against the
declarative
metrics_policy. Dynamic metric generation is strictly forbidden. The enforcer strips away any data that does not match explicitly declared metric names and tightly bounded-cardinality attributes. - Egress: The sanitized, policy-compliant metrics are safely declassified and routed to the host's external logging socket.
This mechanism ensures that essential operational visibility is maintained without exposing unbounded, high-cardinality fields that could be exploited by a malicious workload.
Debugging
To assist operators without compromising workload egress controls, the EZ
enforcer exposes a highly restricted gRPC DiagnosticService. This service
allows operators to collect runtime diagnostics and CPU profiling (pprof)
limited to the enforcer process.
To maintain the Confidential Computing (CC) boundary, the EZ architecture cryptographically and architecturally bars host operators from initiating profiles, memory dumps, or diagnostic traces against the interior sandboxed opaque isolates.
Known limitations and roadmap: logging constraints
In the current Developer Preview, Encrypted Zone does not perform active
data-scope enforcement on standard output (stdout) and error (stderr)
streams. Opaque isolates inherit these file descriptors directly from the parent
container environment, bypassing the IPC bridge. This allows for rapid
iteration during development but represents a temporary security gap.
Roadmap to production hardening
The production architecture will be locked down. In the production release, the EZ architecture will either entirely disable these unmanaged log dumps or require a transparent "break glass" debug access event to read them. Tooling to export structured error metrics (in place of unstructured text logs) using the aforementioned OTLP channels can also be used.