Puppet Security and Network Topologies

Contexte:

Je réserve enfin un peu de temps pour rejoindre le 21e siècle et regarder Puppet.

Dans l'état actuel des choses, nous contrôlons la version de toutes les configurations de serveur dans un référentiel qui est conservé en interne au bureau. Lorsqu'une mise à jour doit être effectuée, les modifications sont réintégrées dans les référentiels et transférées manuellement vers la machine en question. Cela signifie généralement SFTP sur la machine distante, puis déplacer les fichiers en place, avec les autorisations appropriées, à partir d'un shell.

J'espère donc que Puppet sera une extension simple mais incroyable de ce que nous avons déjà.

Maintenant, je considère que le processus que nous devons actuellement être raisonnablement sûr. En supposant que notre réseau interne sera toujours relativement plus sécurisé que les réseaux publics de nos centres de données.

• Le processus est toujours à sens unique. Les changements passent d'un environnement sécurisé à un environnement non sécurisé et jamais l'inverse.

• Le magasin principal est dans l'endroit le plus sûr possible. Le risque de compromis, soit en volant des configurations, soit en envoyant des modifications malveillantes, est considérablement réduit.

Question:

D'après ce que je comprends du modèle de serveur / client Puppet, les clients interrogent et tirent les mises à jour directement depuis le serveur. Le trafic est encapsulé SSL et ne peut donc pas être intercepté ou usurpé. Mais cela diffère de ce que nous faisons actuellement parce que le ou les serveurs Puppet devraient être hébergés dans un endroit public. Soit de manière centralisée, soit un pour chaque site de centre de données que nous entretenons.

Je me demande donc:

• Suis-je inutilement paranoïaque à propos du passage de push à pull?

• Suis-je inutilement paranoïaque à propos du stockage centralisé de toutes ces informations sur un réseau public?

• Comment les autres maintiennent-ils plusieurs réseaux - un serveur séparé pour chaque site?

Mise à jour 30/07/09:

Je suppose que l'une de mes autres grandes préoccupations est de placer donc doit faire confiance à une seule machine. Le ou les marionnettistes seraient protégés par un pare-feu, sécurisés, etc. Mais même ainsi, toute machine publique avec des services d'écoute a une surface d'attaque d'une certaine taille.

Vraisemblablement, si le maître a la permission de mettre à jour n'importe quel fichier sur l'un des clients fantoche, alors son compromis entraînerait finalement le compromis de tous ses clients. Les "rois du royaume" pour ainsi dire.

• Cette hypothèse est-elle correcte?

• Existe-t-il un moyen de l'atténuer?

Parce que je stocke parfois des mots de passe dans des variables dans mes modules, pour pouvoir déployer des applications sans avoir à terminer la configuration manuellement, cela signifie que je ne peux pas décemment mettre mon dépôt de marionnettes sur un serveur public. Cela signifierait qu'attaquer le marionnettiste permettrait d'obtenir des mots de passe d'application ou de base de données de toutes nos différentes applications sur tous nos serveurs.

Donc mon marionnettiste est dans notre réseau privé de bureau, et je n'exécute pas de démon marionnette sur les serveurs. Lorsque j'ai besoin de me déployer, j'utilise ssh depuis un réseau privé vers des serveurs, créant un tunnel et appelant à distance puppetd.
L'astuce n'est pas de configurer le tunnel distant et le client marionnette pour qu'il se connecte au puppetmaster, mais à un proxy qui accepte la connexion http et peut atteindre le serveur puppetmaster sur un réseau privé. Sinon, la marionnette refusera de tirer en raison d'un conflit entre le nom d'hôte et les certificats

# From a machine inside privatenet.net :
ssh -R 3128:httpconnectproxy.privatenet.net:3128 \
    -t remoteclient.publicnetwork.net \
    sudo /usr/sbin/puppetd --server puppetmaster.privatenet.net \
    --http_proxy_host localhost --http_proxy_port 3128 \
    --waitforcert 60 --test –-verbose

Ça marche pour moi, j'espère que ça vous aide

Nous avons deux sites, notre bureau et notre colo. Chaque site a son propre marionnettiste. Nous avons mis en place un dépôt svn avec la structure suivante:

root/office
root/office/manifests/site.pp
root/office/modules
root/colo
root/colo/manifests/site.pp
root/colo/modules
root/modules

Le répertoire des modules sous chaque site est un répertoire svn: externals vers le répertoire des modules de niveau supérieur. Cela signifie qu'ils partagent exactement le même répertoire de modules. Nous nous assurons ensuite que la grande majorité des classes que nous écrivons sont sous le répertoire des modules et utilisées par les deux sites. Cela a l'avantage de nous obliger à penser de manière générique et à ne pas lier une classe à un site particulier.

En ce qui concerne la sécurité, nous hébergeons notre marionnettiste (et le reste de notre réseau) derrière notre pare-feu, nous ne sommes donc pas très préoccupés par le stockage central de la configuration. Le marionnettiste n'enverra la configuration qu'aux hôtes en qui il a confiance. De toute évidence, vous devez garder ce serveur sécurisé.

Je ne peux pas juger de la nécessité de votre paranoïa, cela dépend fortement de votre environnement. Cependant, je peux dire avec confiance que les deux points principaux de votre configuration existante peuvent toujours s'appliquer. Vous pouvez vous assurer que votre changement passe d'un environnement sécurisé (le référentiel de votre bureau) à un environnement moins sécurisé, où que se trouve votre marionnettiste. Vous changez le processus de SFTP'ing en un groupe de serveurs et mettez manuellement les fichiers en place à SFTP'ing à votre marionnettiste et laissez Puppet distribuer les fichiers et les placer au bon endroit. Votre magasin maître est toujours le référentiel et vos risques sont atténués.

Je ne pense pas que pousser ou tirer soit intrinsèquement plus sûr que l'autre modèle. Puppet fait un excellent travail de sécurisation des configurations en transit, ainsi que d'authentification du client et du serveur pour s'assurer qu'il y a une confiance bidirectionnelle en place.

Quant aux réseaux multiples - nous le traitons avec un marionnettiste "maître" central avec des marionnettistes satellites à chaque emplacement agissant comme clients du maître central.

Une approche de conception consiste à avoir un marionnettiste local sur chaque site de systèmes et à utiliser un outil de déploiement pour pousser les changements aux marionnettistes. (L'utilisation de git avec des crochets git pourrait également fonctionner).

Cela préserverait votre inquiétude concernant les services d'écoute sur un réseau public car le trafic du réseau fantoche ne serait que interne.

Il est également possible de pousser les manifestes vers chaque serveur et de demander au client fantoche d'analyser les manifestes et d'appliquer les configurations appropriées.

bien que vous disiez "externe", je doute vraiment que des personnes arbitraires aient besoin de se connecter à votre marionnettiste. vous pouvez toujours jeter un VPN dans le mélange. un de mes amis m'a demandé un jour "avez-vous besoin de vous soucier de la sécurité du protocole si la connexion est sécurisée?" alors que je ne suis pas d'accord avec cette attitude, une couche supplémentaire ne fait jamais de mal et fait certainement des merveilles sur ma paranoïa personnelle. en plus, c'est amusant de creuser des tunnels.

Mark Burgess, l'auteur de cfengine et professeur d'université (cette marionnette semble devoir son héritage à) a beaucoup écrit sur le push and pull. Il prétend que la traction est intrinsèquement plus sûre. Si vous regardez le site Web de cfengine, ils n'ont eu qu'un seul incident de sécurité réseau en 17 ans. Burgess affirme que c'est à cause de la conception de la traction. Je pense qu'un seul point de compromis est inévitable. Je serais plus préoccupé par les voies d'attaque jusqu'à ce point.

Vous pouvez exécuter des marionnettes sans maître central si vous le souhaitez. Une méthode que j'ai vue utilise un référentiel git et des scripts qui ne fusionneront et déploieront une mise à jour que si la balise est signée par l'une d'une liste prédéfinie de clés gpg. Les gens ont même découvert comment obtenir des configurations stockées (utilisées par exemple pour configurer la surveillance des nagios sur un serveur central à partir d'une ressource traitée sur un autre serveur).

Donc, si le serveur git central était compromis, les autres serveurs ne lui appliqueraient plus de mises à jour. Les clés gpg seraient sur les ordinateurs portables d'administration sys ou quelque chose, avec une certaine façon de révoquer les clés.

En savoir plus sur http://current.workingdirectory.net/posts/2011/puppet-without-masters/