Enclave-Aware Scheduler

The scheduler uses node labels to identify hardware with specific TEE capabilities (e.g., intel.sgx.epc.memory, amd.sev.snp.enabled). It automatically applies taints and tolerations to prevent non-enclave workloads from landing on security-critical nodes. This guarantees that standard pods cannot be accidentally scheduled onto hardware reserved for confidential computing, maintaining strict workload isolation at the infrastructure level.

Before binding a pod to a node, the scheduler queries an attestation service to cryptographically verify the node's hardware and firmware integrity. The scheduling decision is gated on a successful remote attestation quote, ensuring the target TEE is genuine and running a trusted firmware version. This prevents workloads from being placed on compromised or misconfigured hardware, enforcing a zero-trust deployment model.

TEEs like Intel SGX have a limited Enclave Page Cache (EPC). The scheduler must account for this scarce, encrypted memory resource as a first-class schedulable quantity, similar to CPU or RAM. It tracks available EPC per node and only places enclave pods if sufficient encrypted memory exists, preventing out-of-memory failures within the secure enclave at runtime.

The scheduler leverages Kubernetes device plugins to advertise specialized TEE hardware resources. This framework allows the scheduler to discover and allocate specific quantities of sgx.intel.com/epc or nvidia.com/confidential-gpu to containers. It extends the standard resource model to handle heterogeneous, security-sensitive accelerators without modifying the core Kubernetes API.

Enclave-aware schedulers coordinate with a Confidential Key Management Service (KMS) to inject secrets only after successful attestation. The scheduler ensures that decryption keys are released exclusively to the verified enclave identity on the specific node where the pod was placed. This binds the secret to the hardware root of trust, making it inaccessible to the host OS or a malicious scheduler.

For Confidential VMs using AMD SEV-SNP or Intel TDX, the scheduler must manage live migration without breaking the encryption context. It coordinates with the hypervisor to transfer the encrypted VM state and re-verify attestation on the destination node. The scheduler enforces migration only to nodes within the same trusted compute pool, preventing a confidential workload from being moved to an untrusted physical host.

A cryptographic hash of the initial code, data, and configuration loaded into a TEE. This serves as a unique identity fingerprint that the scheduler uses to enforce policy.

• Ensures only a specific, known-good application version runs on a node
• The scheduler can reject nodes where the measurement doesn't match the expected value
• Critical for model provenance attestation in AI inference pipelines