SaltStack sécurité : guide complet pour déployer proprement en entreprise

Réponse rapide

SaltStack sécurité ne se limite pas à “installer un master et des minions”. En entreprise, il faut combiner architecture propre (states/pillar/environments), durcissement serveur, gestion stricte des clés, contrôle réseau des ports Salt, et gouvernance Git. Sans ces couches, l’automatisation peut devenir un risque au lieu d’un accélérateur.

Présentation : ce que SaltStack fait vraiment

SaltStack est une plateforme d’automatisation et de gestion de configuration orientée exécution rapide à grande échelle. Son modèle classique repose sur un Salt Master qui orchestre des Salt Minions. Il peut fonctionner en mode agentless via SSH (Salt-SSH), mais son mode le plus puissant reste master/minion avec bus d’événements.

Salt est particulièrement pertinent quand tu as besoin de :

• pilotage centralisé de nombreux nœuds,
• réactivité élevée (commandes fan-out),
• mécanismes event-driven (réactions automatiques),
• modèle déclaratif (states) + données séparées (pillar).

Quand utiliser SaltStack par rapport à Ansible (ou autre)

SaltStack

• Très bon pour orchestration temps réel et grandes flottes.
• Modèle master/minion efficace pour push massif.
• Fort potentiel sur événements et automatisation continue.

Ansible

• Simple à démarrer, agentless natif, très lisible en équipe.
• Souvent privilégié pour standardisation infra classique et onboarding rapide.
• Excellent pour playbooks orientés tâches et rôles reproductibles.

Décision pragmatique

Choisis SaltStack si ton enjeu principal est la vitesse d’orchestration et la gestion événementielle à échelle importante. Choisis Ansible si la priorité est la simplicité d’exploitation et la lisibilité équipe. Dans certains contextes, un mix est possible (ex : Ansible pour bootstrap, Salt pour run continu).

Requirements techniques avant installation

• OS supporté (souvent Linux côté master/minion ; vérifier selon version Salt).
• DNS/réseau propre entre master et minions.
• Horloge synchronisée (NTP) pour éviter des effets de bord.
• Accès root/sudo maîtrisé.
• Politique de firewall définie avant ouverture de flux.

Important sécurité : ne pas exposer le Salt Master sur Internet public. Les communications Salt doivent rester dans un réseau privé contrôlé (VPN, VLAN, bastion, ACL).

Installation de base (exemple Linux)

Les commandes exactes dépendent de la distribution et de la version ciblée. Toujours suivre la documentation officielle Salt pour les dépôts/signatures à jour.

Master

# Exemple générique (adapter selon distro)
sudo apt update
sudo apt install salt-master -y
sudo systemctl enable --now salt-master
sudo systemctl status salt-master --no-pager

Minion

sudo apt update
sudo apt install salt-minion -y

# /etc/salt/minion : définir l'adresse du master
# master: 10.0.10.5

sudo systemctl enable --now salt-minion
sudo systemctl status salt-minion --no-pager

Premier test (safe)

1) Vérifier les clés

sudo salt-key -L
# Accepter une clé minion précise
sudo salt-key -a minion01

2) Test ping

sudo salt '*' test.ping

3) Test d’information système

sudo salt 'minion01' grains.item os osrelease ipv4

Premier apply (states)

Le cœur de Salt, c’est l’application d’états déclaratifs. Commence petit : un state simple, idempotent, et vérifiable.

# /srv/salt/base/motd/init.sls
/etc/motd:
  file.managed:
    - source: salt://motd/files/motd
    - user: root
    - group: root
    - mode: '0644'

# Dry-run
sudo salt 'minion01' state.apply motd test=True

# Apply réel
sudo salt 'minion01' state.apply motd

Architecture Salt : states, pillar, grains, environments

States

Décrivent l’état cible (packages, fichiers, services). C’est ta couche “configuration déclarative”.

Pillar

Données sensibles ou contextuelles injectées côté minion. Exemple : credentials, variables métier, paramètres d’environnement. Les pillars ne doivent pas être traités comme du texte banal ; ils demandent une gouvernance stricte.

Grains

Faits système (OS, IP, hostname…) utilisés pour cibler et conditionner les states.

Environments (saltenv/pillarenv)

Sépare tes environnements (dev/staging/prod) pour éviter les collisions. C’est un point clé pour éviter d’appliquer un state de test en production.

Gérer Salt via Git (modèle recommandé)

Versionner states et pillar (hors secrets en clair), imposer revue de merge request, et déployer selon branches/environnements.

Structure type

salt-infra/
  states/
    base/
    prod/
  pillar/
    base/
    prod/
  formulas/
  docs/
  .gitlab-ci.yml

Bonnes pratiques Git

• Branches par changement (pas de direct main en prod).
• MR avec review obligatoire.
• Tests dry-run avant apply réel.
• Changelog des changements sensibles.

Sécurité réseau Salt : ports et exposition

Point critique demandé : ne jamais exposer les ports Salt master/minion sur Internet public.

Principe

• Master joignable uniquement depuis minions autorisés.
• Minions non exposés publiquement.
• Filtrage IP strict (allowlist réseau interne/VPN).
• Aucun accès direct externe au plan de contrôle Salt.

Vérification locale

# Voir les ports en écoute
ss -tulpen | grep salt

# Vérifier règles firewall (exemple selon stack)
sudo nft list ruleset
# ou
sudo ufw status verbose

Sécurité des clés et des accès

• Valider strictement les clés minions, ne pas accepter à l’aveugle.
• Révoquer immédiatement les minions obsolètes/compromis.
• Durcir l’accès SSH du master (clé only, root login off, allowlist users).
• Ajouter Fail2ban sur les services exposés (notamment SSH).

# Fail2ban (exemple)
sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Pièges fréquents à éviter

1. Tout appliquer sur * trop tôt : commence par un scope minion ciblé.
2. Mélanger secrets et code : jamais de secret en clair dans Git states.
3. Pas de test=True avant apply : augmente fortement le risque d’incident.
4. Absence de séparation env : confusion dev/prod quasi garantie.
5. Logs non exploités : impossible d’analyser un rollback raté.

Observabilité et exploitation continue

Une stack Salt sécurisée doit rester observable :

• journalisation master/minion,
• alertes sur erreurs répétées,
• tableau de suivi des apply critiques,
• runbook incident documenté.

Checklist production SaltStack sécurité

• Master/minions dans réseau privé, pas Internet public.
• Firewall/ACL strictes sur flux Salt.
• Clés minions validées/révoquées proprement.
• States/Pillar versionnés avec revue MR.
• Séparation claire dev/staging/prod.
• Dry-run obligatoire avant apply critique.
• Secrets protégés (pas en clair, rotation planifiée).
• SSH durci + Fail2ban + audit régulier.

FAQ

SaltStack est-il plus “sécurisé” qu’Ansible ?

Ce n’est pas une question binaire. La sécurité dépend surtout de l’architecture, des accès, du réseau et de la gouvernance d’exploitation.

Peut-on utiliser SaltStack sur Windows ?

Oui, mais il faut valider précisément la compatibilité de version, les modules nécessaires et les contraintes d’exploitation selon ton contexte.

Comment éviter un incident massif au premier déploiement ?

Scope réduit, test=True, environnement de préprod, validation humaine et rollback prêt avant toute généralisation.

Faut-il absolument Git pour Salt ?

Techniquement non, opérationnellement oui : sans versioning/review, la dette et le risque montent très vite.

Qu’est-ce que pillar apporte vraiment ?

La séparation entre logique de configuration (states) et données contextuelles/sensibles, ce qui améliore la maintenabilité et la sécurité.

Sources officielles

• Salt Project Documentation
• Salt walkthrough (master/minion, states)
• Pillar tutorial
• salt-key reference
• ss(8) man page
• Fail2ban documentation

Conclusion

SaltStack peut être un excellent choix entreprise si tu cherches une orchestration rapide et robuste, à condition de traiter la sécurité comme une architecture complète : réseau, accès, clés, secrets, Git, tests et gouvernance. C’est cette discipline qui transforme un setup “qui marche” en plateforme fiable en production.

Architecture Salt recommandée en entreprise (exemple concret)

Pour rester simple et fiable, une architecture typique peut être organisée comme suit :

• 1 Salt Master en zone d’administration privée,
• Minions segmentés par environnement (dev/staging/prod),
• repo Git unique avec branches protégées,
• pipeline CI qui valide syntaxe/lint avant merge,
• orchestration progressive (canary puis généralisation).

L’idée n’est pas de complexifier, mais de garder un chemin d’exécution auditable du commit jusqu’à l’apply.

Exemple de targeting propre (éviter le « * »)

Au lieu d’exécuter sur tous les minions, cible par rôle ou environnement :

# Cibler uniquement les minions web de prod (exemple)
sudo salt -C 'G@role:web and G@env:prod' test.ping

# Apply contrôlé
sudo salt -C 'G@role:web and G@env:prod' state.apply nginx test=True

Ce pattern réduit le blast radius en cas d’erreur de state.

Sécurité des secrets : options réalistes

Les pillars peuvent contenir des données sensibles, mais il faut une stratégie claire :

• séparer variables sensibles et non sensibles,
• restreindre l’accès au repo et aux branches secrets,
• activer revue obligatoire sur tout changement sensible,
• prévoir rotation et révocation documentées.

Dans une organisation mature, on combine souvent Salt avec un gestionnaire de secrets externe.

Procédure de mise en production sans stress

1. Validation locale des states.
2. Dry-run sur préprod (test=True).
3. Apply sur un petit sous-ensemble de minions.
4. Contrôle des logs et métriques.
5. Généralisation par lots.

Cette procédure limite les incidents et facilite le rollback si nécessaire.

Rollback et récupération : ce qu’il faut prévoir

Un bon setup Salt inclut un plan de retour arrière :

• version de state précédente identifiée,
• commande de ré-application connue et testée,
• sauvegarde des configurations critiques avant apply majeur,
• fenêtre de déploiement avec supervision active.

Ne pas prévoir le rollback est l’une des erreurs les plus coûteuses en production.

Gouvernance d’équipe : qui peut faire quoi ?

Pour éviter les dérives, définis des rôles :

• Owner automation : valide les states structurants,
• Contributeur : propose via MR,
• Reviewer sécurité : contrôle impacts accès/ports/secrets,
• Opérateur : exécute selon procédure validée.

Cette séparation réduit les erreurs humaines et facilite l’audit interne.

Comparatif opérationnel SaltStack vs Ansible (lecture rapide)

Critère	SaltStack	Ansible
Mode principal	Master/Minion	Agentless (SSH)
Réactivité temps réel	Très bonne	Bonne
Simplicité initiale	Moyenne	Élevée
Event-driven natif	Fort	Plus limité nativement
Courbe d’apprentissage	Plus marquée	Souvent plus douce

Ce tableau aide à cadrer le choix, mais le meilleur outil reste celui que ton équipe opère proprement.

Cas d’usage où SaltStack est un très bon choix

• infrastructure multi-serveurs avec changements fréquents,
• besoin de remédiation rapide à large échelle,
• gestion de configuration continue avec événements.

À l’inverse, pour des contextes simples ou des petites équipes, Ansible peut rester plus pragmatique.

Glossaire utile (pour éviter les malentendus)

• Master : nœud central qui orchestre les exécutions Salt.
• Minion : agent Salt installé sur un serveur géré.
• State : description déclarative de l’état cible d’un système.
• Pillar : données contextuelles/sensibles injectées pour les states.
• Grains : informations système du minion (OS, IP, rôle, etc.).
• Idempotence : relancer une configuration ne doit pas casser l’état stable.