Security

Overview

nxtStore 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 NxtSight administrator if you do not have sufficient permissions.

Prerequisites

Administrator credentials with the admin role
Access to nxtDeploy (https://connect.<your-domain>) for OSD deployment settings
SSH access to cluster management node for cephx key operations

Encryption at Rest

nxtStore 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 nxtDeploy.

Configure encryption before deployment

Navigate to nxtDeploy → Storage → OSD Deployment and enable Encrypt OSDs at deployment before provisioning new OSDs.Encryption keys are managed by the NxtSight 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.

Cluster Authentication (cephx)

All cluster communication uses cephx, the nxtStore 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.

To generate a completely new key for a service:

Delete and recreate a key

ceph auth del client.<NAME>
ceph auth get-or-create client.<NAME> \
  mon 'profile rbd' \
  osd 'profile rbd pool=volumes'

After generating a new key, update the corresponding keyring file on all service nodes and restart the affected services.

Grant each client key only the capabilities required for its role:

Service	Recommended Capabilities
Cinder (block storage)	`mon 'profile rbd' osd 'profile rbd pool=volumes'`
Glance (image service)	`mon 'profile rbd' osd 'profile rbd pool=images'`
Nova (compute)	`mon 'profile rbd' osd 'profile rbd pool=volumes, profile rbd pool=vms'`
RGW (object storage)	`mon 'allow rw' osd 'allow rwx'`

Update capabilities for a key

ceph auth caps client.cinder \
  mon 'profile rbd' \
  osd 'profile rbd pool=volumes'

Network Isolation

Configure a dedicated cluster network for OSD replication traffic to isolate storage replication I/O from client-facing traffic.

Network	Purpose	Traffic
Public network	Client-to-OSD I/O, MON communication, RGW API	Read/write requests from Compute nodes
Cluster network	OSD-to-OSD replication, recovery, scrubbing	Internal replication traffic

Recommended Setup
Verify Network Config

Separate physical interfaces or VLANs are recommended for high-throughput production environments:

Public network: 10 GbE or 25 GbE, shared with compute nodes
Cluster network: 25 GbE or faster, storage-only VLAN

Network configuration is set in the cluster configuration and applied by nxtDeploy during initial deployment.

Isolating cluster (replication) traffic prevents recovery operations from impacting client I/O performance. During OSD failures, recovery traffic can easily saturate a shared 10 GbE link.

Show cluster network configuration

ceph config get osd cluster_network
ceph config get osd public_network

Check OSD binding

ceph osd dump | grep "^osd\." | awk '{print $1, $14, $16}'

Next Steps

Encryption at Rest

Block storage volume-level encryption managed through the Key Management service

NxtSight Key Management

Manage and rotate the encryption keys used by nxtStore and other services

Cluster Management

Ongoing operational management for a secured cluster

Troubleshooting

Diagnose authentication and connectivity issues

Core Services

Other Services

Overview

Encryption at Rest

Configure encryption before deployment

Verify encryption on deployed OSDs

Cluster Authentication (cephx)

Network Isolation

Next Steps

Encryption at Rest

NxtSight Key Management

Cluster Management

Troubleshooting

​Overview

​Encryption at Rest

Configure encryption before deployment

Verify encryption on deployed OSDs

​Cluster Authentication (cephx)

​Network Isolation

​Next Steps

Encryption at Rest

NxtSight Key Management

Cluster Management

Troubleshooting

Overview

Encryption at Rest

Cluster Authentication (cephx)

Network Isolation

Next Steps