[rbd] librbd encryption has no KMS integration, Cinder encryption bypasses librbd — how are others handling this?
Hi all, We're using Ceph RBD as the storage backend for OpenStack Cinder and need encryption at rest with per-volume keys managed by an external key manager (OpenBao/Vault). We've evaluated two approaches: 1. OpenStack Cinder encryption Per-volume keys stored in our key manager. Cinder formats the RBD image with a LUKS header, and QEMU handles decryption. The issue is that Nova doesn't set the libvirt engine to librbd for encryption — it always happens at the QEMU block layer. This means encryption/decryption sits above librbd rather than inside it, adding significant I/O overhead. We're seeing 60-80% IOPS reduction. 2. librbd-native LUKS encryption Encryption inside librbd's I/O dispatch layer. Client-side, per-image keys, data encrypted before it leaves the compute node. This is where encryption should happen for Ceph. But rbd_encryption_load() requires the passphrase directly from the caller — no integration with external key managers (Vault, Barbican, KMIP), making it impractical for orchestrated multi-tenant environments. The gap: - Cinder encryption: per-tenant keys ✓, KMS integration ✓, performance ✗ (stuck at QEMU layer) - librbd-native: performance ✓, per-image keys ✓, KMS integration ✗ We're stuck between key management without good performance and good performance without key management. Is this a known limitation? How are other Ceph + OpenStack deployments handling per-tenant encryption at rest? Happy to contribute if there's a path forward. Thanks, Ravi Sasi Tilak
participants (1)
-
Ravi Sasi Tilak