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

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)

Start by tracing the obol stack init flow, the obolup.sh or Helm chart deployment path, and the obol network install command. Define the work across the listed phases, then validate the requested RuntimeClasses, TEE-aware Aztec deployment, attestation and secret injection, documentation, and success metrics.