Puppet ou Chef convient-il pour gérer la configuration de serveur très basique dans un environnement multi-locataire?

Cela concerne les environnements multi-locataires tels qu'une petite société d'hébergement.

Puppet (ou similaire) est-il une technologie appropriée pour prendre en charge les changements de masse fondamentaux mais critiques? Par exemple:

• Mise à jour des résolveurs DNS (resolv.conf)
• Définition des clés SSH
• Mise à jour de la configuration NTP
• Configuration de snmpd
• Déploiement de scripts de surveillance tels que des extensions SNMP Perl ou des scripts Nagios

Mes préoccupations concernent la sécurité et le caractère envahissant:

1. Je ne veux pas qu'un serveur puisse voir une configuration qu'il ne devrait pas
2. Je crains qu'un maître Puppet ne soit vulnérable aux attaques d'un serveur compromis
3. Je ne veux pas que Puppet fasse des changements qu'il ne devrait pas faire, ni annuler les changements manuels effectués sur le serveur.

Je devrais faire une mise en garde en disant que je n'ai jamais utilisé Puppet en production, je n'ai fait qu'un petit tour dans un laboratoire de test, il est donc possible que j'y pense de la mauvaise façon!

Essayez Ansible (ansible.cc). Peut-être que c'est pour vous. Aucun agent n'est en cours d'exécution sur vos clients. Il se développe très rapidement.

Une autre très bonne alternative est Salt Stack.

Ansible et Salt sont faciles à comprendre, vous pouvez les utiliser comme outil de ligne de commande si vous le souhaitez, comme un shell distribué.

Oui, c'est certainement possible. C'est à vous de décider si vous devez le faire ou non.

Concernant vos requêtes:

1) assez juste. Le trafic est basé sur SSL, donc la gestion des certificats est importante. Ne vous fiez pas non plus aux «faits» que le client fournit concernant son identité, car ceux-ci peuvent être modifiés par le client. Vous souhaitez vous fier au certificat SSL du client pour fournir l'authentification de l'identité du serveur. Pour être honnête, si vous utilisez correctement des éléments comme hiera et évitez les énormes blocs if basés sur le nom d'hôte dans votre code (ce que vous devriez vraiment), tout ira bien.

2) Cela ne devrait pas l'être, en supposant que vous le conserviez corrigé. Correctement configuré, il n'y a qu'un petit vecteur pour que le marionnettiste soit attaqué par les clients. Cela dit, les effets s'ils sont compromis sont importants, alors faites attention à le verrouiller.

3) C'est vraiment un problème de test et de déploiement. Si vous avez un code de marionnette solide, il ne vissera pas vos fichiers. Cela prend un peu de temps pour obtenir ce tri, mais pour les bases (comme vous en avez besoin) pas longtemps.

Puppet (ou similaire) est-il une technologie appropriée pour prendre en charge les changements de masse fondamentaux mais critiques?

Oui, il peut être utilisé de cette façon. Je l'utilise pour prendre en charge les systèmes de clients externes.

Je ne veux pas qu'un serveur puisse voir une configuration qu'il ne devrait pas

Si vous utilisez une marionnette, vous ne devez alors pas activer la signature automatique. La signature automatique permet aux hôtes de demander automatiquement un certificat. Votre configuration et vos autorisations seront certainement liées directement au CN dans le certificat. Vous ne voulez pas qu'un ordinateur aléatoire soit mis en ligne et puisse prétendre qu'il s'agit en fait du système avec tous les éléments secrets de haute sécurité.

Si vous êtes vraiment paranoïaque, vous pouvez ajuster les paramètres du serveur de fichiers des marionnettes pour créer des partages auxquels seuls certains systèmes peuvent accéder. L'accès au serveur de fichiers est basé sur les certificats.

Je ne veux pas que Puppet fasse des changements qu'il ne devrait pas faire, ni annuler les changements manuels effectués sur le serveur.

Il existe deux approches différentes pour permettre des changements locaux.

Une méthode que j'utilise fréquemment est ci-dessous. Fondamentalement, si vous passez une liste à un source, la marionnette essaie chaque élément de la liste. J'ajoute donc le premier élément de la liste pour pointer vers un fichier local.

  file { '/etc/ssh/sshd_config':
    ensure => present,
    source => ["/etc/ssh/sshd_config_local",
               "puppet:///modules/ssh/$ssh_config_file"],
    ...
  }

Une autre option serait d'utiliser des liens symboliques. Si quelqu'un veut utiliser la version marionnette, il crée un lien symbolique vers la version marionnette d'un fichier. S'ils veulent conserver leur configuration localement, ils ne créent pas de lien symbolique.

  file { '/etc/ssh/sshd_config_puppet':
    ensure => present,
    source => "puppet:///modules/ssh/$ssh_config_file",
    ...
  }

L'autre possibilité consiste à utiliser augeas pour effectuer des modifications au niveau ligne au lieu de modifier des fichiers entiers. Soyez très conservateur sur ce que vous changez.

3> Il n'y a pas d'annulation automatique dans Puppet ou dans de tels outils. Vous devez écrire du code explicite pour annuler. De plus, vous pouvez rechercher la fonctionnalité Environnements de marionnette, disposer d'un laboratoire de test où le nouveau code est testé (il peut s'agir de machines virtuelles) et utiliser la révision de code.

Je ne veux pas que Puppet fasse des changements qu'il ne devrait pas faire, ni annuler les changements manuels effectués sur le serveur.

Pour les fichiers de configuration créés à l'aide du type de fichier Puppets, cela peut être obtenu en définissant:

replace => false,

Je l'utilise pour générer des fichiers de configuration la première fois qu'une application est déployée sur un serveur, mais les modifications apportées à ce fichier de configuration ne seront pas écrasées par Puppet.

Cependant, cela va à l'encontre de la philosophie de Puppet d'être un script de déploiement idempotent.

Il peut être préférable, si vous le pouvez, d'avoir des fichiers admin-ediables séparés qui ne sont pas gérés par marionnette qui sont inclus à partir des fichiers qui sont gérés par marionnette.

Puppet fonctionne mieux pour de nombreux serveurs avec une configuration identique. Par exemple, vous écrivez toute la configuration d'un serveur Web partagé fournie par votre entreprise, puis créez N instances de ce serveur. Ensuite, faire des changements sur toutes les instances à la fois (par exemple, vous découvrirez que vous devez changer AllowOverride pour tous les hôtes virtuels apache) sera vraiment facile. Vous pourrez également stocker toutes les informations de configuration en un seul endroit et les avoir sous contrôle de version. Dans le cas parfait, vous pourrez gérer une défaillance matérielle en jetant l'hôte défectueux, en le remplaçant par un nouveau, en définissant le même nom d'hôte et en signant le certificat requis. Tout le reste pourrait être fait par Puppet.

Mais si vous vous retrouvez avec presque aucun partage de configuration entre deux hôtes, l'utilisation de marionnettes peut être moins productive que la configuration manuelle. Gérer également la moitié de la configuration du serveur avec des marionnettes et l'autre moitié manuellement peut ne pas avoir beaucoup de sens.

Résumé : Si vous pouvez créer une configuration uniforme et structurée pour les hôtes que vous allez gérer, Puppet est votre meilleur ami, mais si vous devez gérer chaque service (hôte, hôte virtuel, base de données) spécialement Puppet n'ajoutera pas beaucoup de valeur.