Как указать пароль sudo для Ansible неинтерактивным способом?
Я использую Ansible playbook следующим образом:
$ ansible-playbook playbook.yml -i inventory.ini \
--user=username --ask-sudo-pass
Но я хочу запустить это так:
$ ansible-playbook playbook.yml -i inventory.ini \
--user=username' **--sudo-pass=12345**
Есть ли способ? Я хочу максимально автоматизировать развертывание моего проекта.
Вы можете передать переменную в командной строке через --extra-vars "name=value". Судовая парольная переменная ansible_sudo_pass. Таким образом, ваша команда будет выглядеть так:
ansible-playbook playbook.yml -i inventory.ini --user=username \
--extra-vars "ansible_sudo_pass=yourPassword"
Обновление 2017: Ansible 2.2.1.0 теперь использует var ansible_become_pass. Кажется, что работает.
Документы strong рекомендуют не устанавливать пароль sudo в открытый текст и вместо этого использовать --ask-sudo-pass в команде при запуске ansible-playbook
Обновление 2016:
Ansible 2.0 (не 100%, когда) отмечен --ask-sudo-pass как устаревший. Документы теперь рекомендуют использовать --ask-become-pass вместо этого, а также заменять использование sudo на всех ваших плейерах с помощью become.
Вероятно, лучший способ сделать это - если вы не можете использовать решение NOPASSWD, предоставляемое scottod, - это использовать решение Mircea Vutcovici в сочетании с Ansible vault.
Например, у вас может быть что-то вроде этой книги:
- hosts: all
vars_files:
- secret
tasks:
- name: Do something as sudo
service: name=nginx state=restarted
sudo: yes
Здесь мы включаем файл с именем secret, который будет содержать наш пароль sudo.
Мы будем использовать безопасное хранилище для создания зашифрованной версии этого файла:
ansible-vault create secret
Это попросит вас ввести пароль, затем откройте редактор по умолчанию, чтобы отредактировать файл. Вы можете разместить здесь ansible_sudo_pass.
например: secret:
ansible_sudo_pass: mysudopassword
Сохраните и выйдите, теперь у вас есть зашифрованный secret файл, который Ansible может расшифровать при запуске вашей пьесы. Примечание: вы можете редактировать файл с помощью ansible-vault edit secret (и вводить пароль, который вы использовали при создании файла)
Последняя часть головоломки - предоставить Ansible с --vault-password-file, который он будет использовать для дешифрования вашего файла secret.
Создайте файл с именем vault.txt и вставьте пароль, который вы использовали при создании файла secret. Пароль должен быть строкой, хранящейся как одна строка в файле.
Из Ansible Docs:
.. обеспечить права доступа к файлу, чтобы никто другой не мог получить доступ к вашему ключу и не добавлять ваш ключ к исходному контролю
Наконец: теперь вы можете запустить свою игру с чем-то вроде
ansible-playbook playbook.yml -u someuser -i hosts --sudo --vault-password-file=vault.txt
В приведенном выше примере предполагается следующий макет каталога:
.
|_ playbook.yml
|_ secret
|_ hosts
|_ vault.txt
Подробнее о Ansible Vault вы можете прочитать здесь: https://docs.ansible.com/playbooks_vault.html
Глядя на код (runner/__init__.py), я думаю, вы, вероятно, можете установить его в своем файле инвентаря:
[whatever]
some-host ansible_sudo_pass='foobar'
В конфигурационном файле ansible.cfg тоже есть некоторые положения, но не реализованы прямо сейчас (constants.py).
Я не думаю, что возможно, что вы укажете пароль в флагах, как вы хотите. Возможно, где-то в конфигурациях это можно установить, но это сделало бы использование недоступным в целом безопасным и не рекомендуется.
Одна вещь, которую вы можете сделать, - создать пользователя на целевом компьютере и предоставить им права доступа sudo без пароля для всех команд или ограниченного списка команд.
Если вы запустите sudo visudo и введите строку, как показано ниже, тогда пользовательский "privilegedUser" не должен будет вводить пароль, когда они запускают что-то вроде sudo service xxxx start:
%privilegedUser ALL= NOPASSWD: /usr/bin/service
Пароль sudo сохраняется как переменная с именем ansible_sudo_pass.
Вы можете установить эту переменную несколькими способами:
На хост в вашем файле хостов инвентаря (inventory/<inventoryname>/hosts)
[server]
10.0.0.0 ansible_sudo_pass=foobar
В группе в вашем файле групп инвентаря (inventory/<inventoryname>/groups)
[server:vars]
ansible_sudo_pass=foobar
В группе, в групповых варах (group_vars/<groupname>/ansible.yml)
ansible_sudo_pass: "foobar"
За группу, зашифрованную (ansible-vault create group_vars/<groupname>/ansible.yml)
ansible_sudo_pass: "foobar"
Вы можете установить пароль для группы или для всех серверов одновременно:
[all:vars]
ansible_sudo_pass=default_sudo_password_for_all_hosts
[group1:vars]
ansible_sudo_pass=default_sudo_password_for_group1
Я отрывал свои волосы от этого, теперь я нашел решение, которое делает то, что я хочу:
1 зашифрованный файл на хост, содержащий пароль sudo
/и т.д./анзибль/хостов:
[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
то вы создаете для каждого хоста зашифрованный var файл следующим образом:
ansible-vault create /etc/ansible/host_vars/node-0
с контентом
ansible_sudo_pass: "my_sudo_pass_for_host_node-0"
как вы организуете пароль хранилища (введите через -ask-vault-pass) или cfg зависит от вас
на основе этого, я подозреваю, вы можете просто зашифровать весь файл хостов...
Более разумный способ сделать это - сохранить свой пароль sudo в безопасном хранилище, таком как LastPass или KeePass, а затем передать его в ansible-playbook используя [email protected] но вместо [email protected] содержимого в реальном файле вы можете использовать конструкция [email protected]<(...) для запуска команды в под-оболочке и перенаправления ее вывода (STDOUT) на анонимный файловый дескриптор, эффективно [email protected]<(..) пароль на [email protected]<(..),
$ ansible-playbook -i /tmp/hosts pb.yml \
[email protected]<(echo "ansible_sudo_pass: $(lpass show folder1/item1 --password)")
Выше делает несколько вещей, пусть разбить его.
ansible-playbook -i/tmp/hosts pb.yml - очевидно, запускает playbook через ansible-playbook$(lpass show folder1/item1 --password)" - запускает lpass LastPass CLI и получает пароль для использованияecho "ansible_sudo_pass:...password..." - берет строку 'ansible_sudo_pass:' и объединяет ее с паролем, предоставленным lpass[email protected]<(..) - объединяет вышеперечисленное и соединяет подоболочку <(...) как дескриптор файла для использования в ansible-playbook. Если вы не хотите вводить это каждый раз, вы можете просто делать такие вещи. Сначала создайте псевдоним в вашем .bashrc следующим образом:
$ cat ~/.bashrc
alias asp='echo "ansible_sudo_pass: $(lpass show folder1/item1 --password)"'
Теперь вы можете запустить свой playbook следующим образом:
$ ansible-playbook -i /tmp/hosts pb.yml [email protected]<(asp)
Если вы можете хранить пароли в текстовых файлах, другой вариант - использовать файл JSON с параметром --extra-vars (обязательно исключите этот файл из системы контроля версий):
ansible-playbook --extra-vars "@private_vars.json" playbook.yml
Несколько раз здесь предлагалось Ansible Vault, но я предпочитаю git-crypt для шифрования конфиденциальных файлов в моих книгах. Если вы используете git, чтобы сохранить свои анекдоты, это совсем несложно. Проблема, с которой я столкнулся в ANSIBLE Vault, заключается в том, что я неизбежно сталкиваюсь с зашифрованными копиями файла, с которым хочу работать, и мне приходится расшифровывать его, прежде чем я смогу работать. git-crypt предлагает более приятный рабочий процесс IMO.
Используя это, вы можете поместить свои пароли в .gitattributes в своей .gitattributes и пометить свою книгу как зашифрованный файл в .gitattributes например так:
my_playbook.yml filter=git-crypt diff=git-crypt
Ваша игровая книга будет прозрачно зашифрована на Github. Затем вам просто нужно либо установить ключ шифрования на хосте, который вы используете для запуска ansible, либо следовать инструкциям в документации, чтобы настроить его с помощью gpg.
Хорошие вопросы и ответы по пересылке ключей gpg например, ваш ssh-agent пересылает ключи SSH здесь: https://superuser.com/questions/161973/how-can-i-forward-a-gpg-key-via-ssh-agent.
Вы можете написать пароль sudo для вашей playbook в файле hosts следующим образом:
[host-group-name]
host-name:port ansible_sudo_pass='*your-sudo-password*'
Вы можете использовать утилиту sshpass как sshpass ниже,
$ sshpass -p "your pass" ansible pattern -m module -a args \
-i inventory --ask-sudo-pass
Вы можете использовать ansible vault, которое закодирует ваш пароль в зашифрованном хранилище. После этого вы можете использовать переменную из хранилища в книгах.
Некоторая документация на несанкционированном хранилище:
http://docs.ansible.com/playbooks_vault.html
Мы используем его как хранилище для среды. Для редактирования хранилища у нас есть команда: ansible-vault edit inventories/production/group_vars/all/vault
Если вы хотите вызвать переменную хранилища, вы должны использовать загрузочную книгу с такими параметрами, как: ansible-playbook -s --vault-password-file=~/.ansible_vault.password
Да, мы сохраняем пароль хранилища в локальном каталоге в виде простого текста, но он не более опасен, как пароль для корневого каталога для каждой системы. Пароль root находится внутри файла хранилища, или вы можете использовать его как файл sudoers для своего пользователя/группы.
Я рекомендую использовать файл sudoers на сервере. Вот пример для администратора группы: %admin ALL=(ALL) NOPASSWD:ALL
Просто назовите вашу --extra-vars "become_pass=Password" с помощью --extra-vars "become_pass=Password"
into_pass = ('ansible_become_password', 'ansible_become_pass')
Использование ansible 2.4.1.0 и следующие должны работать:
[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
И просто запустите playbook с этим инвентарем как:
ansible-playbook -i inventory copyTest.yml
Очень просто, и только добавить в файл переменной:
Пример:
$ vim group_vars/all
И добавьте это:
Ansible_connection: ssh
Ansible_ssh_user: rafael
Ansible_ssh_pass: password123
Ansible_become_pass: password123
В вашем инвентаре .ini что-то похожее на:
hostname ansible_ssh_host=ip
[all]
hostname
[all:vars]
ansible_connection=ssh
ansible_ssh_user=root
ansible_ssh_pass=12345
Мы также можем использовать EXPECT BLOCK в недоступном для создания bash и настраивать его в соответствии с вашими потребностями
- 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
Просто дополнение, так что никто больше не переживает раздражение, которое я недавно сделал:
AFAIK, лучшее решение - одно из общих тостов выше. Если имеет смысл статически связать ваши файлы паролей и vars_files вместе, тогда следуйте его шаблону с помощью vars_files (или include_vars). Если вы хотите сохранить их отдельно, вы можете указать содержимое хранилища в командной строке следующим образом:
ansible-playbook --ask-vault-pass [email protected]<PATH_TO_VAULT_FILE> <PLAYBOOK_FILE>
Это очевидно в ретроспективе, но вот ошибки:
Этот кровавый знак @. Если вы оставите его, синтаксический потерпит неудачу тихо, и анзибль-Playbook будет продолжаться, как если бы вы никогда не указали файл в первую очередь.
Вы должны явно импортировать содержимое хранилища либо с помощью командной строки - -e xtra-vars / -e, либо внутри своего кода YAML. --ask-vault-pass ничего не делает сам по себе (кроме того, запрашивает у вас значение, которое может использоваться или не использоваться позже).
Можете ли вы включить ваши "@" и сэкономить час.
Через пять лет я вижу, что это все еще очень актуальная тема. Отчасти зеркальное отражение ответа leucos, который я считаю лучшим в моем случае, с использованием только доступных инструментов (без какой-либо централизованной аутентификации, токенов или чего-либо еще). Это предполагает, что у вас одинаковое имя пользователя и один и тот же открытый ключ на всех серверах. Если вы этого не сделаете, конечно, вам нужно быть более конкретным и добавить соответствующие переменные рядом с хостами:
[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
Добавлять:
myserver_sudo: mysecretpassword
Затем:
ansible-playbook -i inv.ini my_role.yml --ask-vault --extra-vars '@passwd.yml'
По крайней мере, таким образом, вам не нужно писать больше переменных, которые указывают на пароли.
Выше решение @toast38coza работало для меня; просто это sudo: да, в Ansible устарела. Вместо этого используйте становитесь и становитесь_пользователем.
tasks:
- name: Restart apache service
service: name=apache2 state=restarted
become: yes
become_user: root
Мой способ автоматизировать это состоял в том, чтобы использовать переменную окружения и обращаться к ней через --extra-vars="ansible_become_pass='{{ lookup('env', 'ANSIBLE_BECOME_PASS') }}'".
Экспортируйте env var, но избегайте истории bash/shell (добавьте пробел или другие методы). Например.:
export ANSIBLE_BECOME_PASS='<your password>'
Поиск env var при передаче дополнительной переменной ansible_become_pass в ansible-playbook, например:
ansible-playbook playbook.yml -i inventories/dev/hosts.yml -u user --extra-vars="ansible_become_pass='{{ lookup('env', 'ANSIBLE_BECOME_PASS') }}'"
Хорошие альтернативные ответы:
ansible_become_pass. Это прилично. Тем не менее, для параноидальных команд, которым необходимо обмениваться паролями ANSI-хранилищ и выполнять ANSI-игры с индивидуальными учетными записями, они могут использовать пароль общего хранилища, чтобы отменить пароль операционной системы друг друга (кража идентификатора). Возможно, вам нужно доверять своей собственной команде?@ для считывания переменной ansible из дескриптора файла. Избегает истории bash по крайней мере. Не уверен, но мы надеемся, что эхо-оболочка не будет обнаружена в журнале аудита (например, audd).Это сработало для меня... Создан файл /etc/sudoers.d/90-init-users с NOPASSWD
echo "user ALL=(ALL) NOPASSWD:ALL" > 90-init-users
где "пользователь" - ваш идентификатор пользователя.