> ## 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.

# Security

> Secure XSDS deployments with encryption at rest, cluster authentication (cephx), key rotation, and network isolation for production environments.

## Overview

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.

<Warning>
  **Administrator Access Required** — This operation requires the `admin` role. Contact your
  Xloud administrator if you do not have sufficient permissions.
</Warning>

<Note>
  **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
</Note>

***

## Encryption at Rest

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.

<Tabs>
  <Tab title="Enable Encryption" icon="lock">
    Encryption is configured at OSD deployment time through XDeploy.

    <Steps titleSize="h3">
      <Step title="Configure encryption before deployment" icon="settings">
        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.
      </Step>

      <Step title="Verify encryption on deployed OSDs" icon="circle-check">
        ```bash title="Check if OSD device is encrypted" theme={null}
        ceph osd metadata <OSD_ID> | grep dmcrypt
        ```

        Encrypted OSDs report `"dmcrypt": true` in their metadata.

        <Check>OSD metadata confirms dm-crypt encryption is active.</Check>
      </Step>
    </Steps>

    <Warning>
      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.
    </Warning>
  </Tab>

  <Tab title="Key Management" icon="key">
    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

    <Note>
      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.
    </Note>
  </Tab>
</Tabs>

***

## Cluster Authentication (cephx)

All cluster communication uses cephx, the XSDS cluster authentication framework.
Each service has its own key with minimum required capabilities.

<Tabs>
  <Tab title="View and Inspect Keys" icon="list">
    ```bash title="List all cephx keys" theme={null}
    ceph auth ls
    ```

    ```bash title="View capabilities for a specific key" theme={null}
    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
  </Tab>

  <Tab title="Key Rotation" icon="refresh-cw">
    Rotate cephx keys periodically or immediately after a suspected compromise:

    ```bash title="Rotate a cephx key" theme={null}
    ceph auth rotate client.<NAME>
    ```

    <Note>
      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.
    </Note>

    To generate a completely new key for a service:

    ```bash title="Delete and recreate a key" theme={null}
    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.
  </Tab>

  <Tab title="Least Privilege Caps" icon="shield">
    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'`                                         |

    ```bash title="Update capabilities for a key" theme={null}
    ceph auth caps client.cinder \
      mon 'profile rbd' \
      osd 'profile rbd pool=volumes'
    ```
  </Tab>
</Tabs>

***

## 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           |

<Tabs>
  <Tab title="Recommended Setup" icon="network">
    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 XDeploy
    during initial deployment.

    <Tip>
      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.
    </Tip>
  </Tab>

  <Tab title="Verify Network Config" icon="settings">
    ```bash title="Show cluster network configuration" theme={null}
    ceph config get osd cluster_network
    ceph config get osd public_network
    ```

    ```bash title="Check OSD binding" theme={null}
    ceph osd dump | grep "^osd\." | awk '{print $1, $14, $16}'
    ```
  </Tab>
</Tabs>

***

## Next Steps

<CardGroup cols={2}>
  <Card title="Encryption at Rest" href="/services/storage/encryption" color="#197560">
    Block storage volume-level encryption managed through the Key Management service
  </Card>

  <Card title="Xloud Key Management" href="/services/key-manager/admin-guide" color="#197560">
    Manage and rotate the encryption keys used by XSDS and other services
  </Card>

  <Card title="Cluster Management" href="/services/sds/admin-guide/cluster-management" color="#197560">
    Ongoing operational management for a secured cluster
  </Card>

  <Card title="Troubleshooting" href="/services/sds/admin-guide/troubleshooting" color="#197560">
    Diagnose authentication and connectivity issues
  </Card>
</CardGroup>