---
title: "Best practices for secure deployment\n    | Ubuntu"
description: Ubuntu is an open source software operating system that runs from the
  desktop, to the cloud, to all your internet connected things.
url: https://ubuntu.com/ceph/docs/secure-deployment?format=md
keywords: index, follow
---

*Submit*

# Best practices for secure deployment

Security must be incorporated from the beginning of your Charmed Ceph deployment.

### [Network Architecture](https://ubuntu.com/ceph/docs/secure-deployment?format=md#p-179247-network-architecture)

* Segmentation: Use separate physical or logical (VLAN) networks for different access levels
  + External (optional): If applicable, expose specific endpoints for external untrusted consumption, e.g. RGW.
  + Storage Access: Client access (including RGW if no external access provided), MON access.
  + Cluster Network: OSD replication and heartbeat traffic. Isolating this improves performance and security.
* Firewalls: Implement strict firewall rules (e.g. using iptables, nftables) on all nodes:
  + Deny all traffic by default.
  + Allow only necessary ports between specific hosts/networks (refer to the port table).
  + Restrict access to management interfaces (SSH, Juju, Dashboard) to trusted administrative networks.

### [Minimum Privileges](https://ubuntu.com/ceph/docs/secure-deployment?format=md#p-179247-minimum-privileges)

* Cephx Keys: Create dedicated Cephx keys for each client/application with the minimum required capabilities. Do not use the admin key for routine access.
* Juju Roles: Assign Juju users the least permissive role (e.g., read, write) necessary for their tasks on specific models. Reserve admin rights carefully.
* OS Users: Limit sudo access on host machines. Run services under dedicated, unprivileged users where possible (though OSDs inherently require higher privileges for device access, mitigated by containers/snaps). Apply the least privilege principle rigorously across all layers.
* Explicit Assignment: Ensure that all access, whether via Cephx, Dashboard, or RGW, relies on explicit assignment of permissions/capabilities rather than default permissive settings. Limit permissions strictly to what is needed for the operation.

### [Auditing and Centralized Logging](https://ubuntu.com/ceph/docs/secure-deployment?format=md#p-179247-auditing-and-centralized-logging)

* Enable Auditing: Configure Ceph logging to capture significant events.
* Centralized Logging: Forward logs from all Ceph nodes, host systems (syslog, auth.log), and Juju components to a central logging system (such as Loki, Splunk). This facilitates correlation and analysis.
* Monitor and Audit: Regularly review logs for anomalies, security events (e.g. repeated auth failures).

### [Alerting](https://ubuntu.com/ceph/docs/secure-deployment?format=md#p-179247-alerting)

* Configure Monitoring: Use the built-in Ceph monitoring (Prometheus exporter via MGR module) and integrate it with an alerting system such as the Canonical Observability Stack.
* Security Alerts: Configure alerts for security anomalies and critical health issues, such as:
  + Ceph health status changes (HEALTH\_WARN, HEALTH\_ERR).
  + Daemon crashes or restarts.
  + Near-full OSDs/pools.
  + Significant performance deviations.

---

[Previous

Encryption](https://ubuntu.com/ceph/docs/encryption)
[Next

Best practices for secure operation](https://ubuntu.com/ceph/docs/secure-operation)

This page was last modified 11 months ago. [Help improve this document in the forum](https://discourse.ubuntu.com/t/best-practices-for-secure-deployment/69022).