Especifique a senha do sudo para Ansible

Como especifico uma senha do sudo para o Ansible de maneira não interativa?

Estou executando o manual do Ansible assim:

$ ansible-playbook playbook.yml -i inventory.ini \
    --user=username --ask-sudo-pass

Mas eu quero executá-lo assim:

$ ansible-playbook playbook.yml -i inventory.ini \
    --user=username` **--sudo-pass=12345**

Há algum jeito? Quero automatizar o máximo possível a implantação do meu projeto.

Você pode passar variáveis ​​na linha de comando via --extra-vars "name=value". A variável de senha do Sudo é ansible_sudo_pass. Portanto, seu comando seria semelhante a:

ansible-playbook playbook.yml -i inventory.ini --user=username \
                              --extra-vars "ansible_sudo_pass=yourPassword"

Atualização 2017 : O Ansible 2.2.1.0 agora usa var ansible_become_pass. Qualquer um parece funcionar.

Os documentos recomendam enfaticamente não definir a senha do sudo em texto sem formatação e usá-la --ask-sudo-passna linha de comando ao executaransible-playbook

Atualização de 2016:

Ansible 2.0 (não 100% quando) marcado --ask-sudo-passcomo obsoleto. Agora, os documentos recomendam o uso --ask-become-pass, além de trocar o uso sudopelos manuais become.

Provavelmente, a melhor maneira de fazer isso - supondo que você não possa usar a solução NOPASSWD fornecida pela scottod é usar a solução de Mircea Vutcovici em combinação com o Ansible Vault .

Por exemplo, você pode ter um manual assim:

- hosts: all

  vars_files:
    - secret

  tasks:
    - name: Do something as sudo
      service: name=nginx state=restarted
      sudo: yes

Aqui estamos incluindo um arquivo chamado secret que conterá nossa senha sudo.

Usaremos o ansible-vault para criar uma versão criptografada deste arquivo:

ansible-vault create secret

Isso solicitará uma senha e abra seu editor padrão para editar o arquivo. Você pode colocar o seu ansible_sudo_passaqui.

por exemplo secret:

ansible_sudo_pass: mysudopassword

Salve e saia, agora você tem um secretarquivo criptografado que o Ansible pode descriptografar quando você executa o seu manual. Nota: você pode editar o arquivo com ansible-vault edit secret(e inserir a senha usada ao criar o arquivo)

A peça final do quebra-cabeça é fornecer ao Ansible um --vault-password-fileque ele usará para descriptografar seu secretarquivo.

Crie um arquivo chamado vault.txte coloque a senha que você usou ao criar seusecret arquivo. A senha deve ser uma sequência armazenada como uma única linha no arquivo.

Dos Documentos Ansible:

.. garantir que as permissões no arquivo sejam tais que ninguém mais possa acessar sua chave e não a adicione ao controle de origem

Por fim: agora você pode executar seu playbook com algo como

ansible-playbook playbook.yml -u someuser -i hosts --sudo --vault-password-file=vault.txt 

O acima está assumindo o seguinte layout de diretório:

.
|_ playbook.yml
|_ secret
|_ hosts
|_ vault.txt

Você pode ler mais sobre o Ansible Vault aqui: https://docs.ansible.com/playbooks_vault.html

Olhando para o código ( runner/__init__.py), acho que você provavelmente pode configurá-lo no seu arquivo de inventário:

[whatever]
some-host ansible_sudo_pass='foobar'

Parece haver alguma provisão no ansible.cfgarquivo de configuração também, mas não implementada agora ( constants.py).

Eu não acho que o ansible permitirá que você especifique uma senha nos sinalizadores como deseja. Pode haver algum lugar nas configurações que pode ser definido, mas isso tornaria o uso do ansible menos seguro em geral e não seria recomendado.

Uma coisa que você pode fazer é criar um usuário na máquina de destino e conceder a ele privilégios sudo sem senha para todos os comandos ou uma lista restrita de comandos.

Se você executar sudo visudoe digitar uma linha como a abaixo, o usuário 'privilegedUser' não precisará digitar uma senha quando executar algo como sudo service xxxx start:

%privilegedUser ALL= NOPASSWD: /usr/bin/service

A senha do sudo é armazenada como uma variável chamada ansible_sudo_pass. Você pode definir esta variável de algumas maneiras:

Por host, no arquivo de hosts do seu inventário ( inventory/<inventoryname>/hosts)

[server]
10.0.0.0 ansible_sudo_pass=foobar

Por grupo, no seu arquivo de grupos de inventário ( inventory/<inventoryname>/groups)

[server:vars]
ansible_sudo_pass=foobar

Por grupo, em vars de grupo ( group_vars/<groupname>/ansible.yml)

ansible_sudo_pass: "foobar"

Por grupo, criptografado ( ansible-vault create group_vars/<groupname>/ansible.yml)

ansible_sudo_pass: "foobar"

Você pode definir a senha para um grupo ou para todos os servidores de uma vez:

[all:vars]
ansible_sudo_pass=default_sudo_password_for_all_hosts

[group1:vars]
ansible_sudo_pass=default_sudo_password_for_group1

Eu estava arrancando meu cabelo com esse, agora encontrei uma solução que faz o que eu quero:

1 arquivo criptografado por host que contém a senha do sudo

/ etc / ansible / hosts:

[all:vars]
ansible_ssh_connection=ssh ansible_ssh_user=myuser ansible_ssh_private_key_file=~/.ssh/id_rsa

[some_service_group]
node-0
node-1

então você cria para cada host um arquivo var criptografado da seguinte forma:

ansible-vault create /etc/ansible/host_vars/node-0

com conteúdo

ansible_sudo_pass: "my_sudo_pass_for_host_node-0"

como você organiza a senha do cofre (digite via --ask-vault-pass) ou por cfg é com você

com base nisso, suspeito que você pode criptografar todo o arquivo hosts ...

Uma maneira mais inteligente de fazer isso é armazenar sua sudosenha em um cofre seguro, como LastPass ou KeePass, e depois passá-la para o ansible-playbookuso de, -e@mas em vez de codificar o conteúdo em um arquivo real, você pode usar a construção -e@<(...)para executar um comando em um sub-shell e redirecione sua saída (STDOUT) para um descritor de arquivo anônimo, alimentando efetivamente a senha para o -e@<(..).

Exemplo

$ ansible-playbook -i /tmp/hosts pb.yml \
   -e@<(echo "ansible_sudo_pass: $(lpass show folder1/item1 --password)")

O acima está fazendo várias coisas, vamos dividir.

• ansible-playbook -i /tmp/hosts pb.yml - obviamente, executando um manual via ansible-playbook
• $(lpass show folder1/item1 --password)"- executa a CLI LastPass lpasse recupera a senha para usar
• echo "ansible_sudo_pass: ...password..." - pega a string 'ansible_sudo_pass:' e a combina com a senha fornecida por lpass
• -e@<(..)- reúne o que foi dito acima e conecta o subshell de <(...)como um descritor de arquivo para ansible-playbookconsumo.

Outras melhorias

Se você preferir não digitar isso toda vez, pode simplesmente coisas assim. Primeiro, crie um alias .bashrccomo você gosta:

$ cat ~/.bashrc
alias asp='echo "ansible_sudo_pass: $(lpass show folder1/item1 --password)"'

Agora você pode executar seu playbook assim:

$ ansible-playbook -i /tmp/hosts pb.yml -e@<(asp)

Referências

• https://docs.ansible.com/ansible/2.4/ansible-playbook.html#cmdoption-ansible-playbook-e

Se você se sente confortável em manter senhas em arquivos de texto sem formatação, outra opção é usar um arquivo JSON com o parâmetro --extra-vars (certifique-se de excluir o arquivo do controle de origem):

ansible-playbook --extra-vars "@private_vars.json" playbook.yml 

O Ansible suporta esta opção desde a versão 1.3 .

você pode escrever a senha do sudo para o seu playbook no arquivo hosts assim:

[host-group-name]
host-name:port ansible_sudo_pass='*your-sudo-password*'

O cofre Ansible foi sugerido algumas vezes aqui, mas eu prefiro o git-crypt para criptografar arquivos confidenciais nos meus playbooks. Se você estiver usando o git para manter seus playbooks ansíveis, é fácil. O problema que encontrei no cofre ansible é que, inevitavelmente, acabo encontrando cópias criptografadas do arquivo com o qual quero trabalhar e preciso descriptografá-lo antes de poder trabalhar. git-cryptoferece um melhor fluxo de trabalho IMO.

• https://github.com/AGWA/git-crypt

Com isso, você pode colocar suas senhas em um var no seu playbook e marcá-lo como um arquivo criptografado da .gitattributesseguinte maneira:

 my_playbook.yml filter=git-crypt diff=git-crypt

Seu manual será criptografado de forma transparente no Github. Então você só precisa instalar sua chave de criptografia no host usado para executar o ansible ou seguir as instruções na documentação para configurá-la gpg.

Há boas perguntas e respostas sobre o encaminhamento de gpgchaves como as ssh-agentchaves SSH de encaminhamento aqui: /superuser/161973/how-can-i-forward-a-gpg-key-via-ssh-agent .

Você pode usar o sshpassutilitário como abaixo,

$ sshpass -p "your pass" ansible pattern -m module -a args \
   -i inventory --ask-sudo-pass

O uso do ansible 2.4.1.0 e o seguinte devem funcionar:

[all]
17.26.131.10
17.26.131.11
17.26.131.12
17.26.131.13
17.26.131.14

[all:vars]
ansible_connection=ssh
ansible_user=per
ansible_ssh_pass=per
ansible_sudo_pass=per

E basta executar o manual com este inventário como:

ansible-playbook -i inventory copyTest.yml

Meu truque para automatizar isso era usar uma variável de ambiente e acessá-la via --extra-vars="ansible_become_pass='{{ lookup('env', 'ANSIBLE_BECOME_PASS') }}'".

Exporte uma var env, mas evite o histórico do bash / shell (inclua um espaço ou outros métodos). Por exemplo:

     export ANSIBLE_BECOME_PASS='<your password>'

Pesquise a var env ao passar a ansible_become_passvariável extra para ansible-playbook, por exemplo:

ansible-playbook playbook.yml -i inventories/dev/hosts.yml -u user --extra-vars="ansible_become_pass='{{ lookup('env', 'ANSIBLE_BECOME_PASS') }}'"

Boas respostas alternativas:

• @ toast38coza: basta usar um valor abobadado paraansible_become_pass . Isso é decente. No entanto, para as equipes paranóicas que precisam compartilhar senhas do cofre ansible e executar execuções ansible com contas individuais, elas podem usar a senha do cofre compartilhado para reverter a senha do sistema operacional (roubo de identidade). Indiscutivelmente, você precisa confiar em sua própria equipe?
• A saída do subshell bash@ do @ slm gerada para o descritor de arquivo temporário e usando o prefixo para ler a variável ansible do descritor de arquivo . Evita pelo menos o histórico do bash. Não tenho certeza, mas espero que o eco do subshell não seja capturado e exposto no log de auditoria (por exemplo, auditd).

Você pode usar o cofre ansible, que codificará sua senha no cofre criptografado. Depois disso, você pode usar a variável from vault nos playbooks.

Alguma documentação sobre o ansible vault:
http://docs.ansible.com/playbooks_vault.html

Estamos usando-o como cofre por ambiente. Para editar o vault, temos o comando como:
ansible-vault edit inventories/production/group_vars/all/vault

Se você quiser chamar a variável do vault, precisará usar o ansible-playbook com parâmetros como:
ansible-playbook -s --vault-password-file=~/.ansible_vault.password

Sim, estamos armazenando a senha do cofre no diretório local em texto simples, mas não é mais perigoso, como armazenar a senha raiz de todos os sistemas. A senha raiz está dentro do arquivo do Vault ou você pode tê-lo como um arquivo sudoers para o seu usuário / grupo.

Eu estou recomendando usar o arquivo sudoers no servidor. Aqui está um exemplo para o administrador do grupo:
%admin ALL=(ALL) NOPASSWD:ALL

Basta ligar para o seu manual com --extra-vars "become_pass=Password"

torne-se_pass = ('ansible_become_password', 'ansible_become_pass')

Depois de cinco anos, vejo que esse ainda é um assunto muito relevante. Um tanto espelhando a resposta de leucos que eu acho melhor no meu caso, usando apenas ferramentas ansible (sem autenticação centralizada, tokens ou qualquer outra coisa). Isso pressupõe que você tenha o mesmo nome de usuário e a mesma chave pública em todos os servidores. Caso contrário, é claro que você precisará ser mais específico e adicionar as variáveis ​​correspondentes ao lado dos hosts:

[all:vars]
ansible_ssh_user=ansible
ansible_ssh_private_key_file=home/user/.ssh/mykey
[group]
192.168.0.50 ansible_sudo_pass='{{ myserver_sudo }}'

ansible-vault create mypasswd.yml
ansible-vault edit mypasswd.yml

Adicionar:

myserver_sudo: mysecretpassword

Então:

ansible-playbook -i inv.ini my_role.yml --ask-vault --extra-vars '@passwd.yml'

Pelo menos desta forma, você não precisa escrever mais as variáveis ​​que apontam para as senhas.

A solução acima de @ toast38coza funcionou para mim; apenas esse sudo: yes está obsoleto no Ansible agora. Use torne - se e torne - se_usuário .

tasks:
 - name: Restart apache service
   service: name=apache2 state=restarted
   become: yes
   become_user: root

nós também podemos usar o EXPECT BLOCK no ansible para gerar bash e personalizá-lo conforme suas necessidades

- name: Run expect to INSTALL TA
  shell: |
    set timeout 100
    spawn /bin/sh -i

    expect -re "$ "
    send "sudo yum remove -y xyz\n"

    expect "$ "
    send "sudo yum localinstall -y {{ rpm_remotehost_path_for_xyz }}\n"

    expect "~]$ "
    send "\n"

    exit 0
  args:
  executable: /usr/bin/expect

Muito simples e adicione apenas no arquivo variável:

Exemplo:

$ vim group_vars/all

E adicione estes:

Ansible_connection: ssh
Ansible_ssh_user: rafael
Ansible_ssh_pass: password123
Ansible_become_pass: password123

Apenas um adendo, para que ninguém mais passe pelo aborrecimento que fiz recentemente:

AFAIK, a melhor solução é uma das linhas gerais de toast38coza's acima. Se fizer sentido vincular seus arquivos de senha e seu manual estaticamente, siga o modelo dele com vars_files(ou include_vars). Se você deseja mantê-los separados, é possível fornecer o conteúdo do cofre na linha de comando da seguinte maneira:

ansible-playbook --ask-vault-pass -e@<PATH_TO_VAULT_FILE> <PLAYBOOK_FILE>

Isso é óbvio em retrospecto, mas aqui estão as dicas:

1. Aquele maldito sinal @ . Se você deixar de fora, a análise falhará silenciosamente e o ansible-playbook continuará como se você nunca tivesse especificado o arquivo em primeiro lugar.

2. Você deve importar explicitamente o conteúdo do cofre, com uma linha de comando --extra-vars / -e ou dentro do seu código YAML. O --ask-vault-passsinalizador não faz nada por si só (além de solicitar um valor que pode ou não ser usado posteriormente).

Você pode incluir seus "@" se economizar uma hora.

Isso funcionou para mim ... Arquivo criado /etc/sudoers.d/90-init-users arquivo com NOPASSWD

echo "user ALL=(ALL)       NOPASSWD:ALL" > 90-init-users

onde "usuário" é o seu ID do usuário.