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

Я хотел бы использовать выполнимый для управления группой существующих серверов. Я создал файл ansible_hosts и успешно протестировал (с опцией -K) с командами, которые предназначены только для одного хоста

ansible -i ansible_hosts host1 --sudo -K # + commands ...

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

Используя -K, мне будет предложено только один пароль sudo, который, кажется, будет проверен для всех последующих хостов без запроса:

host1 | ...
host2 | FAILED => Incorrect sudo password
host3 | FAILED => Incorrect sudo password
host4 | FAILED => Incorrect sudo password
host5 | FAILED => Incorrect sudo password

Исследования до сих пор:

  • a вопрос StackOverflow с одним неправильным ответом ("use -K ") и один ответ автора:« Обнаружил, что мне нужен пароль без пароля »

  • Ansible docs , который «Использование без пароля sudo упрощает автоматизацию, но не требуется ." (акцент мой)

  • этот вопрос безопасности StackExchange который принимает это как прочитанное, что NOPASSWD требуется

  • article «Масштабируемое и понятное обеспечение. .. ", в котором говорится:

    "при запуске sudo может потребоваться ввести пароль, что является надежным способом блокировки Ansible навсегда. Простое исправление - запустить visudo на целевом хосте и убедиться, что пользователь Ansible будет использовать для входа в систему необходимо ввести пароль "

  • article «Основные невероятные книги» , в котором говорится

    «Ansible может войти в целевой сервер с правами root и избежать необходимости в sudo, или позволить незаменимому пользователю использовать sudo без пароля, но мысль о том, что делает, делает мою селезенку угрозой, чтобы вскочить на мой глоток и заблокируйте мою трубу, так что я не хочу

    Мои мысли в точности, но потом, как выйти за пределы одного сервера?

  • заметная проблема # 1227 , "Ansible должен попросить пароль sudo для все пользователи в playbook », который был закрыт год назад mpdehaan с комментарием« Не видел большого спроса на это, я думаю, что большинство людей предпочитают только одну учетную запись пользователя или большую часть времени используют клавиши ».

Итак ... как люди используют Ansible в подобных ситуациях? Установка NOPASSWD в /etc/sudoers, повторное использование пароля на всех хостах или включение корневого входа в систему SSH все кажется довольно резким снижением безопасности.

92 голоса | спросил supervacuo 9 MonEurope/Moscow2013-12-09T15:49:48+04:00Europe/Moscow12bEurope/MoscowMon, 09 Dec 2013 15:49:48 +0400 2013, 15:49:48

6 ответов


52

Вы, безусловно, сделали свое исследование ...

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

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

  

«Итак ... как люди используют Ansible в таких ситуациях?   NOPASSWD в /etc /sudoers, повторное использование пароля через хосты или включение   root SSH все выглядят довольно резкими сокращениями безопасности ».

Я могу дать вам один взгляд на это. Мой вариант использования - 1 тыс. Узлов в нескольких центрах обработки данных, поддерживающих глобальную фирму SaaS, в которой я должен разработать /внедрить некоторые безумно жесткие средства контроля безопасности из-за характера нашего бизнеса. Безопасность - это всегда балансирующий акт, более удобство использования - меньше, этот процесс ничем не отличается, если вы используете 10 серверов или 1000 или 100 000.

Вы абсолютно правы, чтобы не использовать корневые логины с помощью пароля или ssh-ключей. Фактически, вход в корневой каталог должен быть полностью отключен, если на серверах подключен сетевой кабель.

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

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

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

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

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

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

ответил Zeb 30 MonEurope/Moscow2013-12-30T20:53:18+04:00Europe/Moscow12bEurope/MoscowMon, 30 Dec 2013 20:53:18 +0400 2013, 20:53:18
34

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

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

ответил Daniel Neades 11 Mayam14 2014, 00:32:34
21

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

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

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

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

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

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

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

ответил Alex Dupuy 26 Maypm14 2014, 23:33:57
16

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

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

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

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

ответил fqxp 19 Jpm1000000pmTue, 19 Jan 2016 22:51:35 +030016 2016, 22:51:35
3

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

  • Мы используем две разные системы аутентификации, управление машинами осуществляется с локальных рабочих станций в моей команде.
  • Я написал код vars_plugin для Ansible (довольно полная реализация может быть найдена в https://gist.github.com/mfriedenhagen/e488235d732b7becda81 ), который отличает несколько систем аутентификации:
  • Имя системы аутентификации зависит от группы.
  • Используемый пользователь login /sudo является специфичным для группы и администратора.
  • Таким образом, я вытаскиваю пользователя из среды администратора и соответствующего пароля через библиотеку python-keyring из безопасного пароля (мы используем цепочку ключей Mac OS X, но из документации также поддерживаются kwallet Gnome и _win_crypto).
  • Я устанавливаю разрешения на пароли в цепочке ключей Mac OS X, чтобы уведомить меня о том, что система безопасности командной строки запрашивает доступ к паролю для каждой системы аутентификации, используемой хосты, поэтому я запускаю «ansible -s all -m ping» и получаю два приглашения (по одному для каждой системы аутентификации), где я нажимаю клавишу пробела и недоступен, забирает пароли.
ответил Mirko Friedenhagen 3 MarpmTue, 03 Mar 2015 20:33:56 +03002015-03-03T20:33:56+03:0008 2015, 20:33:56
0

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

например.

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

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

lookup('env', 'pass1') 
lookup('env', 'pass2') 
ответил Paul Calabro 21 J000000Friday17 2017, 11:57:21

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132