Modifier le fichier sudoers avec le modèle de playbook ansible


8

J'essaie de créer un fichier sudoers avec un modèle ansible. Le fichier sudoers devrait ressembler à ci-dessous:

Cmnd_Alias LS = /bin/ls
Cmnd_Alias LESS = /usr/bin/less
Cmnd_Alias DU = /usr/bin/du

%support1 ALL=(ALL) NOPASSWD: LS, LESS, DU

Ce que j'ai réussi jusqu'à présent est ci-dessous:

Cmnd_Alias LS = ls
Cmnd_Alias LESS = less
Cmnd_Alias DU = du

%support1 ALL=(ALL) NOPASSWD: LS, LESS, DU

Le modèle ressemble à ci-dessous:

{% for item in commands %}
Cmnd_Alias {{ item|upper }} = {{ item }}
{% endfor %}

%{{ group }} ALL=(ALL) NOPASSWD: {% for item in commands %}
{{ item|upper}}{% if not loop.last %}, {% endif %}
{% endfor %}

vars

commands:
  - ls
  - less
  - du

Pour autant que je sache, le module de modèle ansible n'a rien qui puisse exécuter la commande dans le serveur distant et imprimer la sortie, sinon je pensais à changer le fichier de modèle pour ressembler à ci-dessous:

{% for item in commands %}
Cmnd_Alias {{ item|upper }} = `which {{ item }}`
{% endfor %}

%{{ group }} ALL=(ALL) NOPASSWD: {% for item in commands %}
{{ item|upper}}{% if not loop.last %}, {% endif %}    
{% endfor %}

et la sortie sera comme ce que je voulais.

Existe-t-il une autre méthode qui peut simplifier les choses?

BTW j'ai déjà vérifié ce post


Je voudrais simplement placer le chemin complet de la commande dans vos vars
jdog

Pour les modifications sur le système, je préfère inclure des scripts dans bash pour mieux fonctionner.
lORD

Réponses:


5

TL; DR: BAISER. N'utilisez pas moins.

Les gens font souvent une erreur avec ansible en essayant de faire des choses variables qui n'ont pas besoin d'être. À moins qu'il y ait plusieurs endroits où vous définissez la liste des commandes auxquelles le support peut accéder, il est parfaitement acceptable de simplement les placer dans le fichier de création de modèle:

templates / etc / sudoers.d / support1

Cmnd_Alias LS = /bin/ls
Cmnd_Alias LESS = /bin/cat
Cmnd_Alias DU = /usr/bin/du

%support1 ALL=(ALL) NOPASSWD: LS, LESS, DU

ou même explicitement car vous ne réutilisez le Cmnd_Alias ​​nulle part

%support1 ALL=(ALL) NOPASSWD: /bin/ls
%support1 ALL=(ALL) NOPASSWD: /bin/cat
%support1 ALL=(ALL) NOPASSWD: /usr/bin/du

Et ajoutez une tâche comme:

- name: add templates
  template:
    src: {{ item }}
    dest: /{{ item }}
    owner: root
    group: root
    mode: 0640
  with_items:
    - etc/sudoers.d/support1

Vous utiliseriez uniquement des modèles au lieu de fichiers, car plus tard, il pourrait y avoir une variable à ajouter à tous ceux-ci ou le nom du groupe pourrait provenir d'une variable si vous obtenez un autre rôle qui crée les groupes.

Si vous devez utiliser une variable, vous pouvez utiliser une liste de hachages comme celle-ci:

sudoers.support1.commands:
- { alias: "LS", path: "/bin/ls" }
- { alias: "DU", path: "/usr/bin/du" }

Puis dans le modèle:

{% for item in sudoers.{{ group }}.commands %}
Cmnd_Alias {{ item.alias }} = {{ item.path }}
{% endfor %}
%{{ group }} ALL=(ALL) NOPASSWD: {{ sudoers.{{ group }}.commands | map(attribute='alias') | join(', ') }}

Il n'est pas sûr d'utiliser / usr / bin / less

Dans tout cela, vous n'avez pas remarqué beaucoup de chose importante et c'est l'utilisation de moins en tant que spectateur. Malheureusement, c'est un trou de sécurité. Vous pouvez taper '! Bash' pour appeler bash. Et en appuyant sur «v», vous accédez à l'éditeur en fonction des variables VISUAL, EDITOR ou LESSEDIT. Vous pouvez donc leur donner '/ bin / cat' et ils peuvent toujours canaliser le contenu en moins eux-mêmes. Notez que c'est toujours une faille de sécurité car certains fichiers sous Unix sont très intentionnellement restreints par exemple:

/etc/shadow
/etc/sudoers
/etc/ssh/ssh_host_rsa_key
$HOME/.ssh/id_rsa

1
J'aime la deuxième partie. Nous devons nous abstenir d'utiliser less comme commande sudo.
Err0rr

1
Il n'y a aucune différence entre le changement de variable et le changement de modèle si le changement est au même endroit. L'utilisation de la variable la rend seulement moins lisible. Si vous avez vraiment besoin d'utiliser la variable, nommez-la mieux et liste des hachages,
Jiri Klouda

1

d'abord

vous devez vous référer à la gestion Jinja des espaces / sauts de ligne. votre modèle actuel créerait de nouvelles lignes, et je pense que cela confondra sudoet échouera la validation de la syntaxe (IIRC, la bonne syntaxe est d'ajouter -comme: -%}à la boucle for, mais vous devriez "jouer" et voir ce qui se passe). Pour rendre un modèle, vous pouvez le faire sur votre poste de travail, sans l'exécuter sur la machine cible réelle.

De plus, je pense que la création du modèle avec 1 commande sur la ligne d'instructions est plus lisible:

{% for command in commands %}
%{{group}} ALL=(ALL) NOPASSWD: {{command}}
{% endfor %}

Deuxièmement

Je ne recommande pas de modifier les fichiers globaux existants avec ansible. Créez plutôt votre modèle personnalisé sous /etc/sudoers.d/(comme vous l'avez mentionné, vous l'avez vu).

C'est la bonne façon de procéder, car:

  • le système aura tous les paramètres par défaut tels quels.
  • votre modèle sera beaucoup plus court.
  • si vous faites des erreurs, vous serez sûr de savoir où chercher - dans votre modèle.

Troisièmement

Je pense que l'exécution à l' whichintérieur sudoersest une idée originale, mais ne devrait pas fonctionner.


1
en effet, j'ai reçu un message d'erreur de syntaxe. J'examinerai la syntaxe. Et bien sûr, j'ai créé un fichier séparé pour cela.
Err0rr
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.