Renforcer la sécurité Ceph avec des exemples pratiques

Intro

Cette version française explique Ceph security hardening with practical examples avec le même objectif pratique que l article source : aider le lecteur à comprendre le contexte, les décisions à prendre et les points à vérifier avant de passer à l action.

Ceph est un système de stockage distribué puissant. Une telle puissance implique des risques si l'on conserve les valeurs par défaut. Ce guide pratique explique comment renforcer la Ceph security par petites étapes sûres et mesurables :

• Utiliser cephx avec des caps en moindre privilège
• Stocker et protéger correctement les secrets
• Réduire la surface d'attaque réseau
• Activer le chiffrement du transport sur le fil
• Verrouiller le Dashboard
• Faire une rotation sûre des identifiants
• Lancer des contrôles reproductibles pour vérifier le hardening

Ces étapes peuvent être appliquées progressivement. Un pilote local simple est inclus pour tester avant de déployer à l'échelle du cluster. Les exemples s'intègrent bien aux environnements Linux, aux clusters de stockage et aux usages RBD (fréquents en virtualisation, par exemple avec Proxmox).

Vue d'ensemble du workflow

Le workflow suivant vise la clarté et la sécurité. Appliquez chaque étape, validez, puis seulement ensuite poursuivez.

1. Inventaire et baseline

• Lister les versions et l'état de santé :

ceph versions
ceph -s
ceph health detail

• Capturer la configuration effective pour la traçabilité :

ceph config dump -f json-pretty > ceph-config-baseline.json

1. Verrouiller l'authentification et l'autorisation (cephx)

• S'assurer que l'insecure global id reclaim est désactivé (comportement requis pour une messagerie plus sûre) :

ceph config get mon auth_allow_insecure_global_id_reclaim
ceph config set mon auth_allow_insecure_global_id_reclaim false

• Créer un client à privilèges minimaux pour l'accès RBD à un pool unique (exemple : vms) :

sudo ceph auth get-or-create client.rbduser \
  mon 'profile rbd' \
  osd 'profile rbd pool=vms' \
  mgr 'allow r' \
  -o /etc/ceph/ceph.client.rbduser.keyring

• Serrer les caps pour un client existant (mise à jour sur place) :

ceph auth caps client.rbduser \
  mon 'profile rbd' \
  osd 'profile rbd pool=vms' \
  mgr 'allow r'

• Pour des caps basées sur les chemins CephFS (exemple) :

ceph fs authorize cephfs client.webuser /var/www r

1. Secrets au repos : protéger les keyrings et le matériel admin

• Restreindre les permissions et la propriété des keyrings :

sudo chown ceph: ceph /etc/ceph/ceph.client.rbduser.keyring
sudo chmod 600 /etc/ceph/ceph.client.rbduser.keyring

• Éviter les admin keyrings sur les hôtes applicatifs. Utiliser l'identité restreinte sur les nœuds applicatifs.

1. Réduire l'exposition réseau

• Séparer les réseaux dans ceph.conf (valeurs d'exemple) :

# /etc/ceph/ceph.conf
[global]
 public_network = 10.10.0.0/24
 cluster_network = 10.20.0.0/24
 ms_bind_msgr2 = true
 auth_allow_insecure_global_id_reclaim = false

• Appliquer des règles de pare-feu hôte. Autoriser uniquement les ports requis depuis des sous-réseaux de confiance. Exemple avec iptables :

# Autoriser les monitors sur le réseau public (msgr2 3300, legacy 6789) depuis le sous-réseau de confiance
sudo iptables -A INPUT -p tcp -s 10.10.0.0/24 --dport 3300 -j ACCEPT
sudo iptables -A INPUT -p tcp -s 10.10.0.0/24 --dport 6789 -j ACCEPT

# Autoriser la plage OSD uniquement sur le cluster network
sudo iptables -A INPUT -p tcp -s 10.20.0.0/24 --dport 6800:7300 -j ACCEPT

# Bloquer le trafic non sollicité vers les ports Ceph (l'ordre compte; placer après les ACCEPT explicites)
sudo iptables -A INPUT -p tcp --dport 3300 -j DROP
sudo iptables -A INPUT -p tcp --dport 6789 -j DROP
sudo iptables -A INPUT -p tcp --dport 6800:7300 -j DROP

• Rendre les règles persistantes via l'outil de votre distribution.

1. Activer le transport chifré (Messenger v2)

• Vérifier que msgr2 est bindé et joignable (port 3300) et que msgr1 n'est pas requis par vos clients.
• Le paramètre vu plus haut doit être à false :

ceph config get mon auth_allow_insecure_global_id_reclaim

• Contrôler que clients et daemons préfèrent les adresses v2 :

ceph mon dump | grep v2:
ceph osd dump | grep v2:

1. Restreindre et chiffrer le Ceph Dashboard

• Activer HTTPS sur le Dashboard avec votre certificat et votre clé :

ceph dashboard set-ssl-certificate -i dashboard.crt
ceph dashboard set-ssl-private-key -i dashboard.key
ceph config set mgr mgr/dashboard/ssl true

• Créer un rôle admin dédié pour l'exploitation quotidienne (éviter l'usage excessif de l'admin intégré) :

ceph dashboard ac-user-create secadmin 'StrongP4ssw0rd!' administrator

• Exposer le Dashboard seulement sur des interfaces de confiance et, si besoin, via un reverse proxy.

1. Rotation de credentials sans interruption

• Créer un nouveau principal, basculer les apps, puis retirer l'ancien :

# Créer un nouveau client avec les mêmes caps
sudo ceph auth get-or-create client.rbduser_v2 \
  mon 'profile rbd' \
  osd 'profile rbd pool=vms' \
  mgr 'allow r' \
  -o /etc/ceph/ceph.client.rbduser_v2.keyring

# Mettre à jour la config applicative pour utiliser client.rbduser_v2, puis vérifier l'accès

# Supprimer l'ancienne identité quand c'est sûr
ceph auth rm client.rbduser

1. Contrôles de validation (répétables)

• Portée d'accès correcte :

ceph auth list | grep client.rbduser
ceph auth get client.rbduser -f json-pretty

• Exposition réseau minimale :

ss -tulpn | grep -E 'ceph|3300|6789|6800|7300'

• Sécurité sur le fil appliquée :

ceph config get mon auth_allow_insecure_global_id_reclaim
ceph mon dump | grep -E 'v2:'

• Santé du cluster stable après chaque changement :

ceph -s
ceph health detail

Plan pilote local

Objectif : tester en toute sécurité l'accès en moindre privilège et le durcissement du transport pour une application utilisant un pool unique, et resserrer le pare-feu sur un hôte.

Périmètre

• Stockage : pool vms
• App : un hôte VM mappant une image RBD
• Nœuds concernés : un hôte OSD (pare-feu), les monitors (flags), et l'hôte applicatif (identité client)

Étapes

1. Préparer et capturer l'état actuel

ceph -s
ceph config dump -f json-pretty > pilot-pre-config.json

1. Créer un client restreint pour l'app

sudo ceph auth get-or-create client.vmapp \
  mon 'profile rbd' \
  osd 'profile rbd pool=vms' \
  mgr 'allow r' \
  -o /etc/ceph/ceph.client.vmapp.keyring
sudo chown ceph: ceph /etc/ceph/ceph.client.vmapp.keyring
sudo chmod 600 /etc/ceph/ceph.client.vmapp.keyring

1. Mapper et utiliser une image RBD avec la nouvelle identité

# Sur l'hôte applicatif
rbd -n client.vmapp --keyring /etc/ceph/ceph.client.vmapp.keyring \
  map vms/test-image

# Test d'E/S simple
sudo dd if=/dev/zero of=/dev/rbd/vms/test-image bs=1M count=64 oflag=direct

1. Renforcer la sécurité sur le fil

ceph config set mon auth_allow_insecure_global_id_reclaim false
# Confirmer l'usage des endpoints v2
ceph mon dump | grep v2:

1. Verrouiller le pare-feu sur un hôte OSD (pilote)

# Autoriser le trafic OSD du cluster network uniquement depuis le sous-réseau cluster
sudo iptables -A INPUT -p tcp -s 10.20.0.0/24 --dport 6800:7300 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 6800:7300 -j DROP

1. Valider et mesurer

• Fonction : l'E/S de l'app réussit, pas d'erreurs d'auth dans les logs
• Sécurité : endpoints msgr2 annoncés, insecure reclaim désactivé
• Exposition : seuls les ports attendus sont ouverts

ceph -s
journalctl -u ceph-* | tail -n 100
ss -tulpn | grep -E '3300|6789|6800|7300'

Rollback (si nécessaire)

• Revenir en arrière sur les règles de pare-feu en supprimant les nouvelles règles DROP
• Réactiver temporairement l'ancienne identité client sur l'app
• Restaurer le snapshot de configuration si un toggle pose problème :

# Exemple de suppression d'une règle DROP (adapter les numéros)
sudo iptables -L INPUT --line-numbers
sudo iptables -D INPUT <rule_number>

Critères de succès

• L'app fonctionne avec uniquement client.vmapp
• Les pools non autorisés restent inaccessibles
• Seuls les ports nécessaires sont ouverts sur l'hôte pilote

Conclusion

Le Ceph hardening est d'autant plus efficace qu'il est appliqué par étapes :

• Faire respecter cephx avec des caps en moindre privilège
• Protéger les keyrings par des permissions strictes et une distribution limitée
• Limiter l'exposition réseau aux sous-réseaux et ports requis
• Préférer Messenger v2 et désactiver les comportements non sûrs
• Restreindre et chiffrer le Dashboard
• Faire une rotation des credentials avec une bascule contrôlée
• Vérifier avec des checks simples et reproductibles après chaque changement

Vérifications rapides avant un déploiement élargi :

# Caps en moindre privilège et correctes
ceph auth get client.vmapp -f json-pretty

# Sécurité sur le fil active
ceph config get mon auth_allow_insecure_global_id_reclaim
ceph mon dump | grep v2:

# Uniquement les ports nécessaires atteignables
ss -tulpn | grep -E 'ceph|3300|6789|6800|7300'

# Cluster en bonne santé
ceph -s

Adoptez le pilote, ajustez à votre topologie, puis étendez par étapes aux pools et nœuds concernés. Documentez chaque décision pour accélérer la maintenance et la réponse aux incidents.