Modificar arquivo sudoers com modelo de manual ansible


8

Estou tentando criar um arquivo sudoers com modelo ansible. O arquivo sudoers deve se parecer com abaixo:

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

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

O que eu consegui até agora está abaixo:

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

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

O modelo se parece abaixo:

{% 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

Até onde eu sei, o módulo de modelo ansible não tem nada que execute o comando no servidor remoto e imprima a saída, caso contrário, eu estava pensando em alterar o arquivo de modelo para se parecer com abaixo:

{% 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 %}

e a saída será como o que eu queria.

Existe algum outro método que possa torná-lo simples?

BTW eu já verifiquei este post


Gostaria apenas de colocar o caminho completo do comando em seu vars
jdog

Para modificações no sistema, prefiro incluir scripts no bash para executar melhor.
Lord 9/08

Respostas:


5

TL; DR: KISS. Não use menos.

As pessoas geralmente cometem um erro de ansiedade, tentando fazer coisas variáveis ​​que não precisam ser. A menos que haja vários locais onde você define a lista de comandos que o suporte pode acessar, é perfeitamente aceitável colocá-los no arquivo de criação de modelo:

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 mesmo explicitamente, pois você não reutiliza o Cmnd_Alias ​​em nenhum lugar

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

E adicione algumas tarefas como:

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

Você usaria apenas modelos em vez de arquivos, porque mais tarde pode haver alguma variável a ser adicionada a todos ou o nome do grupo pode vir da variável se você receber outra função que crie os grupos.

Se você precisar usar variável, o que você pode fazer é usar uma lista de hashes como esta:

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

Então no modelo:

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

Não é seguro usar / usr / bin / less

Em tudo isso, você não percebeu muita coisa importante e esse é o uso de menos como visualizador. Infelizmente, isso é uma brecha na segurança. Você pode digitar '! Bash' para chamar o bash. E pressionando 'v', você entra no editor com base nas variáveis ​​VISUAL, EDITOR ou LESSEDIT. Então você pode dar a eles '/ bin / cat' e eles sempre podem canalizar o conteúdo para menos eles mesmos. Observe que isso ainda é um problema de segurança, pois alguns arquivos no unix são muito intencionalmente restritos, por exemplo:

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

1
Eu gosto da segunda parte. Deveríamos nos abster de usar menos como comando sudo.
precisa saber é o seguinte

1
Não há diferença zero entre alterar variável e alterar o modelo se a alteração estiver em um único local. O uso da variável a torna apenas menos legível. Se você realmente precisa usar a variável, nomeá-lo melhor e lista de hashes,
Jiri Klouda

1

primeiramente

você deve consultar o manuseio de espaços / novas linhas do Jinja. seu modelo atual criaria novas linhas, e acho que isso confundirá sudoe falhará na validação da sintaxe (IIRC, a sintaxe correta é adicionar -como: -%}no loop for, mas você deve "tocar" e ver o que acontece). Para renderizar um modelo, você pode fazê-lo em sua estação de trabalho, sem executá-lo na máquina de destino real.

Além disso, acho que a criação do modelo com 1 comando na linha de instruções é mais legível:

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

Em segundo lugar

Eu não recomendo editar arquivos globais existentes com ansible. Em vez disso, crie seu modelo personalizado em /etc/sudoers.d/(como você mencionou que viu).

Esta é a maneira correta de fazer isso, porque:

  • o sistema terá todos os padrões como está.
  • seu modelo será muito menor.
  • se cometer erros, você terá certeza de onde procurar - no seu modelo.

Em terceiro lugar

Acho que executar whichdentro sudoersé uma ideia original, mas não deve funcionar.


1
de fato, recebi uma mensagem de erro de sintaxe. Vou analisar a sintaxe. E é claro que eu criei um arquivo separado para isso.
precisa saber é o seguinte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.