keys hanging on wall

Feature Focus: StorageOS Encrypted Volumes

The integrity and security of your proprietary data or your customers’ data is of utmost importance to your business. StorageOS v1.2.0 includes encryption of data at rest, using keys that only you hold access to.

The benefit of encrypting data at rest, with keys only you have access to, is the certainty that only you have access to your data. With StorageOS encryption you alone have access to the encryption keys. This is an important distinction between encryption of StorageOS volumes and encryption of devices offered by cloud providers.

StorageOS encrypts data at rest using AES-256 in XTS-AES mode with 512 bit keys as recommended by NIST. Usage of XTS-AES encryption enables the use of the AES-NI instruction set when avaliable. The AES-NI instruction set minimizes the CPU overhead and latency of encrypting volumes. The keys and initialization vectors used to encrypt volumes are generated using the crypto/rand package. Each volume is encrypted with a unique 512bit key. Rather than storing this key, StorageOS encrypts each volume key with a namespace specific 256bit key and a unique 256bit salt. The encrypted volume key is then stored in a Kubernetes secret in your cluster. StorageOS has no access to, nor means to recover these keys allowing you to make iron clad guarantees about who has access to your encryption keys. This also means that data can effectively be destroyed by deleting the volumes encryption keys.

As a further measure to keep the encryption keys secure you can encrypt the Kubernetes secrets in your cluster, as by default they are only base64 encoded. By using a KMS or other means of encrypting your Kubernetes secrets you can control who can decrypt the keys required to decrypt your volumes.

Enabling StorageOS Encryption of Volumes

We designed our encryption at rest feature with an emphasis on ease of use. As such, enabling encryption of StorageOS volumes is as simple as setting the label on a volume when it is provisioned. StorageOS will then encrypt the volume and store the encryption key in a Kubernetes secret in the StorageOS installation namespace.

As encryption is enabled by setting a label on a volume, there are a variety of ways to achieve mass encryption of volumes. If you are running Kubernetes 1.13+ we recommended the usage of the StorageOS CSI driver. The CSI driver allows StorageOS labels to be passed as StorageClass parameters. By setting the StorageOS encryption label as a StorageClass parameter all volumes created with that StorageClass would be encrypted by default. An example of such a CSI StorageClass is provided below.
kind: StorageClass
name: storageos-replicated
fsType: ext4
pool: default "1"
provisioner: storageos

Further flexibility is afforded by the StorageOS rules engine. For example, if volumes with the env=prod are to be encrypted, a rule could be created to add the StorageOS encryption labels to all volumes with that label. Finally, the label can also be set on a per volume basis as a PersistentVolumeClaim label for more granular control over volume encryption.

You can try StorageOS for free to see how it delivers you persistent storage for your containerized application.


Author: Alex Vest

Alex Vest is a Product Reliability Engineer at StorageOS.

  • Customer Case Study: StorageOS provides MSP, Civo with Cloud Native StorageRead Now

  • Blog: Using the RabbitMQ Kubernetes Operator with Persistent DataRead Now

  • Performance Benchmarking Cloud Native Storage Solutions for KubernetesDownload Now

  • Webinar: Register for Accelerating Kubernetes Onboarding and Application Transformation on 18th August, 2021 at 4pm (BST)Register Now