Parent folderOpen Confluence

RWS Architecture article

ADR-014 Encryption at Rest Strategy

Encryption-at-rest is required for some workloads, but applying it universally can add performance overhead. We need a control model that is technically correct for ODF/Ceph and au

  1. Typeadr
  2. Statusaccepted
  3. Domainstorage
On this page
  1. Context and Problem Statement
  2. Decision Drivers
  3. Considered Options
  4. Decision Outcome
  5. Pros and Cons of the Options
  6. Option 1 – Workload-level encryption
  7. Option 2 – Cluster-wide ODF encryption baseline
  8. Option 3 – Policy-driven ODF controls (chosen)
  9. Links and References

Context and Problem Statement

Encryption-at-rest is required for some workloads, but applying it universally can add performance overhead. We need a control model that is technically correct for ODF/Ceph and auditable per workload path, instead of relying on imprecise "encrypted pool" terminology.

Decision Drivers

  • Regulatory requirements for specific workloads.
  • Performance impact of storage-backend encryption controls.
  • Ability to scope controls by workload path (for example block/RBD versus file/RWX).
  • Clarity of ODF external-mode implementation scope and mechanism per workload class.

Considered Options

  1. Workload-level encryption (per volume or OS layer).
  2. Cluster-wide ODF encryption baseline for all supported workloads.
  3. Policy-driven ODF controls: cluster-wide encryption and/or encrypted StorageClass/PV controls by workload class.

Decision Outcome

Chosen option: Policy-driven ODF controls: cluster-wide encryption and/or encrypted StorageClass/PV controls by workload class.

Implementation baseline:

  • Regulated and sensitive workload classes must use encrypted-at-rest storage paths implemented through ODF cluster-wide encryption and/or encrypted StorageClass/PV controls.
  • StorageClass/PV encryption controls are validated per workload path and are treated as RBD/block PV scoped controls; file/RWX paths require cluster-wide encryption and/or additional workload controls.
  • Control mappings must be explicit and auditable as workload class -> StorageClass -> backing Ceph pool -> encryption mechanism.
  • Workloads that cannot meet requirements through platform controls must use workload-level encryption as an exception path with documented justification.
  • Non-regulated workload classes may use non-encrypted storage paths only when explicitly approved by data-classification policy.
  • Audit evidence for regulated services must prove effective encryption, including PVC-to-StorageClass binding, active encryption configuration state, and workload-path coverage (block versus file).

Pros and Cons of the Options

Option 1 – Workload-level encryption

Pros

  • Fine-grained control per workload.

Cons

  • Inconsistent implementation and operational overhead.

Option 2 – Cluster-wide ODF encryption baseline

Pros

  • Uniform compliance baseline across workloads.

Cons

  • Higher performance overhead and lower flexibility for mixed workload classes.

Option 3 – Policy-driven ODF controls (chosen)

Pros

  • Aligns encryption controls to workload class while staying aligned with ODF-supported mechanisms.

Cons

  • Requires stricter evidence and governance to prove control effectiveness per workload path.

Links and References