XSDS security encompasses encryption at rest for stored data, cluster authentication
between all services using cephx, network isolation to separate replication traffic
from client-facing traffic, and regular key rotation procedures.
Administrator Access Required — This operation requires the admin role. Contact your
Xloud administrator if you do not have sufficient permissions.
Prerequisites
Administrator credentials with the admin role
Access to XDeploy (https://connect.<your-domain>) for OSD deployment settings
SSH access to cluster management node for cephx key operations
XSDS supports OSD-level encryption at rest using dm-crypt. All data written to an
encrypted OSD is encrypted before it reaches the physical disk.
Enable Encryption
Key Management
Encryption is configured at OSD deployment time through XDeploy.
Configure encryption before deployment
Navigate to XDeploy → Storage → OSD Deployment and enable
Encrypt OSDs at deployment before provisioning new OSDs.Encryption keys are managed by the Xloud Key Management service and rotated
on a configurable schedule.
Verify encryption on deployed OSDs
Check if OSD device is encrypted
ceph osd metadata <OSD_ID> | grep dmcrypt
Encrypted OSDs report "dmcrypt": true in their metadata.
OSD metadata confirms dm-crypt encryption is active.
Encryption cannot be enabled on existing OSDs without redeploying them. Plan
encryption requirements before initial OSD deployment. In-place encryption of
existing OSDs requires data migration to new encrypted OSDs.
Encryption keys for XSDS OSDs are managed by the Xloud Key Management (XKM) service.
Keys are generated per-OSD at deployment time
Keys are stored in the XKM service, not on the OSD nodes themselves
Key rotation schedules are configurable in XDeploy → Security → Key Rotation
Each OSD retrieves its key at startup via the XKM API
If an OSD node is compromised, the attacker cannot decrypt disk contents without
access to the corresponding key in XKM. The physical disks are unreadable outside
the cluster.
All cluster communication uses cephx, the XSDS cluster authentication framework.
Each service has its own key with minimum required capabilities.
View and Inspect Keys
Key Rotation
Least Privilege Caps
List all cephx keys
ceph auth ls
View capabilities for a specific key
ceph auth get client.<NAME>
Standard key names:
client.admin — full administrative access
client.cinder — used by the block storage service
client.glance — used by the image service
client.nova — used by the compute service
client.rgw.<id> — used by object storage gateways
Rotate cephx keys periodically or immediately after a suspected compromise:
Rotate a cephx key
ceph auth rotate client.<NAME>
Rotating a cephx key does not require redistributing the key file — updated
capabilities take effect immediately in the MON database. The key itself (secret)
remains the same after rotation unless you generate a new key entirely.
