Aperta Scientia Crest
← Back to Tech Radar
📡 Aperta Intelligence Lab
OpenShift Data Foundation: Rook-Ceph, CSI and Per-Tenant Encryption

OpenShift Data Foundation: Rook-Ceph, CSI and Per-Tenant Encryption

📅 October 8, 2026
Tech Radar Storage OpenShift

Briefing Summary

On a Kubernetes platform you size the CPU, cap the memory, watch network latency — and then you discover the real problems the day a PersistentVolumeClaim stays Pending. Storage is the most underestimated layer of Platform Engineering: it decides resilience, portability and, increasingly, compliance. On OpenShift that layer has a name: OpenShift Data Foundation (ODF) — the operator that turns raw disks into a Ceph cluster consumable through the Kubernetes API.

1. ODF: a Ceph cluster governed by an operator

ODF does not invent storage: it industrialises Rook, the operator that deploys and reconciles Ceph on Kubernetes (see the Rook Ceph documentation). Three daemon families form the core:

  • MON (Monitor) — holds the cluster map (topology, OSD state, placement groups); the MON quorum is the cluster’s single point of decision.
  • MGR (Manager) — exposes metrics, the dashboard and administration modules.
  • OSD (Object Storage Daemon) — one process per disk: it stores the actual data, replicates and repairs.

Where a classic SAN demands a dedicated storage administrator, ODF exposes Kubernetes CRDs: you declare a StorageCluster, Rook converges the real state. It is the same declarative contract as the rest of the platform — and therefore the same GitOps pipeline.

2. One cluster, three consumption interfaces

Ceph storage is exposed to the cluster through CSI drivers that dynamically provision volumes:

  • ocs-storagecluster-ceph-rbd — RBD block volumes (RADOS Block Device), RWO (ReadWriteOnce) access. The default choice for databases, application state and StatefulSets.
  • ocs-storagecluster-cephfs — CephFS, a shared filesystem with RWX (ReadWriteMany) access. Essential for volumes shared by several Pods (build artefacts, models, pipelines).
  • S3 / Object Storage via NooBaa (Multicloud Object Gateway) — an S3-compatible API for backups, data lakes and training backends.

From the platform’s point of view these are standard StorageClasses: a PVC plus a class name, and CSI provisions the volume. That abstraction is what makes storage portable — and testable in CI like any other manifest.

3. Encryption: two granularities, one key decision

This is where ODF outgrows the black-box SAN. Ceph encryption relies on a two-key envelope: each volume has a DEK (Data Encryption Key) that encrypts the data, itself encrypted by a KEK (Key Encryption Key) held by an external KMS. ODF integrates with HashiCorp Vault as that KMS.

Two levels coexist:

  • Cluster-wide encryption — all data at rest is encrypted, under a single policy. This is the baseline, described step by step in the Red Hat Developer Blog article OpenShift Data Foundation and HashiCorp Vault securing data.
  • Per-PV (StorageClass) encryption — often insufficient in multi-tenant environments: compliance may require a distinct key per project, tenant or sensitivity level.

4. The multi-tenant case: isolating encryption boundaries per namespace

The Red Hat Developer Blog article Enhance data security in OpenShift Data Foundation (15 July 2025) walks through exactly that scenario. By enabling StorageClass encryption in the ODF installation wizard, the cluster gains an additional encrypted StorageClass:

$ oc get sc
NAME                                              PROVISIONER                        RECLAIMPOLICY
ocs-storagecluster-ceph-rbd                       openshift-storage.rbd.csi.ceph.com Delete
ocs-storagecluster-ceph-rbd-encrypted (default)   openshift-storage.rbd.csi.ceph.com Delete
ocs-storagecluster-cephfs                         openshift-storage.cephfs.csi.ceph.com Delete

Isolation is built in four moves, each mapped to a Kubernetes primitive:

  1. A Vault role and ACL per tenant — each namespace gets its own path (kv/tenant-a/), hence its own cryptographic boundary.
  2. A ConfigMap inside the namespace — overrides the CSI configuration to point the volume at the right Vault path.
  3. A dedicated ServiceAccount, bound to the Vault role through Kubernetes Auth (bound_service_account_namespaces).
  4. PVCs in the namespace consuming the encrypted StorageClass — each volume is sealed by the tenant’s KEK.

An engineering point that is often missed: Kubernetes discourages long-lived ServiceAccount tokens (since v1.22). The right reflex is a short TTL in the Vault policy, with automatic rotation through the TokenRequest API. The secret no longer lives forever in a Secret; it lives in time.

5. Why this is foundational for AI platforms (AS300)

Storage is not a peripheral DevOps topic: it is the substrate of enterprise AI.

  • Distributed training — datasets must be mounted RWX by several workers; CephFS becomes the meeting point for jobs.
  • RAG and vector databases — a backend such as Milvus relies on RBD block volumes for its persistent indexes, with CSI snapshots.
  • Model store & registry — model artefacts and checkpoints are stateful volumes: CSI snapshots and clones let you version a state without a full copy.
  • Sovereignty — encryption at rest with keys you control (Vault KMS) and internal S3 (NooBaa): training data never leaves the perimeter.

6. Technical Sources & References

Apply these technologies in production

Explore our intensive 3-month AS200 (DevOps) and AS300 (AI Platform Engineer) curriculums.

View Curriculums →