У меня есть ansible playbook, который я хотел бы разрешить обычному пользователю запускать для установки приложения на сервере centos, но я не обязательно хочу давать ему учетные данные для входа. Я знаю, что вы можете использовать ansible vault для хранения зашифрованных данных, но насколько я могу судить, вы также можете довольно легко расшифровать эти данные. Есть идеи, возможно ли это и как этого добиться?
решение1
Большинство методов установки программного обеспечения требуют наличия прав привилегированного пользователя.
Принципы наименьших привилегий и ответственности подразумевают, что вход в систему должен осуществляться с помощью менее привилегированного личного пользователя, и привилегированные должны предоставляться при необходимости. Ansible может помочь с плагинами, которые запускают вещи от имени другого пользователя для вас, с помощью doas или sudo или чего-то еще.
Пароли — это мусорный метод аутентификации в целом. Низкая энтропия, плохая практика исторически и неудобно для автоматизации. Некоторые методы, работающие как другой пользователь, запрашивают ваш личный пароль, что снижает необходимость в общих учетных данных. Ansible может запросить у пользователя такой пароль с помощью--ask-become-pass
ansible-vault (и плагины поиска систем безопасности) защищают данные только в состоянии покоя, а не во время использования. Человек, работающий с Ansible, будет иметь доступ к открытому текстовому секрету. Он может быть виден при включенной достаточно подробной отладке.
Учитывая все вышесказанное, приемлемым решением может быть настройка become без паролей. ssh с использованием ключа или сертификата, но используйте become для запуска задачи пакета как root. Однако то, что они делают как root, не может быть ограничено. Ansible генерирует временные скрипты для запуска модулей, и нет хорошего правила sudo для ограничения команд, которые выглядят как/bin/sh -c '/usr/bin/python3 ~/.ansible/tmp/ansible-tmp-1628781435.871488-116497-130276452381107/AnsiballZ_setup.py'
Запускайте привилегированные сценарии для пользователей. Поощряйте их давать информацию о том, что делать, но не давайте им полномочий для этого. Поместите такие сценарии в систему контроля версий и принимайте запросы на изменения. Запускайте сценарии так, как вам нравится:
- ansible-бегун запланировано в cron.
- От конвейера, запускаемого слияниями, до производственной ветви в системе контроля версий.
- Задания запускаются из пользовательского интерфейса AWX.