Confidential Containers (CoCo) — Running Code Nobody Else Can See, Not Even the Cloud Provider

The One-Liner

Confidential Containers encapsulates pods inside of confidential virtual machines, allowing Cloud Native workloads to leverage confidential computing hardware with minimal modification. Your code and data are encrypted in memory — not even the cloud provider, the host OS, or the Kubernetes admin can see what’s running inside.

The Problem: You Trust Your Cloud Provider with Everything

When you deploy a container to AWS, GCP, or Azure, here’s who CAN access your running data:

WHO CAN SEE YOUR DATA IN A NORMAL CONTAINER
═══════════════════════════════════════════════════

Your application data in memory:
  ✅  Your code (obviously)
  ⚠️  Cloud provider employees (with access to hypervisor)
  ⚠️  Host OS administrator (root on the node)
  ⚠️  Kubernetes cluster admin (can exec into pods)
  ⚠️  Hypervisor (can read guest VM memory)
  ⚠️  Anyone with physical access to the server
  ⚠️  A compromised kernel or hypervisor
  ⚠️  Government agencies with provider cooperation

Your data at rest:  Encrypted ✅ (disk encryption)
Your data in transit: Encrypted ✅ (TLS)
Your data IN USE:   UNENCRYPTED ❌ (plaintext in RAM)

We encrypt data when it’s stored (at rest) and when it’s moving (in transit). But when the CPU is actually processing it — when it’s in use — it sits in memory as plaintext. Anyone with hypervisor access or physical access to the machine can read it.

For most workloads, this is fine. You trust AWS. You trust Google. But for some workloads — healthcare records, financial models, AI models with proprietary training data, government systems, multi-party computation — trusting the infrastructure provider isn’t acceptable.

THE THREE STATES OF DATA
═══════════════════════════════════════════════════

Data at REST     → Encrypted ✅  (AES disk encryption)
  Files on disk, databases, object storage.
  Solved decades ago.
Data in TRANSIT  → Encrypted ✅  (TLS/HTTPS)
  Network traffic between services.
  Solved decades ago.
Data in USE      → PLAINTEXT ❌  (sitting in RAM)
  Application memory while the CPU processes it.
  THIS is what Confidential Computing solves.

The Solution: Trusted Execution Environments (TEEs)

Confidential Containers are cloud-native security constructs that employ Trusted Execution Environments (TEEs) to ensure confidentiality and integrity of containerized workloads deployed on potentially untrusted infrastructure.

A TEE is a hardware-enforced secure enclave inside the CPU. Data inside the TEE is encrypted in memory by the CPU itself. Not by software — by the silicon. The hypervisor can’t read it. The OS can’t read it. Even someone with physical access to the RAM chips can’t read it.

NORMAL CONTAINER:
═══════════════════════════════════════════════════
┌──────────────────────────────────────────────┐
│  Host OS / Hypervisor (can see everything)   │
│                                              │
│  ┌──────────────────────────────────────┐    │
│  │  Container                           │    │
│  │  ┌──────────────────────────────┐    │    │
│  │  │  Application Memory          │    │    │
│  │  │  [plaintext data in RAM]     │◄───│────│── Host admin can read
│  │  │  [API keys, PII, models]     │◄───│────│── Hypervisor can read
│  │  └──────────────────────────────┘    │    │── Physical access can read
│  └──────────────────────────────────────┘    │
└──────────────────────────────────────────────┘

CONFIDENTIAL CONTAINER:
═══════════════════════════════════════════════════
┌──────────────────────────────────────────────┐
│  Host OS / Hypervisor (CANNOT see inside)    │
│                                              │
│  ┌──────────────────────────────────────┐    │
│  │  Hardware TEE (encrypted by CPU)     │    │
│  │  ╔══════════════════════════════╗    │    │
│  │  ║  Container                   ║    │    │
│  │  ║  ┌──────────────────────┐    ║    │    │
│  │  ║  │ Application Memory   │    ║    │    │
│  │  ║  │ [ENCRYPTED in RAM]   │    ║◄───│────│── Host admin: sees gibberish
│  │  ║  │ [hardware enforced]  │    ║◄───│────│── Hypervisor: sees gibberish
│  │  ║  └──────────────────────┘    ║    │    │── Physical access: sees gibberish
│  │  ╚══════════════════════════════╝    │    │
│  └──────────────────────────────────────┘    │
└──────────────────────────────────────────────┘
The CPU encrypts/decrypts on the fly.
Data is ONLY plaintext inside the CPU itself.
Everywhere else - RAM, bus, cache - it's encrypted.

How CoCo Works on Kubernetes

For developers, running a confidential workload requires minimal changes to the existing Kubernetes workflow. The only change needed is specifying the appropriate runtimeClassName in the deployment or pod definition.

# NORMAL pod (no confidential computing)
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
    - name: my-app
      image: ghcr.io/myorg/my-sensitive-app:v1

---

# CONFIDENTIAL pod (one line added)
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  runtimeClassName: kata-cc      # ← THIS IS THE ONLY CHANGE
  containers:
    - name: my-app
      image: ghcr.io/myorg/my-sensitive-app:v1

That’s it. One line: runtimeClassName: kata-cc. Your pod now runs inside a hardware-encrypted TEE.

What Happens Under the Hood

CoCo leverages Kata, an open-source project that runs pods inside microVMs — stripped-down, barebone VMs optimized for containers. In the case of CoCo, the microVM is virtualized from hardware that supports confidential computing, effectively placing the entire pod inside a TEE.

THE CoCo ARCHITECTURE
═══════════════════════════════════════════════════

STEP 1: You apply the pod with runtimeClassName: kata-cc
STEP 2: CoCo Operator intercepts the pod creation
STEP 3: Instead of running the container directly,
        CoCo launches a microVM (lightweight VM) using
        Kata Containers runtime
STEP 4: The microVM runs on confidential computing hardware
        (Intel TDX, AMD SEV-SNP, or IBM SE)
        → Memory is encrypted by the CPU
STEP 5: Inside the TEE (trusted side):
        ┌────────────────────────────────────────┐
        │  Confidential MicroVM                  │
        │                                        │
        │  ┌─────────────────────────────────┐   │
        │  │  Kata Agent                     │   │
        │  │  (manages the container inside) │   │
        │  ├─────────────────────────────────┤   │
        │  │  Attestation Agent              │   │
        │  │  (proves to outside world that  │   │
        │  │   this TEE is genuine + intact) │   │
        │  ├─────────────────────────────────┤   │
        │  │  Confidential Data Hub (CDH)    │   │
        │  │  (fetches secrets + keys once   │   │
        │  │   attestation passes)           │   │
        │  ├─────────────────────────────────┤   │
        │  │  YOUR CONTAINER                 │   │
        │  │  (your actual application)      │   │
        │  └─────────────────────────────────┘   │
        └────────────────────────────────────────┘
STEP 6: Attestation Agent contacts Trustee service:
        "I'm running in a genuine TEE. Here's my
         hardware measurement proof."
STEP 7: Trustee verifies the attestation:
        "Yes, this is a real AMD SEV-SNP enclave,
         not tampered with. Here are your secrets."
STEP 8: CDH receives secrets (encryption keys, API keys,
        DB passwords) - ONLY after attestation passes
STEP 9: Your container starts running with the secrets,
        fully encrypted in memory

Attestation: “Prove You’re Really in a TEE”

This is the critical piece. Anyone can claim “I’m running in a secure enclave.” Attestation is cryptographic proof that it’s true.

The enclave software stack is measured, which means that a trusted cryptographic algorithm is used to authenticate its content.

ATTESTATION FLOW
═══════════════════════════════════════════════════

1. CPU generates a hardware-signed attestation report:
   "This TEE is running on genuine AMD SEV-SNP hardware.
    The firmware hash is X. The kernel hash is Y.
    The guest memory encryption key is Z.
    Signed by AMD's root key (burned into silicon)."
2. Attestation Agent sends this to Trustee:
   TEE → Trustee: "Here's my hardware attestation report"
3. Trustee verifies:
   - Is this signed by genuine hardware? ✅
   - Does the firmware hash match expected? ✅
   - Does the software stack match expected? ✅
   - Has anything been tampered with? No ✅
4. Trustee releases secrets:
   Trustee → TEE: "Verified. Here are your secrets:
     - Database encryption key
     - API credentials
     - TLS certificates"
5. Without attestation passing, the TEE gets NOTHING.
   No secrets. No keys. No data.

Inside the TEE, essential guest components are deployed, including the Kata Agent (managing the workload), the Attestation Agent (for verification), and the Confidential Data Hub (CDH) (for key and secret management).

The Trust Model — What’s Trusted and What’s NOT

The fundamental tenet of the CoCo trust model is that the Kubernetes control plane is explicitly untrusted.

WHAT YOU TRUST                    WHAT YOU DON'T TRUST
═══════════════                   ════════════════════

✅ CPU hardware (Intel/AMD)        ❌ Cloud provider employees
✅ Hardware attestation keys       ❌ Host operating system
✅ Your container image            ❌ Hypervisor
✅ Trustee attestation service     ❌ Kubernetes admin
                                   ❌ Other tenants on same hardware
                                   ❌ Anyone with physical access
                                   ❌ Compromised kernel/firmware

This is a radical shift. In normal Kubernetes, you trust the cluster admin, the node OS, and the hypervisor. In CoCo, you trust NONE of them. The only trust is in the CPU silicon and your own code.

Supported Hardware

On bare metal Confidential Containers supports Intel TDX, AMD SEV-SNP, and IBM Secure Execution — all with attestation support.

HARDWARE TEE OPTIONS
═══════════════════════════════════════════════════

AMD SEV-SNP (Secure Encrypted Virtualization - Secure Nested Paging)
  CPU encrypts VM memory with per-VM key
  Hypervisor cannot read guest memory
  Available: AMD EPYC 3rd gen+
  Cloud: Azure, GCP, AWS (coming)
Intel TDX (Trust Domain Extensions)
  CPU creates isolated "Trust Domains"
  Each TD has its own encryption key
  Available: Intel 4th gen Xeon+
  Cloud: Azure, GCP (coming)
IBM Secure Execution
  Hardware isolation for IBM Z / LinuxONE
  Available: IBM z15+
  Cloud: IBM Cloud
NVIDIA Confidential GPUs
  GPU memory encrypted
  Attestation for GPU workloads
  Hopper (H100), Blackwell (B200)
  Critical for: Confidential AI inference

Real Use Cases

1. Confidential AI — Protect Models and Training Data

This is the hottest use case. You have a proprietary AI model worth millions. You need to run inference in the cloud, but you don’t want the cloud provider (or their employees) to be able to extract your model weights.

CONFIDENTIAL AI INFERENCE
═══════════════════════════════════════════════════

Without CoCo:
  Your 70B model weights sit in GPU memory → plaintext
  Cloud provider admin could theoretically dump them
  Competitor could steal your fine-tuned model
With CoCo:
  Model weights encrypted in memory (CPU + GPU TEE)
  vLLM runs inside a confidential VM
  Model loaded only after hardware attestation passes
  Even the cloud provider can't read the weights
  ┌─────────────────────────────────┐
  │  Confidential TEE               │
  │  ┌───────────┐  ┌─────────── ┐  │
  │  │  vLLM     │  │  NVIDIA    │  │
  │  │  engine   │  │  H100 GPU  │  │
  │  │           │──│  (TEE mode)│  │
  │  │  Model    │  │  Encrypted │  │
  │  │  weights  │  │  GPU mem   │  │
  │  └───────────┘  └─────────── ┘  │
  └─────────────────────────────────┘
  ↑ Memory encrypted. Nobody outside can read it.

2. Multi-Party Computation — Competitors Sharing Data

Two hospitals want to train a model on combined patient data without sharing the raw data with each other. Neither trusts the other. Neither trusts the cloud.

Hospital A data ──┐
                  ├──▶ Confidential Container (TEE)
Hospital B data ──┘     │
                        │ Processes combined data
                        │ inside hardware enclave
                        │ Neither party can see
                        │ the other's raw data
                        ↓
                    Combined model output
                    (shared with both parties)

Both parties attest the TEE before sending data. The hardware guarantees neither party (nor the cloud) can access the other’s raw data.

3. Regulated Industries — Healthcare, Finance, Government

HIPAA, GDPR, PCI-DSS, FedRAMP — all have requirements around data protection. Confidential Containers provide hardware-level guarantees that data is encrypted even during processing.

Without CoCo:
  "We encrypt data at rest and in transit.
   In memory, you have to trust us."
  → Auditor: "That's not sufficient for FedRAMP High."

With CoCo:
  "Data is encrypted at rest, in transit, AND in use.
   Hardware attestation proves it."
  → Auditor: "That satisfies the requirement." ✅

4. Secure Cloud Bursting

Your on-prem data center is full. You need to burst to the cloud for peak workloads. But you can’t send sensitive data to the cloud unprotected.

CoCo lets you run the same Kubernetes workloads in the cloud with hardware encryption — your data is protected even on shared cloud infrastructure.

5. Supply Chain Security

Container Launch with Encrypted Image — Launch an encrypted container by proving the workload is running in a TEE in order to retrieve the decryption key. Container Launch with Image Signature Verification — Launch a container and verify the authenticity and integrity of an image by proving the workload is running in a TEE.

Container images can be encrypted. The decryption key is only released after the TEE passes attestation. An attacker who steals the image from the registry gets an encrypted blob they can’t run.

CoCo Features — The Full List

FEATURE                         WHAT IT DOES
═══════════════════════════════════════════════════

Memory Encryption               CPU encrypts all RAM for the pod.
                                Nobody outside the TEE can read it.
Encrypted Images                Container images are encrypted at rest.
                                Decrypted only inside the TEE after
                                attestation.
Signed Images                   Images are verified via Sigstore-style
                                signatures inside the TEE.
Sealed Secrets                  Kubernetes secrets are encrypted.
                                Only decryptable inside a verified TEE.
Hardware Attestation            Cryptographic proof that the workload
                                runs on genuine TEE hardware.
Trustee (KBS)                   Key Broker Service that releases
                                secrets only after attestation.
Confidential EmptyDir           Temporary storage inside the TEE,
                                encrypted and isolated.
Protected Storage               Persistent volumes encrypted
                                within the TEE boundary.
NVIDIA GPU Attestation          GPU memory encryption + attestation
                                for AI/ML workloads.

Pros

Data encrypted in use. The missing piece of the encryption triangle. At rest ✅, in transit ✅, in use ✅. Hardware-enforced, not software-based.

Zero trust on infrastructure. The fundamental tenet of the CoCo trust model is that the Kubernetes control plane is explicitly untrusted. You don’t trust the cloud provider, the OS, the hypervisor, or the Kubernetes admin. Only the CPU hardware.

Minimal code changes. The only change needed is specifying the appropriate runtimeClassName in the deployment or pod definition. Add one line to your pod spec. Your application doesn’t need to be rewritten.

Cryptographic attestation. Hardware-signed proof that your workload is running in a genuine TEE. Not a promise — a mathematical proof verified by silicon.

NVIDIA GPU support. Confidential GPUs (H100, Blackwell) extend memory encryption to GPU workloads. Critical for AI model protection.

CNCF project. Open-source, community-driven, cloud-agnostic. Works on bare metal, AWS, Azure, GCP, and IBM Cloud.

Supply chain protection. Encrypted and signed container images that can only be decrypted inside a verified TEE. Stolen images are useless.

Cons

Performance overhead. Memory encryption/decryption by the CPU adds latency. Operational overhead exists with 0–5% overhead on SEV and 0–20% on TDX depending on workload. Memory-intensive workloads feel it more.

Hardware dependency. You need specific CPUs (AMD EPYC 3rd gen+, Intel Xeon 4th gen+, IBM z15+). Not every cloud instance type supports it. Not every on-prem server has the right hardware.

Debugging is hard. By design, you can’t “exec into” a confidential pod from the host. The whole point is that the host can’t see inside. This makes troubleshooting significantly harder. You need to design observability into the workload itself.

Cloud support is uneven. Azure’s Confidential Containers preview is set to sunset in March 2026 (though they offer alternatives). AWS support is still under development. GCP supports SNP. The landscape is fragmented.

Larger trusted computing base (TCB) than enclaves. CoCo puts an entire VM + container runtime inside the TEE. Process-level enclaves (Intel SGX) have a smaller TCB but are harder to use. CoCo trades minimal TCB for usability.

Attestation complexity. Setting up Trustee, configuring attestation policies, managing reference values — this is non-trivial infrastructure. Platform teams need to understand the attestation flow to operate it correctly.

Not a silver bullet. If your application has a bug that leaks data through its API, CoCo doesn’t help. It protects the memory, not the application logic. Side-channel attacks against TEEs have been demonstrated (though hardware vendors patch them).

When to Use vs. Not Use

USE CoCo WHEN:                         DON'T NEED CoCo WHEN:

Processing regulated data (HIPAA,      Internal data with trusted infra
PCI-DSS, FedRAMP) in the cloud

Running proprietary AI models you      Using public open-source models
can't let the cloud provider see

Multi-party computation where          Single-party workloads where
nobody trusts each other               you trust your own cloud account

Government/defense workloads           Typical web applications
with strict compliance                 

Cloud bursting sensitive               All workloads stay on trusted
on-prem workloads                      on-prem hardware

Protecting trade secrets during        Non-sensitive data processing
computation

How CoCo Connects to Your Stack

YOUR STACK + CONFIDENTIAL CONTAINERS
═══════════════════════════════════════════════════

vLLM + GPU TEE
  → Run LLM inference with encrypted model weights
  → NVIDIA H100/B200 in confidential mode
  → Model weights never visible to cloud provider
Sigstore
  → Sign container images before deploying to CoCo
  → TEE verifies signatures via attestation
  → Encrypted images decrypted only inside TEE
Kubernetes + KServe
  → LLMInferenceService with runtimeClassName: kata-cc
  → Confidential AI serving at scale
Dagger CI/CD
  → Build encrypted container images in pipeline
  → Sign with cosign
  → Deploy to CoCo-enabled cluster
CloudNativePG
  → Database inside a TEE
  → Queries processed on encrypted memory
  → Even cloud DBA can't see the data

Getting Started

# 1. Install the CoCo operator on your cluster
kubectl apply -f https://raw.githubusercontent.com/confidential-containers/operator/main/deploy/deploy.yaml

# 2. Create a CoCo runtime class
kubectl apply -f cc-runtime.yaml
# 3. Deploy a confidential pod (one line change)
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: my-confidential-app
spec:
  runtimeClassName: kata-cc
  containers:
    - name: app
      image: ghcr.io/myorg/sensitive-app:v1
EOF
# Your pod is now running inside a hardware-encrypted TEE.

The Bottom Line

Confidential Containers solves the last unsolved encryption problem: data in use. We’ve had encryption at rest for decades. Encryption in transit for decades. But data being processed by a CPU has been plaintext in memory — readable by anyone with hypervisor access, physical access, or a compromised kernel.

CoCo changes the trust model from “trust the cloud provider, trust the OS, trust the admin” to “trust the CPU silicon and your own code.” For workloads where that matters — AI model protection, regulated data, multi-party computation, government systems — it’s transformative.

And it’s one line in your pod spec.

Confidential Containers is a CNCF Sandbox project. Supported hardware: Intel TDX, AMD SEV-SNP, IBM Secure Execution, NVIDIA Confidential GPUs. Learn more at confidentialcontainers.org.

Tags: Confidential Computing · Kubernetes · Security · Cloud Native · AI