How Confidential Containers Protect Your Kubernetes Workloads (Even From Your Cloud Provider) — Thunder with Tobin Feldman-Fitzthum

how-confidential-containers-protect-your-kubernetes-workload.md

How Confidential Containers Protect Your Kubernetes Workloads (Even From Your Cloud Provider)

Associated Thunder episode: How Confidential Containers Protect Your Kubernetes Workloads (Even From Your Cloud Provider)

---

Before Confidential Containers (CoCo)

• Confidential Computing (CC) was very new
• Confidential Computing (CC) was hard to integrate in any environment

Confidential Containers (CoCo) solves the problem of integrating Confidential Computing (CC) into Kubernetes (K8s) = standardization for adding Confidential Computing (CC) at the Pod level ←don't trust the Kubernetes (K8s) control plane Confidential Computing (CC) is a new technology that has big momentum

• paradigm shift
• needs different hardware

Kata Containers (KATA) encapsulates Virtual Machines (VMs) in containers

---

Confidential Computing (CC) protects data while it is in use

• data at rest is protected
• data in motion is protected
• data in use is vulnerable
  • it can be seen by the physical machine owner, for example

WHOMEVER OWNS THE KERNEL SEES ALL

---

What is Confidential Computing (CC)?

• has a different trust model
• it is hardware
• In practice, usually implemented as Virtual Machines (VMs) w extra layers of security - cannot be breached by host

---

The experience of using Confidential Containers (CoCos)

ASSUMPTION: NEED THE RIGHT HARDWARE

• Run Kubernetes (K8s) operator to install Confidential Containers (CoCo) (easy to use!)
• add a runtime class to your workload

---

The Confidential Computing (CC) Trust Model

DONT TRUST THE HOST

• defined by what goes inside vs outside the enclave } ISOLATION

• Confidential Containers (CoCo) puts each pod in its own Virtual Machine (VM) (Kubernetes (K8s) control plane is not in there)

  • uses a project called Kata Containers (KATA)

• The owner of the Virtual Machine (VM) should know what is running } ATTESTATION everything about the Virtual Machine (VM) itself

---

ISOLATION

The secure place can be called:

• guest
• enclave
• realm
• Trusted Execution Environment (TEE)

Attestation supplies evidence that the secure place is secure

• For example, secrets are only supplied to guest after guest is attested
• Key Broker Service (KBS) in a trusted place

flowchart TB
    KBS["Key Broker Service (KBS)\n(in a trusted place)"]

    subgraph VM["Virtual Machine (VM)"]
        IR["image-rs"]
        CDH["Confidential Data Hub (CDH)"]
        AA["Attestation Agent (AA)"]
        KA["Kata Agent (KATA Agent)"]
        WP["Workload Pod"]
    end

    subgraph K8S["Kubernetes (K8s)"]
        KS["Kata Shim (KATA Shim)"]
        KL["kubelet"]
    end

    HW["Confidential Computing (CC)-Enabled Hardware"]

    KBS -.-> VM
    VM --- K8S
    K8S --- HW

Loading

3 things:

1. put 1 pod in Virtual Machine (VM)
2. pull image inside Virtual Machine (VM)
3. decrypt image/get secrets

---

Components of Confidential Containers (CoCo)

Virtual Machine(s) (VM)

• Kata Shim (KATA Shim) on the host

  • receives container requests
  • makes a Virtual Machine (VM)
  • forwards container request into Virtual Machine (VM)

• Kata Agent (KATA Agent) in Virtual Machine (VM)

  • receives container requests
  • does whatever ex Create, Read, Update, Delete (CRUD)

• one pod in the Virtual Machine (VM)

• Confidential Containers (CoCo) snapshotter talks to image-rs on the host

• image-rs downloads the image inside Virtual Machine (VM)

• Key Broker Service (KBS) = runs in another location - receives evidence from Confidential Data Hub (CDH)/Attestation Agent (AA), verifies it, releases keys to unpack image or whatever secrets

• Confidential Data Hub (CDH) & Attestation Agent (AA) run on Virtual Machine (VM)

  • work together to get hardware evidence from the guest, then
  • sets up a secure connection w Key Broker Service (KBS)
  • makes the attestation

---