Как я могу реализовать ansible с паролями на хост, надежно?

Вы определенно провели свое исследование ...

Судя по моему опыту работы с анзиблем, то, что вы хотите достичь, не поддерживается. Как вы упомянули, в ansible указано, что для него не требуется sudo без пароля, и вы правы, это не так. Но мне еще предстоит увидеть какой-либо метод использования нескольких паролей sudo в ansible, конечно, без запуска нескольких конфигураций.

Итак, я не могу предложить точное решение, которое вы ищете, но вы спросили ...

«Итак ... как люди используют Ansible в подобных ситуациях? NOPASSWD в / etc / sudoers, повторное использование пароля на хостах или включение но мои администраторы / инженеры взбунтовались бы, если бы у них были разные пароли на 1000 узлов. Реализовать это также было бы почти невозможно, каждый пользователь должен был бы где-то хранить свои собственные пароли, надеюсь, пароль, а не электронную таблицу. И каждый раз, когда вы помещаете пароль в место, откуда его можно вывести в виде обычного текста, вы значительно снижаете свою безопасность. Я бы предпочел, чтобы они знали наизусть один или два действительно надежных пароля, чем обращались к файлу keypass каждый раз, когда им нужно было войти в систему или вызвать sudo на машине.

Таким образом, повторное использование паролей и стандартизация - это то, что полностью приемлемо и стандартно даже в безопасной среде. В противном случае не было бы необходимости в ldap, keystone и других службах каталогов.

Когда мы переходим к автоматизированным пользователям, ключи ssh отлично помогают вам, но вам все равно нужно пройти через sudo. Ваш выбор: стандартный пароль для автоматического пользователя (что во многих случаях приемлемо) или включение NOPASSWD, как вы указали. Большинство автоматизированных пользователей выполняют только несколько команд, поэтому вполне возможно и, безусловно, желательно включить NOPASSWD, но только для предварительно утвержденных команд. Я бы предложил использовать ваше управление конфигурацией (в данном случае доступное) для управления файлом sudoers, чтобы вы могли легко обновить список команд без пароля.

Теперь есть несколько шагов, которые вы можете предпринять после начала масштабирования, чтобы еще больше изолировать риски. Хотя у нас около 1000 узлов, не все из них являются «производственными» серверами, некоторые - тестовыми средами и т. Д. Не все администраторы могут получить доступ к производственным серверам, хотя те, которые могут использовать тот же пользовательский / пароль | ключ единого входа, что и в других местах . Но автоматизированные пользователи немного более безопасны, например, автоматизированный инструмент, к которому могут получить доступ непроизводственные администраторы, имеет пользователя и учетные данные, которые нельзя использовать в производственной среде. Если вы хотите запустить ansible на всех узлах, вам придется сделать это двумя партиями: один раз для непроизводственного и один раз для производственного.

Мы также используем марионетку, поскольку это принудительный инструмент управления конфигурацией, поэтому большинство изменений во всех средах будут вытеснены через него.

Очевидно, что если указанный вами запрос функции будет повторно открыт / завершен, то, что вы хотите сделать, будет полностью поддерживаться. Даже в этом случае безопасность - это процесс оценки риска и компромисса. Если у вас есть только несколько узлов, для которых вы можете запомнить пароли, не прибегая к заметкам, отдельные пароли будут немного более безопасными. Но для большинства из нас это невыполнимый вариант.

Начиная с Ansible 1.5, можно использовать зашифрованное хранилище для host_vars и других переменных. Это, по крайней мере, позволяет вам безопасно хранить переменную ansible_sudo_pass для каждого хоста (или группы). К сожалению, - ask-vault-pass будет запрашивать только один пароль хранилища на один доступный вызов, поэтому вы по-прежнему ограничены одним паролем хранилища для всех хостов, которые вы будете использовать вместе.

Тем не менее, для некоторых применений это может быть улучшением по сравнению с использованием одного пароля sudo на нескольких хостах, поскольку злоумышленнику без доступа к вашим зашифрованным host_vars по-прежнему потребуется отдельный пароль sudo для каждой машины (или группы машин), которую он или она атакует.

В Ansible 1.5 можно установить переменную ansible_sudo_pass , используя поиск ('пароль',…) :

ansible_sudo_pass: "{{ lookup('password', 'passwords/' + inventory_hostname) }}"

Я нахожу это удобнее, чем использование файлов в host_vars / по нескольким причинам:

• Я действительно использую with_password: "passwords / {{inventory_hostname}} encrypt = sha256_crypt" для обеспечения паролей для удаленного пользователя deploy (который затем необходим для sudo ), так они уже присутствуют в файлах (хотя выполнение этих поисков в открытом тексте теряет солидную ценность сохраняются в файле при генерации хешированного значения).

• Это сохраняет только пароли в файле (нет ansible_sudo_pass: известного открытого текста) для некоторого эпсилонского повышения криптографической безопасности. Что еще более важно, это означает, что вы не шифруете все другие переменные, специфичные для хоста, поэтому их можно читать без пароля хранилища.

• Помещение паролей в отдельный каталог упрощает сохранение файлов вне системы контроля версий или использование такого инструмента, как git-crypt , для их хранения в зашифрованном виде (вы можете использовать это с более ранней версией Ansible, в которой отсутствует функция хранилища). Я использую git-crypt, и, поскольку я проверяю репозиторий только в расшифрованном виде в зашифрованных файловых системах, я не беспокоюсь о хранилище и, следовательно, мне не нужно вводить пароль хранилища. (Использование обоих, конечно, было бы более безопасно.)

Вы также можете использовать функцию lookup с ansible_ssh_pass ; это может быть возможно даже с более ранними версиями Ansible, в которых нет ansible_sudo_pass .

Тем не менее, это довольно старый поток:

• Мы используем две разные системы аутентификации внутри компании, управление машинами осуществляется с локальных рабочих станций в моей команде.
• Я написал vars_plugin для Ansible (довольно полную реализацию можно найти на https: //gist.github.com / mfriedenhagen / e488235d732b7becda81 ), который различает несколько систем аутентификации:
• Имя системы аутентификации зависит от группы.
• Используемый пользователь входа / sudo зависит от группы и администратора.
• Итак, я извлекаю пользователь из среды администратора и соответствующий пароль через библиотеку python-keyring из сейфа с паролями (мы используем связку ключей Mac OS X, но из документации также поддерживаются kwallet Gnome и _win_crypto).
• Я установил разрешения для паролей в связке ключей Mac OS X, чтобы уведомить меня о том, что защита программы командной строки запрашивает доступ к паролю для каждой системы аутентификации, используемой хосты, поэтому я запускаю "ansible -s all -m ping" и получаю два приглашения (по одному для каждой системы аутентификации), где я нажимаю пробел, и ansible берет пароли.

Использование прохода - это простой метод для предоставления доступа с паролями sudo. pass хранит один пароль для каждого файла, что упрощает обмен паролями через git или другие методы. Это также безопасно (с использованием GnuPG), и если вы используете gpg-agent, он позволяет вам использовать ansible без ввода пароля при каждом использовании.

Чтобы предоставить пароль, хранящийся как servers / foo для сервера foo для доступа, используйте его в файле инвентаризации следующим образом:

[servers]
foo ansible_sudo=True \
    ansible_sudo_pass="{{ lookup('pipe', 'pass servers/foo') }}"

Учитывая, что вы ранее разблокировали ключ для gpg-agent,это запустит ansible без необходимости вводить пароль.

Один из возможных способов сделать это - использовать переменные окружения.

например

pass1=foo pass2=bar ansible-playbook -i production servers.xml

Затем в играх вы можете найти пароль sudo, используя:

lookup('env', 'pass1') 
lookup('env', 'pass2') 

Кто опаздывает сюда: ср. https://stackoverflow.com/a/37002802

Per host, in your inventory hosts file (inventory/<inventoryname>/hosts)
[server]
10.0.0.0 ansible_sudo_pass=foobar

Per group, in your inventory groups file (inventory/<inventoryname>/groups)
[server:vars]
ansible_sudo_pass=foobar

Per group, in group vars (group_vars/<groupname>/ansible.yml) and encrypted (ansible-vault create group_vars/<groupname>/ansible.yml)
ansible_sudo_pass: "foobar"

Это вполне возможно. Вы можете определить свой инвентарь для использования переменных для таких вещей, как пароли:

ИНВЕНТАРЬ:

[023_mqtt]
023-softbank-mqtt01 ansible_host=IP.IP.IP.IP ansible_ssh_private_key_file=/path/to/my_key ansible_ssh_user=my_user ansible_become=yes ansible_become_method=sudo ansible_become_pass='{{ my_user_pass }}'

Вам понадобится файл group_vars / 023_mqtt.yaml, в котором находится ваш инвентарь, если вы используете сервер перехода (если он вам нужен):

ansible_ssh_common_args: '-o ProxyCommand="ssh -i /path/to/your/jump_key -W %h:%p -q you_jump_user@IP.IP.IP.IP"'

Наконец, вы определяете хранилище для хранения ваших паролей. Желательно создать его в той же папке, что и ваш файл инвентаризации:

ansible-vault create passwds.yaml
[enter a vault pass]

Добавьте пароли:

my_user : 'my_user's sudo password'

Чтобы запустить это, передайте хранилище как дополнительные переменные:

 ansible -a "docker ps" -i /path/to/hosts hosts_group --ask-vault-pass --extra-vars '@passwd.yaml'

У меня это определено для нескольких хостов, каждый со своим собственным SSH ключ, парольную фразу SSH и пароль SSH SUDO, и он отлично работает. Полную версию статьи можно найти в моем git:

https://github.com/flow0787/ansible/blob/master/README.md