Encryption
#
OverviewOpenEBS supports data-at-rest encryption to ensure the confidentiality of persistent disk data. By configuring disk pools with user-defined encryption keys, the pools themselves are encrypted, and volume replicas placed on these pools are automatically encrypted. This approach is especially beneficial for meeting security and regulatory compliance requirements.
This guide outlines how to enable encryption in Mayastor DiskPools and use them for volume replica placement.
#
PrerequisitesBefore provisioning encrypted volumes, ensure the following are set up:
#
Create a Kubernetes Secret with AES-XTS KeysEncryption in Mayastor uses the AES-XTS cipher, which requires two 128-bit hex-encoded keys.
Example: Kubernetes Secret
note
You can additionally use Kubernetes built-in resource encryption to secure this Secret resource. Refer to the Encrypting Confidential Data at Rest Documentation for more information.
#
Configure DiskPool to Use the Encryption SecretReference the encryption secret in the DiskPool
resource to enable encrypted storage.
Example: DiskPool Configuration
#
Define StorageClass for Encrypted VolumesTo place volume replicas on encrypted pools, set encrypted: "true"
in the StorageClass
.
Example: StorageClass
#
Migrating from Non-Encrypted to Encrypted PoolsCurrently, there is no automatic support for migrating existing unencrypted volumes. The following manual migration steps are recommended:
Migration Steps
- Identify all the volumes to be converted to encrypted, and change their spec to encrypted via plugin.
- Identify Target Pool: Select a non-encrypted pool (Example: P1) to migrate.
- Identify all volumes with replicas on P1.
- (Optional) Scale Up Volumes: Increase replica count (Example: from 2 to 3) to maintain availability.
- Mayastor Cordon Node: Cordon the mayastor node hosting P1 to stop new replicas from being scheduled using the plugin command
kubectl mayastor cordon node N1 <cordon_label>
. - Scale Down Volumes: Reduce replica count to remove replicas from P1. In effect, this is like draining the pool.
- Recreating as Encrypted Pool:
- Delete the non-encrypted pool.
- Uncordon the node.
- Recreate it with encryption using the previously defined secret.
- Scale-up Volumes: Increase replica count to allow new encrypted replicas to be created on the new pool.
- Optional Replica Adjustment: After migration, optionally reduce replica count back to the original.
note
- Monitor disk space and health throughout the migration to avoid service disruption.
- If there are snapshots on the pool being migrated, then delete the volume snapshot objects before doing migration, otherwise they might just lying around unusably. Since pool is being recreated as part of this procedure, the underlying snapshot blobs are anyway going to be deleted.
- If a snapshot is needed to be kept around, consider creating a restore volume from it, then scale it up to multiple replicas. After this, you can either use restore volume, or take a snapshot again, so it'll be preserved.
#
Validation and Tips- The Kubernetes Secret must be created before applying the DiskPool.
- Key rotation is not supported at this time.
- Persistent device paths are required for pool creation. Retrieve them using:
note
Pool and volume migration is manual and requires careful planning.