Add Trusted Execution Environment (TEE) support via Confidential Containers (CoCo)

[bussyjd]

Summary

Add support for running Obol Stack workloads in hardware-based Trusted Execution Environments (TEEs) using Confidential Containers (CoCo), enabling secure, attested execution on both Intel (SGX/TDX) and AMD (SEV/SEV-SNP) platforms with a uniform Kubernetes-native interface.

Background

Confidential Containers (CoCo) is a CNCF sandbox project and the de facto open-source standard for running Kubernetes pods uniformly in hardware-based TEEs. It provides a vendor-neutral, portable solution for confidential computing across heterogeneous hardware.

Why CoCo?

• Cross-platform support — Single pod spec works across Intel (SGX/TDX) and AMD (SEV/SEV-ES/SEV-SNP) platforms
• Industry backing — Supported by Red Hat, Intel, AMD, IBM, Microsoft, and major cloud providers
• Kubernetes-native — Deployed as a cluster operator with standard RuntimeClasses
• Production-ready — Available on bare metal and major clouds (Azure, GCP, AWS)

Key Features

1. Cross-Platform TEE Support

Abstracted via Kata Containers runtime, supporting:

• AMD: SEV/SEV-ES/SEV-SNP (via kata-qemu-sev or kata-qemu-snp)
• Intel TDX: VM-based isolation (via kata-qemu-tdx)
• Intel SGX: Process-based enclaves (via enclave-cc)
• IBM Secure Execution and others

2. Transparent Workload Experience

Pod authors simply specify runtimeClassName:

spec:
  runtimeClassName: kata-qemu-snp  # or kata-qemu-tdx / kata-qemu-sev / enclave-cc

CoCo handles:

• Image pulling/verification/decryption inside TEE
• Remote attestation
• Secret injection via Key Broker Service (KBS)

3. Intelligent Scheduling

Combined with Node Feature Discovery (NFD), CoCo automatically:

• Labels nodes with TEE capabilities
• Schedules confidential pods on appropriate hardware
• Supports heterogeneous clusters with mixed TEE types

Example node labels (auto-applied):

feature.node.kubernetes.io/confidential-computing-amd-sev-snp=true
feature.node.kubernetes.io/confidential-computing-intel-tdx=true

Benefits for Obol Stack

Security

• Hardware-attested execution — Cryptographic proof that workloads run in genuine TEEs
• Memory encryption — Runtime memory protected from host/hypervisor
• Secret protection — Private keys and sensitive data secured in enclaves

Use Cases for Obol

1. Distributed Validator (DVT) operators — Protect validator private keys in TEEs
2. Aztec attesters — Secure attester private keys in hardware enclaves
3. Multi-party computation — Run sensitive consensus operations in verified environments
4. Compliance — Meet regulatory requirements for key material protection

Portability

• Cloud and bare metal — Same workload runs on any TEE-capable infrastructure
• Future-proof — Support for emerging TEE technologies (e.g., ARM CCA)

Implementation Approach

Phase 1: CoCo Operator Integration

1. Install CoCo operator in obol-stack cluster during obol stack init
2. Deploy Node Feature Discovery for automatic TEE detection
3. Create default RuntimeClasses for common TEE types

# Modified obolup.sh or helm chart
kubectl apply -f https://github.com/confidential-containers/operator/releases/latest/download/operator.yaml
kubectl apply -f https://github.com/kubernetes-sigs/node-feature-discovery/releases/latest/download/nfd-master.yaml

Phase 2: TEE-Aware Application Deployment

Add --tee flag to network installation:

obol network install aztec \
  --attester-private-key <KEY> \
  --tee intel-tdx \  # or amd-sev-snp, intel-sgx
  --l1-execution-url https://geth-prysm-mainnet-1.gcp.obol.tech/ \
  --l1-consensus-url https://prysm-geth-mainnet-1.gcp.obol.tech/

Phase 3: Attestation & Key Management

Integrate with CoCo Key Broker Service:

• Store sensitive keys (validator keys, attester keys) in KBS
• Inject into TEE pods after attestation verification
• Support for external KBS providers (Intel Trust Authority, Azure Attestation)

Example Pod Specification

apiVersion: v1
kind: Pod
metadata:
  name: aztec-attester-confidential
  namespace: aztec
spec:
  runtimeClassName: kata-qemu-snp  # AMD SEV-SNP TEE
  
  # Allow scheduling on any TEE-capable node
  tolerations:
  - key: confidential-computing
    operator: Exists
    effect: NoSchedule
  
  nodeSelector:
    feature.node.kubernetes.io/confidential-computing: "true"
  
  containers:
  - name: aztec-node
    image: aztecprotocol/aztec:latest
    env:
    - name: ATTESTER_PRIVATE_KEY
      valueFrom:
        secretRef:
          name: aztec-attester-key  # Injected by KBS after attestation

Comparison with Alternatives

Approach	Intel SGX	Intel TDX	AMD SEV-SNP	Uniform pod spec?	Notes
Confidential Containers (CoCo)	✅	✅	✅	✅	Industry standard, vendor-neutral
Azure AKS Confidential	✅ (SGX)	Limited	✅	Partial	Cloud-specific, uses CoCo under hood
Intel SGX device plugin	✅	❌	❌	❌	Legacy, SGX-only
AWS Nitro / GCP Confidential VMs	❌	❌	Partial	❌	Not portable

CoCo is the only fully open, vendor-neutral solution for portable TEE workloads.

Implementation Tasks

• Add CoCo operator to embedded applications or default deployment
• Create RuntimeClass templates for common TEE types
• Integrate Node Feature Discovery for TEE capability detection
• Add --tee flag to obol network install command
• Document TEE hardware requirements and setup
• Add KBS integration for secret injection
• Create example configurations for Aztec + other networks in TEEs
• Add monitoring/observability for TEE-enabled workloads
• Write user guide for TEE deployment

References

• Confidential Containers (CoCo) Project
• CoCo Documentation
• Kata Containers
• Node Feature Discovery
• Intel Trust Authority
• AMD SEV-SNP
• Intel TDX

Target Audience

• Validator operators requiring hardware key protection
• Enterprise users with compliance requirements
• Security-conscious node runners
• Multi-party computation workloads

Success Metrics

• Successfully deploy Aztec node in AMD SEV-SNP TEE
• Successfully deploy Aztec node in Intel TDX TEE
• Verify attestation and secret injection workflow
• Document performance overhead (<10% target)
• Gather community feedback on TEE deployment

---

Priority: Medium-High
Complexity: Medium
Timeline: Q1-Q2 2025 (pending hardware availability)