Volumes

Edit online

Configuration and usage of encrypted persistent block volumes for Bare Metal CCCO workloads.

Important: The volumes feature is only applicable for Bare Metal IBM Confidential Computing Containers for Red Hat OpenShift Container Platform (CCCO) deployments.

The volumes section in the contract manages persistent block volumes for CCCO workloads. CCCO encrypts all attached block volumes to protect data from external access, including OpenShift Container Platform administrators, system administrators, and other data owners. Workload processes run in a Trusted Execution Environment, enabling you to run stateful applications with persistent block storage support.

Overview

To use volumes with CCCO workloads, you must define volume parameters in both the workload and env sections of the contract. CCCO merges these parameters for each persistent block volume, using the provided seeds to encrypt the volume and create the specified mount point to the workload.

Each volume requires a unique label that matches the block device in the pod specification. This label enables CCCO to identify and encrypt the respective persistent block device.

Prerequisites

Before you configure volumes in CCCO:

  1. Attach physical block devices (such as IBM DASD and IBM Z FCP) to your OpenShift Container Platform bare metal nodes.
  2. Install a storage operator to manage persistent block volumes (for example, Red Hat OpenShift Data Foundation (ODF) or Fusion Data Foundation(FDF)).
    Note: Make that you have enabled the Transport Layer Security (TLS) for ODF or FDF.
  3. Set up volumes for contracts. For more information, see Setting up volumes for contracts.
Important: To set up ODF or FDF, follow the setup guide in the Red Hat OpenShift Data Foundation documentation or IBM Storage Fusion Data Foundation. You must complete the operator setup before you can create persistent volume claims for CCCO workloads.

Configuration example

The following example shows a single volume configuration across the workload section, env section, and pod specification.

Workload section:
workload:
  volumes:
    test:
      filesystem: "ext4"
      mount: "/mnt/data"
      seed: "workloadphrase1"
Env section:
env:
  volumes:
    test:
      seed: "envphrase123457"
Pod specification:
apiVersion: v1
kind: Pod
metadata:
  name: busybox-block-storage-pod
  namespace: default
spec:
  containers:
  - name: busybox
    image: busybox:latest
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo 'Block device available'; sleep 30; done"]
    volumeDevices:
    - name: odf-block-volume
      devicePath: /dev/test
  volumes:
  - name: odf-block-volume
    persistentVolumeClaim:
      claimName: odf-internal-rbd-pvc-1

In this example, the block device name for the container, test, specified in the devicePath field of the volumeDevices section, matches the test label defined in both the workload and env volumes sections. CCCO uses both seeds to encrypt the volume and creates the mount point at /mnt/data with an ext4 filesystem. The encrypted storage persists across pod restarts when you use the same contract.