Confidential Service Mesh

Traditional service mesh sidecars run as privileged containers on the host OS, exposing them to kernel-level attacks. In a confidential mesh, the Envoy proxy or a lightweight equivalent executes inside the same TEE enclave as the application container. This co-location ensures that TLS termination, mTLS handshakes, and request decryption occur within the hardware-protected boundary. The sidecar's private keys are sealed to the enclave's identity, making them inaccessible to the host operating system, hypervisor, or cloud provider. This architecture eliminates the sidecar as an attack vector for intercepting plaintext service-to-service traffic.

Mutual TLS in a confidential mesh is augmented with hardware attestation as a precondition for connection establishment. Before a TLS handshake completes, each sidecar presents a cryptographic attestation report—signed by the CPU manufacturer—that proves:

• The exact enclave code hash (measurement) running
• The TEE hardware's authenticity and firmware version
• The security configuration of the execution environment

A centralized attestation service or SPIRE agent validates these reports. If attestation fails, the connection is refused at the network layer, preventing untrusted or compromised workloads from joining the mesh.

All inter-service communication traverses TLS 1.3 tunnels with cipher suites that leverage hardware-accelerated encryption. The session keys for these tunnels are generated and stored exclusively within the enclave's encrypted memory pages. This provides defense-in-depth: even if an attacker compromises the host kernel and captures raw network packets, they observe only ciphertext. The mesh enforces strict east-west traffic encryption with automatic certificate rotation, where private keys never leave the TEE boundary. This is distinct from standard mesh encryption, where keys reside in host memory accessible to privileged users.

Authorization policies—such as which services can call a billing API or access a PII database—are evaluated inside the enclave rather than in a host-level sidecar. The policy engine runs as part of the attested workload, ensuring that:

• Policy decisions cannot be tampered with by the infrastructure operator
• Audit logs of access decisions are cryptographically signed by the enclave
• Fine-grained claims (OAuth scopes, SPIFFE IDs) are validated in a trusted context

This moves the policy decision point from the infrastructure layer to the application's trusted computing base, closing a gap where a compromised host could silently disable authorization checks.

Service discovery in a confidential mesh must not leak the topology or existence of sensitive services to the underlying platform. The mesh uses encrypted DNS and gossip protocols that operate within the TEE boundary. Service endpoints are registered with attestation-bound identities, and the discovery cache is maintained in enclave memory. This prevents the cloud provider or a network observer from enumerating the microservices running in a confidential cluster. Integration with SPIRE ensures that only attested workloads can register or resolve service names, preventing spoofing attacks on the discovery mechanism.

TLS certificates, API tokens, and database credentials are delivered to the mesh sidecar only after successful attestation. A Confidential Key Management Service releases secrets directly into the enclave's memory over a secure channel. The secrets are then sealed to the enclave's identity for persistent caching, meaning they can only be decrypted by the exact same workload on the exact same CPU. This eliminates the risk of secrets being extracted from environment variables, Kubernetes secrets, or configuration files by a compromised host. Secret rotation occurs automatically without any plaintext exposure to the infrastructure layer.

Defensive techniques that prevent attackers from extracting secrets by observing physical side effects of computation within a Confidential Service Mesh. Even though memory is encrypted, subtle leaks through timing, power consumption, or cache access patterns can reveal sensitive data.

• Constant-time cryptographic algorithms eliminate timing variations
• Cache partitioning prevents cross-enclave interference
• Hardware mitigations in Intel TDX and AMD SEV-SNP address speculative execution attacks

A Confidential KMS releases decryption keys only to workloads that have successfully attested their identity and integrity. The KMS validates the enclave measurement against a policy before unwrapping a key. This ensures secrets are only accessible inside verified Trusted Execution Environments.

• Binds keys to specific enclave identities
• Prevents the host or hypervisor from accessing plaintext secrets
• Essential for securing TLS private keys and data encryption keys in the mesh

A Kubernetes scheduler extension that understands the hardware requirements and security constraints of Trusted Execution Environments. It places enclave workloads only on nodes with compatible TEE capabilities, such as Intel SGX or AMD SEV-SNP, and respects node-level attestation status.

• Prevents scheduling confidential pods on non-TEE nodes
• Integrates with device plugins for TEE resource advertising
• Ensures the mesh control plane only routes to verified enclaved endpoints