Confidential Computing on Kubernetes in 2026: Protecting Data-in-Use with Hardware TEEs, Remote Attestation, and Confidential Containers

We have spent a decade getting good at two of the three states of data. Data-at-rest is encrypted on disk; data-in-transit is wrapped in TLS. The third state — data-in-use, the plaintext sitting in RAM while a CPU actually computes on it — has always been the exposed one. Anything with control of the machine underneath your workload can read it: the hypervisor, the host kernel, a compromised cloud operator, a malicious co-tenant who broke isolation, or anyone with physical access and a memory bus. For most of computing history this was simply accepted. You trusted the infrastructure because you had no cryptographic alternative.

Hardware confidential computing removes that assumption. A Trusted Execution Environment (TEE) — AMD SEV-SNP, Intel TDX, Arm CCA — encrypts a workload's memory with a key held inside the CPU package and never exposed to software outside the boundary. The hypervisor can schedule the VM, but it cannot read its memory. The host can crash it, but it cannot peer inside. For engineering teams who want to own the systems they depend on, this is the frontier of sovereignty: it lets you run a workload on infrastructure you do not control or fully trust, and still hold a cryptographic guarantee that the operator of that infrastructure cannot see your data. This article is about how that guarantee works on Kubernetes, why it is worth nothing without remote attestation, and how attestation gates the release of your secrets so a workload only ever runs on verified, untampered hardware.

The short version of the thesis: encryption-in-use is the mechanism, but attestation is the trust. A TEE that you cannot verify is just a black box making promises. Attestation turns the promise into a proof — a hardware-signed measurement of exactly what is running — and that proof becomes the gate that controls whether your keys, secrets, and encrypted data are ever released into the environment. Get the attestation design right and you have audit-grade trust rooted in silicon. Get it wrong, or skip it, and you have an expensive VM with a confidential-sounding name.

The Third State of Data: Why Encryption-in-Use Changes the Trust Model

Confidential computing's defining move is to shrink the Trusted Computing Base (TCB) — the set of components that must be correct and honest for your security to hold. In a conventional cloud VM, the TCB includes the guest OS, the hypervisor, the host kernel, the firmware, the cloud control plane, and by extension the cloud operator's staff and supply chain. That is an enormous surface to trust. A TEE collapses it. With AMD SEV-SNP or Intel TDX, the hardware encrypts guest memory with a per-VM key managed by the CPU's secure processor, and the TCB shrinks to the guest workload, the guest kernel, and the CPU silicon itself. The hypervisor and host are explicitly moved *outside* the boundary — present, necessary for scheduling and I/O, but no longer trusted to keep a secret.

SEV-SNP (Secure Encrypted Virtualization–Secure Nested Paging) adds memory-integrity protection on top of AMD's earlier memory-encryption work, defeating the replay and remapping attacks that undermined first-generation SEV. Intel TDX (Trust Domain Extensions) takes a similar approach with a different architecture: a hardware-isolated Trust Domain whose memory and CPU state are inaccessible to the VMM and the host. Both establish what the Confidential Computing Consortium — a Linux Foundation project that has grown from seven founding members in 2019 to more than fifty in 2026 — defines as the baseline: protection of data-in-use by performing computation in a hardware-based, attested TEE.

This trust-model shift is precisely why confidential computing reads as a sovereignty capability rather than just another security feature. It decouples *where* a workload runs from *who can see it*. A regulated workload can execute on shared or third-party infrastructure while the data it processes stays cryptographically opaque to the infrastructure owner. That is the property that makes self-hosting, cloud repatriation, and multi-tenant platforms defensible in environments where the threat model explicitly includes the operator — which, increasingly, regulators expect it to.

The Trust Boundary: What Is Inside the TCB and What Is Decisively Out

Click to zoom

Drawing the boundary precisely is the whole discipline. Inside the TCB you have the guest workload, the guest kernel, the in-use plaintext in encrypted memory, and the measured guest firmware that booted the VM. Outside it — and this is the part that takes adjustment — you have the hypervisor, the host kernel, the cloud operator, the BIOS/UEFI of the host, the orchestration control plane, and every other tenant on the box. They are all assumed compromised for the purposes of your threat model. The TEE does not ask you to trust them; it asks you to trust the CPU manufacturer's silicon root of trust, and nothing else.

That root of trust is concrete hardware. On AMD, it is the AMD Secure Processor, which derives a per-chip Versioned Chip Endorsement Key (VCEK) from the chip's unique secrets and the running firmware/microcode version. The VCEK chains up to AMD's SEV Signing Key (ASK) and ultimately to the self-signed AMD Root Key (ARK) — a certificate chain you can validate offline against AMD's published roots. On Intel, the TDX module measures the trust domain and the platform's Quoting Enclave signs attestation quotes that chain to Intel's provisioning certification authority. In both cases the trust ultimately terminates at a key burned into silicon by the manufacturer, not at any software the operator controls.

Two honest caveats belong in any serious treatment. First, you are trading trust in the cloud operator for trust in the CPU vendor — confidential computing does not eliminate trust, it relocates it to a party whose business depends on the silicon being sound and whose root keys are publicly auditable. For most regulated workloads that is a vastly better trade, but it is a trade, not a free lunch. Second, the boundary protects confidentiality and integrity of compute and memory; it does not by itself protect against side-channels, denial of service by the host (which can always refuse to schedule you), or a vulnerability in your own workload. The TCB is small, but what is in it still has to be correct.

Remote Attestation: Turning a Hardware Promise into a Verifiable Proof

Click to zoom

The IETF formalized the vocabulary in RFC 9334, the RATS (Remote ATtestation procedureS) Architecture, and using it precisely prevents most of the confusion in this space. Four roles matter. The Attester is the thing being vouched for — your workload running inside the TEE. It produces Evidence: a hardware-signed report describing its state. The Verifier appraises that Evidence against trusted inputs and produces Attestation Results. The Relying Party consumes those results and makes a policy decision — in our case, whether to release a key. Feeding the Verifier are two supply-chain roles: the Reference Value Provider supplies the known-good measurements to compare against, and the Endorser supplies Endorsements — the manufacturer's statement that the signing key genuinely belongs to genuine hardware.

The Evidence is the cryptographic heart of it. On SEV-SNP, the Secure Processor takes a launch measurement — a SHA-384 digest of the initial guest memory and configuration captured before the VM's firmware executes — and places it, along with VM metadata and a verifier-supplied nonce (which defeats replay), into an ATTESTATION_REPORT structure signed by the VCEK. On TDX, the module records the launch state in the MRTD (Measurement of the Trust Domain) and subsequent boot stages into RTMRs (Run-Time Measurement Registers), assembles a TDREPORT, and the platform converts it into a signed TD Quote. Either way, the output is a structure that says, in effect: *this exact code and configuration is running, on genuine and unmodified TEE hardware, right now, in response to your specific challenge.*

Appraisal is where policy lives. The Verifier checks the signature chains to the manufacturer root (is the hardware genuine?), compares the measurement against Reference Values (is this the firmware and image we expect?), checks the reported TCB/microcode version against a minimum (is it patched against known attacks?), and confirms the nonce matches (is this fresh, not replayed?). Only if every check passes does it emit a positive Attestation Result. This is the audit-grade rigor distinction in its purest form: the decision to trust is not a configuration toggle a human flipped, it is a cryptographic appraisal that produces evidence an auditor can independently re-verify.

Attestation-Gated Key Release: The Mechanism That Actually Protects Anything

Attestation produces a verdict; on its own, a verdict does nothing. The control comes from binding secret release to that verdict. The pattern that does real work is conditional key release: your encrypted container image, your database credentials, your data-decryption keys — none of them are baked into the image or handed over at boot. They live in a Key Broker Service (KBS) outside the workload. The workload, on startup, asks for them. The KBS refuses to answer until the workload presents valid attestation Evidence. Only a workload that can prove — to the silicon — that it is the right code on genuine, patched hardware ever receives the keys.

This inverts the usual secret-distribution problem in a way that is hard to overstate. In a conventional setup, a stolen image or a leaked manifest can carry secrets straight out of the building. Under attestation-gated release there is nothing to steal at rest: the secret only materializes inside a verified TEE, in encrypted memory the operator cannot read, and only after a live cryptographic proof. An attacker who exfiltrates the image gets ciphertext. An attacker who boots it on untrusted hardware fails attestation and gets nothing. An attacker who tampers with one byte of the workload changes the launch measurement, fails appraisal, and gets nothing. The key is the reward for being provably correct, and only provably correct.

Confidential Containers implements this with lazy (conditional) attestation: the attestation handshake is triggered precisely when a secret is needed — for example, the key to decrypt an encrypted container image, or a credential the workload requests at runtime — rather than as an unconditional boot step. The result is a clean separation of concerns: the hardware proves the environment, the KBS owns the secrets, and the policy that connects them is the single, auditable place where you decide what counts as trustworthy. This is the same secret-management discipline we apply with External Secrets and Vault, pushed one layer deeper — the secret store now demands a hardware proof of the consumer's identity and integrity before it answers at all.

# Trustee KBS resource policy (Rego/OPA-style) — release a key only when the
# workload's attestation Evidence appraises clean. The KBS is the Relying Party:
# it consults the Attestation Service's results before handing back any secret.
package policy

default allow = false

allow {
    # 1. The Attestation Service verified the hardware evidence and signature
    #    chain (VCEK -> ASK -> ARK on SEV-SNP, or the TD Quote chain on TDX).
    input.tee in {"snp", "tdx"}
    input.attestation_status == "verified"

    # 2. The launch measurement matches a known-good reference value supplied
    #    by the Reference Value Provider Service (RVPS). One byte of drift in
    #    the guest image or firmware changes this digest and denies the key.
    input.measurement == data.reference_values.guest_launch_digest

    # 3. The platform TCB / microcode is at or above the patched minimum —
    #    a downgraded, vulnerable TEE is refused even if it is otherwise genuine.
    input.tcb_version >= data.reference_values.min_tcb_version

    # 4. The request targets a key this workload identity is entitled to.
    input.resource_path == "default/decryption-key/db-credentials"
}

Confidential Containers (CoCo): Bringing TEEs to a Kubernetes Pod

Click to zoom

Confidential Containers (CoCo) is the CNCF sandbox project that makes all of this work with an ordinary Kubernetes pod spec. It builds on Kata Containers — the runtime that already isolates pods in lightweight VMs — and extends it so each pod boots into a hardware TEE rather than a normal VM. You install the CoCo operator, it registers a set of RuntimeClass objects (for example kata-qemu-snp, kata-qemu-tdx), and a workload opts in simply by setting runtimeClassName on its pod. The threat model the CoCo project targets explicitly includes the cluster operator and the host: the goal is that even a fully compromised host cannot read the pod's data.

The components split cleanly across the trust boundary. Inside the confidential guest run the guest-components: the Attestation Agent (AA), which gathers hardware Evidence and speaks the attestation protocol, and the Confidential Data Hub (CDH), which handles secret retrieval and image decryption on the workload's behalf. The AA's modular Key Broker Client design lets the same guest support multiple TEEs (SEV-SNP, TDX, and others) behind a common interface. Outside the guest, in your control plane, runs Trustee — the attestation and secret-delivery service. Trustee bundles the Key Broker Service (KBS) (the Relying Party that releases secrets), the Attestation Service (AS) (the Verifier that appraises Evidence), and the Reference Value Provider Service (RVPS) (which supplies the known-good measurements). The mapping to RATS is exact, which is what makes the architecture reason-about-able.

# A confidential pod: opt into a TEE-backed runtime and pull an encrypted image
# whose decryption key is released only after the guest attests successfully.
apiVersion: v1
kind: Pod
metadata:
  name: confidential-inference
  namespace: regulated-workloads
spec:
  # The CoCo operator registers this RuntimeClass; it boots the pod into an
  # AMD SEV-SNP confidential VM via Kata. Swap for kata-qemu-tdx on Intel.
  runtimeClassName: kata-qemu-snp
  containers:
    - name: model-server
      # Encrypted image: the layer is ciphertext in the registry. The in-guest
      # Confidential Data Hub fetches the decryption key from the KBS, which
      # releases it ONLY if this guest's attestation Evidence appraises clean.
      image: registry.internal/regulated/inference:enc-2026.06
      resources:
        limits:
          memory: 16Gi
  # The annotation tells the Confidential Data Hub which KBS (Trustee) to
  # attest against. The KBS URL and its trust roots are pinned, not discovered.
  # No plaintext secret is present anywhere in this manifest.

The elegance here is that the application is largely unchanged. A developer writes an ordinary pod spec; the platform team owns the RuntimeClass, the encrypted-image pipeline, and the Trustee policy. The confidentiality is a property the platform provides, not a library the application links against — which is exactly the golden-path division of responsibility that keeps these capabilities adoptable rather than boutique. Recent research has pushed this further toward pod-granularity attestation with end-to-end times measured in tens of milliseconds, narrowing the historical gap between the security of a VM-per-pod model and the density Kubernetes operators expect.

GPUs, Confidential AI, and the State of the Hardware in 2026

The most active 2026 frontier is confidential AI: running model inference — and increasingly training on sensitive data — inside a TEE so neither the model weights nor the input data are visible to the infrastructure. This needs the TEE boundary to extend off the CPU and onto the accelerator. NVIDIA's Confidential Computing mode does exactly that on H100, H200, and Blackwell-class parts (B200, GB200), encrypting data over the PCIe bus between the confidential VM and the GPU and producing its own attestation that composes with the CPU's. The GB200 generation integrates CPU-side SEV-SNP or TDX directly with the GPU TEE, so a single attestation can cover the whole compute path.

Attestation policy is keeping pace. Verifier implementations now support composite policies that appraise Evidence from multiple technologies at once — for example, requiring that a workload prove it is running on *both* an Intel TDX trust domain *and* a genuine NVIDIA H100 in CC mode before a key is released. For a self-hosted LLM platform handling regulated data, this is the difference between 'the data is encrypted on disk' and 'the data is never visible in plaintext to anyone but the verified model server, not even on the GPU.' It is a meaningful new capability for healthcare, finance, and any setting where the input prompts themselves are the sensitive asset.

Where Confidential Computing Earns Its Cost — and Where It Does Not

Confidential computing is a sharp tool with a specific edge. It is most defensible where the threat model genuinely includes the infrastructure operator or the platform underneath you — and where you can articulate, to an auditor, why the operator is in scope. The patterns that pay for the overhead are concrete:

• Regulated data on infrastructure you do not fully control — processing PII, PHI, or financial data on shared, hosted, or third-party platforms where the contractual and regulatory posture requires that the operator provably cannot access plaintext.
• Confidential AI — inference or fine-tuning on sensitive prompts or proprietary weights, where the input data and the model itself must stay opaque to the host, including across the CPU↔GPU boundary.
• Multi-party computation and clean rooms — several organizations contributing data to a shared computation where each party must be assured, by attestation, that the others cannot see their inputs and that only the agreed code runs.
• Key and secret protection — running a CA, an HSM-adjacent signing service, or a secrets broker inside a TEE so that even root on the host cannot extract the keys, with attestation gating their release.
• Verifiable sovereign deployments — proving to a customer, regulator, or partner that a workload runs unmodified on attested hardware, producing cryptographic evidence rather than a contractual assurance.

Equally important is knowing when *not* to reach for it. If your threat model does not include the operator — a workload on hardware you own, in a facility you control, with staff you trust — then confidential computing adds cost and complexity to defend against an adversary you have already excluded. It is not a substitute for the rest of your security program: you still need supply-chain attestation of the image you run, admission control, network policy, and patching. A TEE running a vulnerable, compromised, or unsigned image faithfully protects the attacker's foothold from the host operator. Confidential computing protects the *environment*; the rigor of *what you put in it* is still yours to own.

And it composes with the rest of the optionality argument rather than competing with it. Because attestation is rooted in open standards — RFC 9334, the CoCo project's open guest-components and Trustee, vendor root certificates you can validate offline — a confidential-computing posture does not lock you to a single cloud's proprietary enclave service. The same attestation policy can gate key release whether the verified hardware sits in AWS, Azure, GCP, or a Talos cluster on your own bare metal. That portability is the point: the proof travels with the workload, not with the provider.

Cryptographic Proof, Not Promises

Strip away the acronyms and confidential computing makes a single, powerful claim: you can run a workload on infrastructure you do not trust and still hold a hardware-signed proof of exactly what is running and that nothing underneath it can see your data. The TEE provides the encryption-in-use. Remote attestation — Attester, Evidence, Verifier, Relying Party, appraised against pinned reference values and manufacturer endorsements — provides the proof. And attestation-gated key release turns that proof into an enforced control: secrets only ever reach a workload that has cryptographically demonstrated it deserves them.

For the audiences this matters most to — security and compliance leaders defending regulated workloads, platform teams building multi-tenant systems, CTOs weighing where their most sensitive computation can safely run — the appeal is that the trust is *checkable*. Not a vendor's word, not a configuration someone swears is correct, but evidence an auditor, a regulator, or your own monitoring can independently re-verify against published roots. That is the standard Stribog holds infrastructure to: audit-grade rigor means the control produces proof by design, and the proof outlives the person who configured it.