Observability vs. Confidentiality
You've built a system with a strong CoCo Vector. Attestation is solid. Builds are reproducible. Binding is dynamic. Key release is strict. Then someone asks: "how do we debug it in production?"
This is the operational tension at the heart of confidential computing: the same isolation that protects your workload from the infrastructure also protects it from your ops team.
The problem
A traditional workload gives you full observability: logs, metrics, traces, memory dumps, live debugging, SSH access. A confidential workload runs inside hardware-enforced isolation specifically designed to prevent exactly that kind of access.
If your ops team can read the logs, so can the infrastructure operator. If they can attach a debugger, the TEE's confidentiality guarantee is broken. The whole point is that nobody outside the enclave sees what's inside — but "nobody" includes your own SREs at 3 AM during an incident.
What you can still do
Confidentiality doesn't mean zero visibility. It means the workload controls what leaves the enclave:
- Structured logs with classification — the application decides what to log. Sensitive data stays inside; operational signals (request counts, error rates, latency) go out.
- Metrics export — aggregate metrics that don't leak individual data points. A counter of "signing operations per minute" is safe. The signing keys are not.
- Health endpoints — liveness and readiness probes that report status without exposing state.
- Encrypted audit trails — the workload can encrypt detailed logs to a key that only authorized auditors can access, after the fact, with attestation-verified access controls.
The principle: the enclave is the declassification boundary. Nothing leaves without the application explicitly choosing to export it.
What you lose
- Live debugging — attaching a debugger to a TEE workload typically requires disabling confidentiality protections. On Intel TDX, debug mode disables measurement. A debuggable enclave is an unattested enclave.
- Memory dumps — the whole point of a TEE is that the host can't read guest memory. Core dumps from the host side are empty or encrypted.
- SSH access — if you SSH into a confidential VM, you're now inside the TEE. The session must be attested and access-controlled, or it becomes a backdoor.
- Full-fidelity logs — any log that contains request data, keys, or plaintext undermines the confidentiality guarantee if it leaves the enclave.
Design patterns
Log classification
Before deploying, classify every log line:
| Classification | Example | Handling |
|---|---|---|
| Public | Request count, error rate, latency p99 | Export to standard monitoring |
| Internal | Request IDs, workflow states | Export encrypted, restrict access |
| Confidential | Keys, plaintext data, PII | Never export. Audit in-enclave only. |
The classification must happen in the application, not in the logging infrastructure. By the time a log line reaches your SIEM, it's too late to redact it.
Debug builds vs. production builds
Some teams maintain a debug build with relaxed logging for development, and a production build with strict classification. This works — but the debug build has a different measurement hash. If your KBS is enforcing exact measurements (K3/K4), the debug build won't receive production secrets. This is a feature, not a bug.
Encrypted audit channels
For regulatory or forensic requirements, the workload can write detailed logs encrypted to an auditor's key. The auditor later requests access through the same attestation-verified path (K3/K4 enforcement). The logs exist, but they're only readable by someone who passes the same verification bar as the workload itself.
The KRAB connection
Observability decisions don't change your CoCo Vector — but they can undermine it operationally. A system with A3 | R4 | B2 | K4 that logs plaintext signing keys to CloudWatch has a perfect vector and zero confidentiality.
The vector measures verifiability. Observability determines whether you maintain confidentiality in practice. Both matter. Neither substitutes for the other.
Debug mode on most TEE platforms disables attestation measurements. A workload running in debug mode cannot be attested and will not receive secrets from a properly configured KBS. Never run debug mode in production — it's not a "less secure" mode, it's an "unattested" mode.
Design your logging taxonomy before deployment, not after the first incident. Every log line should have a classification. When in doubt, classify as confidential and relax later — it's much harder to reclassify public logs as confidential after they've been exported.