Управление секретами в Ansible

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

Давайте посмотрим, как мы можем управлять секретами.

Пароль или ключи SSH

В большинстве случаев Ansible подключается к целевым хостам через SSH. Обычно используется имя пользователя системы и ключи SSH, установленные в /.ssh, что является значением по умолчанию для SSH-клиентов. В этом случае ничего не нужно делать на клиентах, чтобы Ansible мог использовать SSH, если они уже могут подключаться к целевым хостам.

Также можно указать другое имя пользователя как ANSIBLE_REMOTE_USER и файл конфигурации SSH как ANSIBLE_NETCONF_SSH_CONFIG. Эти параметры можно указать в файле конфигурации Ansible или в качестве переменных среды.

ANSIBLE_ASK_PASS может быть указан. В этом случае Ansible запросит у пользователя ввод пароля SSH.

Избегание совместного использования секретов

Как общее правило, любая конфигурация, предполагающая передачу конфиденциальной информации лицам, которые будут подключаться к системе, подразумевает определённый риск. Поэтому наиболее распространённым выбором является предоставление пользователям возможности входа в удалённые системы под своими локальными именами пользователей, используя ключи SSH.

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

MariaDB имеет плагин UNIX_SOCKET, который можно использовать, чтобы некоторые пользователи избегали ввода пароля, поскольку они уже вошли в систему. Этот метод аутентификации используется по умолчанию для пользователя root. Это хороший способ избежать ввода ещё одного пароля и, возможно, записи в файл .my.cnf, чтобы пользователю не пришлось его вводить.

Даже для пользователей, подключающихся удалённо, обычно нет необходимости вводить пароли в файл Ansible. При создании пользователя с паролем хэш исходного пароля хранится в MariaDB. Этот хэш можно найти в таблице mysql.user. Чтобы узнать хэш пароля, не создавая пользователя, мы можем использовать функцию PASSWORD():

SELECT PASSWORD('my_password12') AS hash;

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

CREATE USER user@host IDENTIFIED BY PASSWORD '*54958E764CE10E50764C2EECBB71D01F08549980';

ansible-vault

Даже если вы попытаетесь избежать совместного использования секретов, скорее всего, вам придётся хранить некоторые из них в Ansible. Например, у пользователей MariaDB, подключающихся удалённо, есть пароли, и если мы хотим, чтобы Ansible создавал и управлял этими пользователями, хэши должны быть где-то в нашем репозитории Ansible. Хотя хэш нельзя преобразовать обратно в пароль, обычно имеет смысл рассматривать хэши как секреты. Ansible предоставляет встроенный способ обработки секретов: ansible-vault.

В простейшем случае мы можем управлять всеми нашими паролями с помощью одного пароля ansible-vault. При добавлении или изменении нового пароля в некотором файле (обычно в файле в host_vars или group_vars) мы будем использовать ansible-vault для шифрования этого пароля. При этом нас попросят ввести наш пароль ansible-vault. При применении роли и Ansible потребуется расшифровать этот пароль, он попросит нас снова ввести наш пароль ansible-vault.

ansible-vault может использовать более одного пароля. Каждый пароль может управлять набором секретов. Например, некоторые пользователи могут иметь пароль для управления паролями обычных пользователей MariaDB, а только один может иметь пароль, необходимый для управления паролем пользователя root.

Содержание первоначально предоставлено компанией Vettabase Ltd.