Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.xloud.tech/llms.txt

Use this file to discover all available pages before exploring further.

​
Overview

Xloud protects data at every stage: in transit between services, at rest on storage backends, and during backup operations. Volume encryption uses LUKS with keys managed exclusively by Xloud Key Management (Barbican). Object storage supports server-side encryption. This page covers configuration for all data protection mechanisms available in the platform.
Prerequisites
  • Administrator role in Xloud Identity
  • Xloud Key Management enabled (enable_barbican: "yes" in XDeploy configuration)
  • For encrypted volumes: an encrypted volume type configured in Block Storage
  • For object storage encryption: access to the object storage admin API

​
Data Protection Architecture

LayerMechanismKey Storage
Block volume (LUKS)AES-256-XTSXloud Key Management
Ceph OSD at restAES-256-GCMCeph key management daemon
Object storage SSEAES-256-CBCPer-object or per-bucket keys
DatabaseMariaDB TDE or encrypted tablespaceExternal KMS
BackupInherited from volume encryptionSame key as source volume

​
Volume Encryption (LUKS)

GA LUKS encryption wraps every I/O operation at the compute host before data reaches the storage network. The compute host fetches the encryption key from Xloud Key Management at volume attachment time and never writes it to disk.

​
Create an Encrypted Volume Type

Open Volume Types

Navigate to Admin → Volume → Volume Types and click Create Volume Type.

Define encryption parameters

After creating the type, select View Encryption and click Create Encryption:
FieldValueNotes
Provider Classnova.volume.encryptors.luks.LuksEncryptorLUKS v2 encryptor
Control Locationfront-endEncryption at the compute host
Cipheraes-xts-plain64AES-256 in XTS mode
Key Size256256-bit AES key
The volume type now shows Encrypted: Yes in the type list.

Create an encrypted volume

Navigate to Project → Volumes → Create Volume and select the encrypted type. The platform generates a unique encryption key in Xloud Key Management and associates it with the volume.
Once a volume is created with encryption enabled, the encryption cannot be removed without creating a new unencrypted volume and migrating the data. Plan your volume type strategy before provisioning production volumes.

​
Key Management Integration (Barbican)

Xloud Key Management stores, rotates, and controls access to all encryption keys. Each encrypted volume has a unique key. Key access is audited and can be restricted by ACL.

​
Key Operations

List secrets managed by Key Management
openstack secret list --limit 10
Retrieve key metadata (not the key material)
openstack secret get <secret-href>
Create a named secret for application use
openstack secret store \
  --name "app-encryption-key" \
  --secret-type "symmetric" \
  --payload-content-type "application/octet-stream" \
  --payload "$(openssl rand -base64 32)"
Set an ACL on a secret
openstack acl user add \
  --user <user-id> \
  --project <project-id> \
  <secret-href>

​
Key Rotation

Rotate an encryption key (create new, re-encrypt)
# Step 1: Create a new key
NEW_KEY=$(openstack secret store \
  --name "rotated-key-$(date +%Y%m)" \
  --secret-type symmetric \
  --payload "$(openssl rand -base64 32)" \
  -c "Secret href" -f value)

# Step 2: Migrate volume to new key (requires volume to be detached)
openstack volume migrate <volume-id> --host <new-host-with-new-key>
Key rotation requires migrating the volume. Schedule rotations during maintenance windows. Xloud Key Management retains old keys until explicitly deleted to support rollback scenarios.

​
Object Storage Encryption

Object storage encryption protects data at rest in the object store. Two modes are supported:
ModeDescriptionKey Location
SSE-CCustomer-provided key sent per requestClient-managed
SSE-KMSKeys managed by Xloud Key ManagementPlatform-managed
Upload object with SSE-C encryption
# Generate a 256-bit key
KEY=$(openssl rand -base64 32)

openstack object create my-container my-file.dat \
  --object-name encrypted-file.dat \
  -H "X-Object-Sysmeta-Crypto-Key: $KEY" \
  -H "X-Object-Sysmeta-Crypto-Etag: yes"
With SSE-C, the client is responsible for storing and supplying the encryption key on every request. If the key is lost, the object is permanently unreadable. Use SSE-KMS for platform-managed key storage and rotation.

​
Encrypted Backups

Volume backups inherit the encryption state of their source volume. Backups of encrypted volumes are stored encrypted in the backup repository.
Create encrypted backup
openstack volume backup create \
  --name db-vol-backup-$(date +%Y%m%d) \
  --force \
  db-vol-01
Verify backup encryption
openstack volume backup show db-vol-backup-20251201 \
  --column "availability_zone" \
  --column "volume_id" \
  --column "status" \
  --format table
Backup keys are tied to the same Xloud Key Management secret as the source volume. If the source volume’s encryption key is deleted, the backup becomes permanently unreadable. Do not delete keys for volumes that have active backups.

​
Data-at-Rest Encryption for Databases

Platform databases (MariaDB) use encrypted tablespaces for sensitive configuration and credential storage. XDeploy configures this during deployment, so you do not need manual intervention.
Enable database encryption (XDeploy configuration)
mariadb_enable_encryption: "yes"
mariadb_encryption_key_management: "file"
For production deployments, use an external key management server:
External KMS for database encryption
mariadb_encryption_key_management: "hashicorp_vault"
mariadb_encryption_vault_addr: "https://vault.internal:8200"
mariadb_encryption_vault_token: "{{ vault_token }}"

​
Secure Deletion and Data Scrubbing

When a volume is deleted, the underlying storage blocks are marked for reclamation. For regulatory compliance requiring secure deletion:
Zero-fill a volume before deletion
# Attach volume to a temporary instance and zero it
# Inside the instance:
sudo dd if=/dev/zero of=/dev/vdb bs=4M status=progress
sudo sync

# Then detach and delete the volume
openstack volume detach <instance-id> <volume-id>
openstack volume delete <volume-id>
For Ceph-backed storage, the storage layer performs data scrubbing through Ceph’s object deletion and placement group (PG) scrub process. Immediately after deletion, the data may remain on OSDs until the next scrub cycle. For environments requiring immediate data erasure, use LUKS encryption. Deleting the key renders the data unreadable without waiting for the scrub cycle.

​
Next Steps

Key Manager Service

Detailed guide for storing and managing secrets in Xloud Key Management

Volume Encryption (Admin)

Administrative guide for volume encryption and volume type management

VM Security

vTPM, Secure Boot, and hypervisor-level protection for virtual machines

Compliance

Audit logging and compliance framework requirements for encrypted data