Enclave-Aware Orchestration

The scheduler integrates with remote attestation services to verify an enclave's identity and integrity before placing a pod. This ensures secrets and sensitive workloads are only provisioned to nodes that can cryptographically prove they are running the correct, untampered code.

• Validates MRENCLAVE and MRSIGNER measurements against policy
• Integrates with Intel DCAP or AMD SEV-SNP attestation services
• Prevents scheduling on compromised or non-compliant hardware

Orchestrators must securely deliver secrets to enclaves without exposing them to the untrusted host OS or Kubernetes API server. This is achieved by encrypting secrets to a specific enclave's public key, ensuring only that attested enclave can decrypt them.

• Leverages Data Sealing primitives for stateful workloads
• Integrates with HashiCorp Vault and cloud KMS for key release policies
• Secrets are never visible to the underlying node or hypervisor

Standard container runtimes cannot manage hardware enclaves. Enclave-aware orchestration uses specialized Container Runtime Interface (CRI) shims and device plugins to manage the full lifecycle of Confidential Containers and Confidential VMs.

• Manages ECALL and OCALL interface boundaries
• Handles enclave creation, memory paging, and destruction
• Supports live migration of encrypted VMs with AMD SEV-SNP

Trusted Execution Environments consume a critical, limited hardware resource: the Enclave Page Cache (EPC) or equivalent protected memory. The orchestrator must account for this resource to prevent over-subscription and denial-of-service.

• Tracks EPC memory as a schedulable, allocatable resource
• Enforces node-level limits on concurrent enclave count
• Prevents noisy-neighbor scenarios that degrade enclave performance

Workloads requiring Confidential Computing must be automatically placed on nodes with the correct hardware capabilities. Orchestrators use node feature discovery and affinity rules to match workloads to Intel TDX, AMD SEV-SNP, or ARM CCA enabled machines.

• Uses Node Feature Discovery (NFD) to label TEE-capable hardware
• Defines required node affinity in pod specifications
• Ensures non-confidential workloads don't consume scarce TEE resources

Enclave-aware orchestration extends data-in-use protection to the network layer by establishing mutually attested, encrypted channels between enclaves. This creates a zero-trust network fabric where communication is encrypted end-to-end, even between pods on the same node.

• Establishes mTLS tunnels with attestation-bound certificates
• Integrates with service mesh proxies like Envoy for transparent encryption
• Protects against host-level network sniffing and man-in-the-middle attacks

The cryptographic process by which a TEE proves its identity, integrity, and security posture to a remote relying party. Enclave-aware orchestrators must integrate attestation verification into the scheduling pipeline before provisioning secrets or routing traffic.

• Verifies MRENCLAVE or MRSIGNER measurements against known good values
• Orchestrator acts as the relying party in the attestation flow
• Failed attestation must trigger rescheduling or quarantine of the workload

Containerized workloads deployed within a hardware-enforced TEE, combining the agility of Kubernetes with data-in-use protection. This is the primary workload unit that enclave-aware orchestration schedules and manages.

• Uses Kata Containers or similar sandboxed runtimes with TEE backends
• Requires attested container images to verify integrity before decryption
• Orchestrator must handle encrypted image pulls and secure secret injection

Full virtual machine instances running inside a hardware-backed TEE, encrypting their entire memory space. Technologies like AMD SEV-SNP and Intel TDX enable orchestrators to protect legacy monolithic workloads without code modification.

• Provides strong isolation boundary at the VM level
• Orchestrator must be aware of memory encryption capabilities per node
• Supports live migration of encrypted VMs between compatible hosts

A set of security instruction codes that allow user-level code to allocate private memory regions called enclaves. Enclave-aware orchestrators must manage SGX's Enclave Page Cache (EPC) limits, which typically cap at 512MB or 1GB per socket.

• Requires ECALL/OCALL interfaces for enclave-host communication
• Orchestrator must track EPC memory availability as a schedulable resource
• DCAP infrastructure enables scalable, data-center-local attestation

Extends TEE protections to GPU-accelerated workloads, enabling secure AI training and inference on protected data. Enclave-aware orchestrators must schedule workloads onto GPU nodes that support encrypted PCIe links and attested GPU firmware.

• Protects model weights and training data during GPU computation
• Requires GPU attestation in addition to CPU TEE verification
• Critical for Confidential AI and private inference at scale