3 votes

Comment générer des fichiers sudoers personnalisés dans Puppet en fonction de l'environnement dans lequel ils sont déployés?

Les administrateurs système sont présents dans les fichiers sudoers de tous les environnements, mais les autres sudoers ne le sont pas. Les différents environnements ont tous des sudoers légèrement différents. La plupart du temps, 90% des utilisateurs sont les mêmes, et 10% varient donc nous ne pouvons pas avoir qu'un seul fichier sudoers pour tout.

Actuellement, nous utilisons puppet avec 10 fichiers différents portant des noms tels que sudoers.production1, sudoers.production2, sudoers.production3, sudoers.testing1, sudoers.staging1, etc.

Ensuite, Puppet choisit le fichier à déployer en fonction du $domain du serveur (ex : dbserver.staging1.acme.com) ou de $hardwaremodel. Cela fonctionne bien mais il est cauchemardesque de maintenir autant de fichiers.

J'aimerais générer automatiquement des fichiers sudoers en fonction du domaine du serveur et n'avoir qu'un seul fichier volumineux avec toutes les permissions sudoers pour tous les utilisateurs et tous les environnements. Quelque chose qui ressemble à :

User_Alias ADMINS = abe, bob, carol, dave

case $domain {
 "staging1.acme.com" {
    #ajouter dev1, dev2, testeur1, testeur2 au fichier sudoers 
  }
 "testing2.acme.com" {
    #ajouter testeur1, testeur3, testeur4 au fichier sudoers
  }    

Quelle est la meilleure façon de procéder ? Les suggestions d'alternatives sont les bienvenues. Je serais reconnaissant de tout conseil.

Mise à jour 1 :

Pour des raisons de sécurité, nous préférerions ne pas concaténer une série de fichiers provenant d'un dossier situé sur un client Puppet au cas où quelqu'un y placerait un fichier (malicieusement ou non) et soit casse le fichier combiné, soit y insère quelque chose.

Surtout, pour des raisons de convivialité, nous aimerions limiter le nombre de fichiers sudoers (fragment ou complet) sur le serveur Puppet à 3 (prod/stage/test) ou de préférence à 1 seul fichier. Ce fichier générerait (d'une manière ou d'une autre) des fichiers sudoers sur le serveur Puppet et enverrait un fichier personnalisé à chaque client Puppet.

La raison de cela serait la recherche d'un nom d'utilisateur dans un seul fichier et le supprimer plus rapidement que de le faire sur 11 fichiers. Lors de l'ajout d'un utilisateur à plusieurs environnements, cela ne sera pas aussi rapide, mais un seul fichier devrait être ouvert et consulté, réduisant considérablement les risques d'omission.

notre version de Sudo est 1.6.9p8 donc nous ne pouvons pas utiliser le dossier /sudoers.d, seulement un fichier sudoers.

Mise à jour 2 :

J'ai fait quelques recherches sur Google et je viens de trouver ceci, sur lequel j'ai passé la dernière heure à regarder :

https://github.com/saz/puppet-sudo#readme

Je n'en suis pas certain mais il semble que cela pourrait faire l'affaire. Est-ce que quelqu'un l'a utilisé ou en a entendu parler ?

9voto

jammus Points 1796

Quelle version de sudo? Votre version de sudo prend-elle en charge l'utilisation de l'option #includedir pour fractionner les éléments dans un répertoire de fragment /etc/sudoers.d/ ?

Si c'est le cas, je vous suggère d'utiliser cette fonctionnalité pour construire votre configuration.

Faites en sorte que votre fichier de configuration principale soit livré à /etc/sudoers qui inclut tous les paramètres communs à chaque hôte que vous contrôlez. Ensuite, laissez la configuration spécifique aux rôles être ajoutée à un fichier dans /etc/sudoers.d/.

Chaque classe ou section de marionnette est responsable de mettre à jour la petite partie de la configuration des sudo directement liée à cette classe.

3voto

silviud Points 2667

Vous pouvez consulter des ressources virtuelles et réaliser: https://puppet.com/docs/puppet/latest/lang_virtual.html.

Cela fait exactement cela : sur certains systèmes, vous 'réalisez' la ressource et sur d'autres non.

2voto

ewwhite Points 193555

Vous pouvez le faire en utilisant les modèles Puppet... Configuration spécifique au site avec un petit extrait de code Ruby/variable pour l'utilisateur dont vous avez besoin. (Je posterai un exemple plus tard)

La manière traditionnelle de gérer cela est d'utiliser des définitions de groupe au lieu d'utilisateurs nommés dans votre /etc/sudoers. Cela peut être moins contraignant à gérer.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X