Skip to content

Add LUKS encryption support for cloud volumes via CDH - #3155

Open
mohammedadnan21 wants to merge 4 commits into
confidential-containers:mainfrom
mohammedadnan21:add-luks-encryption-support
Open

Add LUKS encryption support for cloud volumes via CDH#3155
mohammedadnan21 wants to merge 4 commits into
confidential-containers:mainfrom
mohammedadnan21:add-luks-encryption-support

Conversation

@mohammedadnan21

@mohammedadnan21 mohammedadnan21 commented Jun 19, 2026

Copy link
Copy Markdown
Contributor

Summary

Adds LUKS2 encryption support for cloud volumes passed through to Peer Pods. When a StorageClass specifies encrypt-type: LUKS and kbs-key-id, the interceptor inside the PodVM calls CDH's secure_mount TTRPC API instead of raw formatAndMount. CDH handles LUKS formatting/opening and fetches the encryption key from KBS after remote attestation.

This builds on the volume passthrough merged in #3037.

Changes

  • pkg/util/cloud.go — Extend CloudVolumeAnnotation with EncryptType and KeyID fields
  • pkg/adaptor/proxy/service.go — Read encrypt-type and kbs-key-id from mountInfo.json metadata and pass in OCI annotation
  • pkg/forwarder/interceptor/cdh_client.go — Lightweight CDH TTRPC client (uses existing containerd/ttrpc dependency)
  • pkg/forwarder/interceptor/interceptor.go — Branch on EncryptType: encrypted volumes go through CDH, plain volumes use existing formatAndMount; isLuks detection for first-mount vs re-mount; LUKS cleanup via cryptsetup luksClose
  • Tests — Unit tests for annotation flow, CDH request construction, and encrypted mount tracking

How it works

StorageClass (encrypt-type, kbs-key-id)
  → CSI Driver writes mountInfo.json with metadata
    → CAA Proxy reads metadata, sets cloud_volumes annotation
      → Interceptor in PodVM receives annotation
        → if encrypt_type set: call CDH secure_mount (LUKS + KBS key)
        → else: formatAndMount (existing path)

CDH determines whether to format a fresh disk or open an existing LUKS container by checking cryptsetup isLuks.

What doesn't change

  • CSI driver NodePublishVolume — encryption params already flow to mountInfo.json
  • Cloud providers (AWS/Azure) — disk attachment is the same
  • PodVM image — CDH and cryptsetup already installed
  • KBS/attestation — existing provisioning handles this

Test plan

  • Unit tests pass for annotation serialization with encryption fields
  • Unit tests pass for CDH request format verification
  • Unit tests pass for encrypted mount cleanup tracking
  • go build ./... passes
  • gofmt clean
  • E2e: create PVC with encrypted StorageClass, verify data persists across pod restarts

Closes: confidential-devhub/caa-csi-block-driver#16

@bpradipt

Copy link
Copy Markdown
Member

@mohammedadnan21 this will need a rebase

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds support for mounting cloud-passthrough volumes using LUKS2 encryption via Confidential Data Hub (CDH) when encryption parameters are provided via mountInfo.json metadata and forwarded through the cloud_volumes OCI annotation. This extends the existing “format-and-mount inside PodVM” flow by introducing a CDH secure_mount path for encrypted volumes, plus cleanup of LUKS mappings on teardown.

Changes:

  • Extend cloud_volumes annotation schema to carry encrypt_type and key_id, and plumb those fields from proxy → interceptor.
  • Add CDH TTRPC client + protobuf types, and route encrypted mounts through secureMount with LUKS detection.
  • Add unit tests covering encryption annotation flow, CDH request/response proto round-trips, and encrypted mount tracking.

Reviewed changes

Copilot reviewed 6 out of 7 changed files in this pull request and generated 2 comments.

Show a summary per file
File Description
src/cloud-api-adaptor/pkg/util/cloud.go Extends cloud volume annotation schema with encryption fields.
src/cloud-api-adaptor/pkg/adaptor/proxy/service.go Reads encryption metadata from mountInfo.json and forwards it in the OCI annotation.
src/cloud-api-adaptor/pkg/adaptor/proxy/cloud_volumes_test.go Adds proxy tests for encryption field propagation into cloud_volumes.
src/cloud-api-adaptor/pkg/forwarder/interceptor/interceptor.go Adds encrypted mount branch via CDH + LUKS cleanup tracking on teardown.
src/cloud-api-adaptor/pkg/forwarder/interceptor/cdh_client.go Introduces a lightweight CDH TTRPC client wrapper.
src/cloud-api-adaptor/pkg/forwarder/interceptor/cdhpb/confidential_data_hub.pb.go Adds generated protobuf message definitions for CDH RPC payloads.
src/cloud-api-adaptor/pkg/forwarder/interceptor/interceptor_test.go Adds tests for annotation parsing, proto round-trips, and encryption param validation.
Files not reviewed (1)
  • src/cloud-api-adaptor/pkg/forwarder/interceptor/cdhpb/confidential_data_hub.pb.go: Generated file

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines 70 to 74
for idx := len(i.cloudMounts) - 1; idx >= 0; idx-- {
cm := i.cloudMounts[idx]
if err := syscall.Unmount(cm.path, 0); err != nil {
logger.Printf("WARNING: failed to unmount cloud volume %s: %v", cm.path, err)
} else {
Comment on lines +24 to +28
func newCDHClient(socketPath string) (*cdhClient, error) {
const maxAttempts = 10
const retryDelay = 2 * time.Second

var conn net.Conn
Run protoc against the existing confidential_data_hub.proto definition
(kata-containers/src/libs/protocols/protos/) to produce Go types that
properly implement proto.Message. These are needed by the ttrpc v1.2.7
codec for wire-compatible serialization of SecureMount RPC calls.

Signed-off-by: Mohammed Adnan <muhammedadnan50007@gmail.com>
Integrate with CDH's secure_mount TTRPC API to support LUKS2 encrypted
block volumes in Peer Pods. When a StorageClass specifies encrypt-type
and kbs-key-id, the interceptor inside the PodVM delegates to CDH which
handles LUKS formatting/opening with keys fetched from KBS after remote
attestation.

Changes:
- Extend CloudVolumeAnnotation with EncryptType and KeyID fields
- Proxy reads encrypt-type/kbs-key-id from mountInfo.json metadata
- Add CDH TTRPC client using generated proto types, with connection
  retry logic (10 attempts) and error logging on close
- Interceptor branches on EncryptType: CDH path vs plain formatAndMount
- Pass predictable mapperName to CDH for reliable cryptsetup cleanup;
  fallback to /proc/mounts lookup if name is unavailable
- Validate encrypt type (only luks/luks2 accepted) before CDH call
- isLuks detection distinguishes fresh disks from existing LUKS volumes
- unmountCloudVolumes handles cryptsetup close for encrypted mounts
- Unit tests for annotation flow, proto round-trip, encrypt type
  validation, CDH request format, encrypted mount tracking

Signed-off-by: Mohammed Adnan <muhammedadnan50007@gmail.com>
Strip AI-style doc comments that restate function names (isLuks,
validateEncryptParams, secureMount, findMapperForMountPoint,
unmountCloudVolumes, newCDHClient) and inline comments that narrate
obvious code.

Upgrade github.com/containerd/containerd v1.7.32 → v1.7.33 to resolve
GO-2026-5758 (CRI image-config LABEL host-root command execution).

Signed-off-by: Mohammed Adnan <muhammedadnan50007@gmail.com>
CDH only accepts encryptionType "luks2"; accept StorageClass
aliases LUKS/luks and always send luks2. Resolve mapper name
before unmount and skip cryptsetup close if unmount fails.
Thread context into CDH dial retries so CreateContainer cancel
is respected.

Signed-off-by: Mohammed Adnan <muhammedadnan50007@gmail.com>
@mohammedadnan21
mohammedadnan21 force-pushed the add-luks-encryption-support branch from a583761 to 9e7500c Compare July 28, 2026 16:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add encryption support

3 participants