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


Я хотел бы использовать анзибль для управления группой существующих серверов. Я создал 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

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

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

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

  • этот вопрос безопасности StackExchange который гласит, что NOPASSWD необходимо

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

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

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

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

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

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

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


92
2017-12-09 11:49


Источник


Есть ли причина, по которой вы не используете SSH-ключи? - Trondh
Я уже использую ключи SSH; они не влияют sudo (который по-прежнему требует пароль). - supervacuo
Это может быть не совсем то, что вы ищете, но в ящиках Ubuntu я все еще использую ключи, т. Е. Вставляя свой открытый ключ в / root / authorized_keys напрямую, как root. Очевидный недостаток позволяет корневым входам через ssh ... Я также запрещаю вход в пароли через ssh и запускаю fail2ban для дополнительной безопасности. - senorsmile
Спасибо за ответ! Не могли бы вы вместо этого ответить на этот вопрос, чтобы я мог спустить вас за то, что вы не читали вопрос? - supervacuo
то есть  ansible_ssh_password настройка применяется только к паролю SSH (ключ находится в имени ...). & Я уже пользуюсь ключом SSH для входа в систему. - supervacuo


Ответы:


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

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

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

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

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

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

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

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

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

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

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

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


52
2017-12-30 16:53



Спасибо, @Zeb - я подумал, что пользователи с десятками-тысячами серверов будут использовать NOPASSWD в любом случае, по причинам здравомыслия (возможно, поддерживается более жесткими правилами брандмауэра и т.п.), но хорошо прочитать ваш прецедент и мысли о модели угрозы. - supervacuo
Один комментарий, тем не менее, к вашему предложению об ограничении «предварительно одобренных», sudo (что произошло со мной, когда я обнаружил, что NOPASSWD в значительной степени требуется). К сожалению, это кажется полностью не поддерживается - вопрос не дает никаких обещаний о вызове например  chown или mkdir напрямую, и должен иметь возможность sudo /bin/sh для большинства модулей. - supervacuo
Кажется, я вспоминаю, как один из моих инженеров жаловался на это некоторое время назад, это раздражает. - Zeb


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

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


34
2018-05-10 20:32



ansible_sudo_pass вариант кажется новым тоже - и, похоже, делает то, о чем я просил. Один пароль для хранилища идеален для моих целей. Благодаря! - supervacuo
Есть ли способ избежать шифрования все  host_vars используя этот метод? (потенциальное ограничение, отмеченное Алексом Дюпюем) - supervacuo
@supervacuo. Чтобы избежать шифрования всех хостов-хостов, просто используйте каталог хоста var, содержащий main.yml (незашифрованный) и secret.yml (зашифрованный) - см. последнюю часть этот раздел документа где он говорит о группе «ролей» - та же техника работает для хостов-варов и групповых варов. Я использую это много, единственный вариант заключается в том, что если секрет необходим только для некоторых игровых автоматов, может быть полезно сохранить его в другом дереве целиком и включить через путь, включающий имя хоста или var. - RichVel


С помощью 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" для предоставления паролей для развертывание удаленный пользователь (который тогда необходим для Судо), поэтому они уже присутствуют в файлах (хотя выполнение этих поисков открытого текста теряет значение соли хранится в файле, когда генерируется хешированное значение).

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

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

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


21
2018-05-26 19:33



я в конце концов (спасибо!), но не вижу, как это будет работать без git-crypt; насколько я вижу. Это похоже на Ansible пока не поддерживает для использования lookup в зашифрованном хранилище. password модульные документы скажем, что есть некоторая недокументированная поддержка зашифрованного хранилища, но я еще не нашел деталей. Любые подсказки? - supervacuo


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

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

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

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


16
2018-01-19 19:51



Такое превосходное решение - спасибо! - Leng


Это довольно старая нить, тем не менее:

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

3
2018-03-03 17:33



Это выглядит очень аккуратно, спасибо. Мне нравится идея не хранить пароли в двух местах. На данный момент я застрял, используя KeepassX (потому что GNOME keyring не кажется очень портативным), но, возможно, я могу сделать python-keepass Работа? - supervacuo
Насколько я понимаю, python-keyring является абстракцией для этого, поэтому ваши коллеги могут использовать другие ОС. Или вы храните свой бит keepassx на USB-накопителе и должны администрироваться с рабочих станций с различными ОС? - Mirko Friedenhagen
понимать; Я имел в виду, что мне уже нужно использовать KeepassX для доступа к паролям в системах, отличных от GNOME, поэтому их хранение в gnome-keyring будет означать сохранение повторяющихся записей. Еще лучше, чем использовать NOPASSWD, хоть… - supervacuo


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

например

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

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

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

0
2017-07-21 08:57