Encryption

StorageOS supports encryption for data-at-rest and data-in-transit.

Data-in-transit is data as it is travelling between nodes. It is encrypted by default with mTLS. Data-at-rest is the data stored in your volumes as blob files. Encryption of these blob files is optional and can be enabled by adding a label to your volume definitions before they’re provisioned.

For information on how to enable encryption on your volumes, please see our Encryption Operations page.

How volumes are encrypted

Volumes are encrypted using AES-256 in the XTS-AES mode with 512-bit keys, as specified by IEEE Standard 1619-2007. There is a non-zero performance impact of using encrypted volumes. A 10-25% cost in read/write throughput can be expected from XTS-AES, dependent on workload. Thin provisioning still applies to encrypted volumes.

Encryption Key Generation

On PVC creation, if encryption is enabled, StorageOS will automatically generate up to two keys as Kubernetes secrets. Both keys are stored in the same namespace as the PVC.

Firstly, if it doesn’t already exist, a namespace key is generated. It is always named storageos-namespace-key and only one exists per namespace.

Secondly a volume key is created for each encrypted volume. It has a name in the format storageos-volume-key-<random-id>, with no connection to the name of the volume. The volume it is associated with can be determined by looking at the storageos.com/pvc label on the secret. The storageos.com/encryption-secret-name and storageos.com/encryption-secret-namespace annotations are added to the PVC by an admission controller to map the PVC back to its secret.

The encryption key is passed to StorageOS as part of the CSI volume creation request and is used to encrypt the volume.

Encryption Key Use

The volume specific secret is needed whenever a volume is attached to a node for use by a pod. When this happens, the StorageOS node container’s Service Account reads the secret and passes it to the StorageOS controlplane.

A volume missing its key or with a malformed key will be unable to attach.

The key is stored in memory by StorageOS only on the node that the volume is being used on. As a result, encryption and decryption are performed where the data is consumed, rather than where it is stored.

Because of this, the use of encrypted volumes is transparent to the user. There is a complete integration between Kubernetes applications and StorageOS encryption.

Key Management Best Practices

StorageOS does not store encryption keys outside of Kubernetes secrets. Backups are therefore imperative in case the Kubernetes etcd is lost. StorageOS has no ability to decrypt a volume whose encryption keys have been lost.

Secrets in Kubernetes are not encrypted by default, they are stored in the Kubernetes etcd in simple Base64 encoding. As StorageOS encryption keys are stored as Kubernetes Secrets, this means that anyone with access to a Kubernetes etcd installation can read encryption keys and decrypt encrypted volumes, unless the cluster has an external secrets store.

For better security secret encryption or an access control system such as Vault should be in operation on production-grade or sensitive clusters.

Secrets are not garbage-collected by StorageOS. To clean up completely upon deletion of a volume it is necessary to also delete that volume’s secret. There is no benefit to doing this, however.