Подготовка управляемых узлов и узлов управления к использованию системных ролей#

Введение в системные роли#

Системные роли — это набор ролей и модулей Ansible. Системные роли предоставляют интерфейс конфигурации для удаленного управления несколькими системами SberLinux. Интерфейс позволяет управлять конфигурациями системы в нескольких версиях, а также внедрять новые мажорные релизы.

В SberLinux интерфейс состоит из следующих ролей:

  • Выдача и продление сертификата (certificate);

  • Кокпит (cockpit);

  • Межсетевой экран (firewall);

  • Кластер высокой готовности (ha_cluster);

  • Дамп ядра (kdump);

  • Настройки ядра (kernel_settings);

  • Ведение журнала (logging);

  • Показатели (PCP) (metrics);

  • SQL Server (sql.server);

  • Сеть (network);

  • Клиент Network Bound Disk Encryption и сервер Network Bound Disk Encryption (nbde_client и nbde_server);

  • Postfix (postfix);

  • SELinux (selinux);

  • SSH-клиент (ssh);

  • SSH-сервер (sshd);

  • Хранение (storage);

  • Запись сеанса терминала (tlog);

  • Синхронизация времени (timesync);

  • VPN (vpn);

  • PostgreSQL (postgresql);

  • Podman (podman);

  • Управление службами (systemd);

Роли ha_cluster, firewall, selinux и системы сертификатов#

Системная роль ha_cluster поддерживает следующие функции:

  • Использование системных ролей брандмауэра и selinux для управления доступом к портам. Чтобы настроить порты кластера для запуска служб firewalld и selinux, можно установить новым ролевым переменным ha_cluster_manage_firewall и ha_cluster_manage_selinux значение true. Это настраивает кластер на использование системных ролей брандмауэра и selinux, автоматизируя и выполняя эти операции в рамках системной роли ha_cluster. Если для этих переменных установлено значение по умолчанию - false, роли не выполняются. Значит ha_cluster_manage_firewall получает значение - true.

  • Использование роли системы сертификатов для создания пары закрытого ключа pcsd и сертификата. Системная роль ha_cluster поддерживает переменную роли ha_cluster_pcsd_certificates. Установка этой переменной передает значение переменной certificate_requests для роли системы сертификации. Это обеспечивает альтернативный метод создания пары закрытого ключа и сертификата для pcsd.

ha_cluster

Устройство кворума действует как стороннее арбитражное устройство для кластера. Устройство кворума рекомендуется для кластеров с четным числом узлов. В кластерах с двумя узлами использование устройства кворума позволяет лучше определить, какой узел остается в ситуации их разделения. Можно настроить устройство кворума с помощью ha_clusterqdeviceqnetd.

metrics

Сбор фактов Ansible может быть отключен в среде по соображениям производительности. В таких конфигурациях невозможно использовать роль системы показателей metrics.

Системная роль metrics может использовать роль firewall и роль selinux для управления доступом к портам. С помощью этого можно контролировать доступ к портам. Если установите для новых переменных ролей metrics_manage_firewall и metrics_manage_selinux значение true, роли будут управлять доступом к порту.

postfix

Системная роль postfix может использовать системные роли firewall и selinux для управления доступом к портам. С помощью этого можно автоматизировать управление доступом к портам, используя новые переменные ролей postfix_manage_firewall и postfix_manage_selinux:

  • Если для них установлено значение true, каждая роль используется для управления доступом к порту.

  • Если для них установлено значение false, которое используется по умолчанию, роли не задействуются.

vpn

Системная роль vpn может использовать роли firewall и selinux для управления доступом к портам. С помощью этого можно автоматизировать управление доступом к портам в роли системы vpn через роли firewall и selinux. Если установить для новых переменных ролей vpn_manage_firewall и vpn_manage_selinux значение true, роли будут управлять доступом к порту.

nbde_server

Системная роль nbde_server может использовать роли firewall и selinux для управления доступом к портам. Если установите для новых переменных ролей nbde_server_manage_firewall и nbde_server_manage_selinux значение true, роли будут управлять доступом к порту. Можно автоматизировать эти операции напрямую с помощью роли nbde_server.

Интеграция системной роли cockpit с ролями firewall, selinux и certificate#

Роль cockpit интегрируется с ролями firewall и selinux для управления доступом к портам, а также интегрируется с ролью certificate для генерации сертификатов.

Для управления доступом к порту используйте переменные new cockpit_manage_firewall и cockpit_manage_selinux. По умолчанию обе переменные имеют значение true и не выполняются. Установите для них значение false, чтобы разрешить ролям и true управлять доступом к порту службы пользовательской веб-консоли. Затем операции будут выполняться в рамках firewall роли.

Примечание

Пользователь несет ответственность за управление доступом к портам для firewall и SELinux.

Для создания сертификатов используйте новую cockpit_certificates переменную. По умолчанию для переменной установлено значение false, и certificate роль не выполняется. Можно использовать эту переменную так же, как использовали бы certificate_request переменную в certificate роли.

Системная роль selinux теперь поддерживает local параметр. Используя этот параметр, можно удалить только изменения локальной политики и сохранить встроенную политику SELinux.

Интеграция системной роли logging с ролями firewall, selinux и certificate#

Роль logging интегрируется с ролями firewall и selinux для управления доступом к портам, а также интегрируется с ролью certificate для генерации сертификатов.

Для управления доступом к порту используйте переменные new logging_manage_firewall и logging_manage_selinux. По умолчанию обе переменные имеют значение false и не выполняются. Установите для них значение true чтобы роли выполнялись, как logging роль.

Примечание

Пользователь несет ответственность за управление доступом к портам для firewall и SELinux.

Для создания сертификатов используйте новую logging_certificates переменную. По умолчанию для переменной установлено значение false, и certificate роль не выполняется. Можно использовать эту переменную так же, как использовали бы certificate_request переменную в certificate роли. После чего logging роль будет использовать certificate роль для управления сертификатами.

Интеграция системной роли sshd с ролями firewall, selinux и certificate#

Системная роль sshd может использовать системные роли firewall и selinux для управления доступом к портам.

Это автоматизирует управление доступом к портам с помощью новых переменных sshd_manage_firewall и sshd_manage_selinux. Если для них установлено значение true, каждая роль используется для управления доступом к порту. Если для них установлено значение false, которое используется по умолчанию, то роли не задействуются.

Подготовка узла управления#

Для подготовки узла управления выполните следующий сценарий:

  1. Установите sberlinux-system-roles пакет:

    [root@control-node]# yum install sberlinux-system-roles

    Эта команда устанавливается Ansible Core как зависимость.

  2. Создайте пользователя, которого позже будете использовать для управления и выполнения playbook:

    [root@control-node]# useradd ansible

  3. Переключитесь на только что созданного ansible пользователя:

    [root@control-node]# su - ansible

    Выполните оставшуюся часть процедуры от имени этого пользователя.

  4. Создайте открытый и закрытый ключ SSH:

    [ansible@control-node]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/ansible/.ssh/id_rsa): password
...

    Используйте предлагаемое расположение по умолчанию для файла ключа.

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

  6. Создайте ~/.ansible.cfg файл со следующим содержимым:

    [defaults]
inventory = /home/ansible/inventory
remote_user = ansible

[privilege_escalation]
become = True
become_method = sudo<
become_user = root
become_ask_pass = True

С этими настройками:

  • Ansible управляет хостами в указанном файле inventory.

  • Ansible использует учетную запись, указанную в remote_user параметре, при установке SSH-соединений с управляемыми узлами.

  • Ansible использует sudo утилиту для выполнения задач на управляемых узлах от имени пользователя с административными полномочиями. Из соображений безопасности настройте sudo на управляемых узлах в виде требования введения пароля удаленного пользователя, чтобы стать пользователем с административными полномочиями. Укажите become_ask_pass=True параметр в ~/.ansible.cfg, и Ansible запросит пароль при выполнении playbook.

Настройки в ~/.ansible.cfg файле имеют более высокий приоритет и переопределяют настройки из глобального /etc/ansible/ansible.cfg файла.

Создайте ~/inventory файл. Например, ниже представлен файл inventory в формате INI с тремя хостами и одной группой хостов с именем RU:

managed-node-01.example.ru [RU]
managed-node-02.example.ru ansible_host=<IP_address>
managed-node-03.example.ru

Обратите внимание, что управляющий узел должен иметь возможность разрешать имена хостов. Если DNS-сервер не может разрешить определенные имена хостов, добавьте параметр рядом с записью хоста, чтобы указать его IP-адрес, в примере выше это <IP_address>.

Дополнительные ресурсы:

Справочная страница: ssh-keygen(1).

Подготовка управляемого узла#

Ansible не использует агент на управляемых хостах. Единственным требованием является Python, который по умолчанию установлен на SberLinux, и SSH-доступ к управляемому хосту.

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

  • для входа в управляющий узел;

  • выполнения playbook от имени разных пользователей, например от пользователя с административными полномочиями.

Предварительные условия

- Подготовлен узел управления

Чтобы подготовить управляемый узел, выполните следующие шаги:

  1. Создайте пользователя:

    [root@managed-node-01]# useradd ansible

    Позже управляющий узел использует этого пользователя для установления соединения SSH с этим хостом.

  2. Установите пароль для пользователя ansible:

    [root@managed-node-01]# passwd ansible
Changing password for user ansible.
New password: password
Retype new password: password
passwd: all authentication tokens updated successfully.

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

  3. Установите ansible открытый SSH-ключ пользователя на управляемом узле:

    • Войдите на управляющий узел как ansible пользователь и скопируйте открытый ключ SSH на управляемый узел:

    [ansible@control-node]$ ssh-copy-id managed-node-01.example.ru /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed:
"/home/ansible/.ssh/id_rsa.pub"
The authenticity of host 'managed-node-01.example.ru (<ip-address>)' can't be established.
ECDSA key fingerprint is SHA256:9bZ33GJNODK3zbNhybokN/6Mq7hu3vpBXDrCxe7NAvo.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
ansible@managed-node-01.example.ru's password: password

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'managed-node-01.example.ru'"
and check to make sure that only the key(s) you wanted were added.

    • Удаленно выполните команду на узле управления, чтобы проверить соединение SSH:

    [ansible@control-node]$ ssh managed-node-01.example.ru whoami
ansible

  4. Создайте sudo конфигурацию для ansible пользователя:

    • Используйте visudo команду для создания и редактирования /etc/sudoers.d/ansible файла:

    [root@managed-node-01]# visudo /etc/sudoers.d/ansible

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

    • Введите в /etc/sudoers.d/ansible файл следующее содержимое:

    ansible ALL=(ALL) NOPASSWD: ALL

    Эти настройки предоставляют ansible пользователю права запускать все команды от имени любого пользователя и группы на этом хосте без ввода пароля ansible пользователя.

Дополнительные ресурсы:

Справочная страница: sudoers(5).

Проверка доступа с узла управления к управляемым узлам#

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

Выполните эту процедуру как ansible пользователь на узле управления.

Предварительные условия

- Подготовлен узел управления

- Подготовлен как минимум один управляемый узел

- Если можно запускать playbook на группах хостов, управляемый узел указан в файле inventory на узле управления

Для проверки доступа выполните следующий сценарий:

  1. Используйте модуль Ansible ping, чтобы убедиться, что можно выполнять команды на всех управляемых хостах:

    [ansible@control-node]$ ansible all -m ping
BECOME password: password
managed-node-01.example.ru | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}
...

  2. Закодированная группа хостов all динамически содержит все хосты, перечисленные в файле inventory.

  3. Используйте модуль Ansible command для запуска whoami утилиты на управляемом хосте:

    [ansible@control-node]$ ansible managed-node-01.example.ru -m command -a whoami
BECOME password: password
managed-node-01.example.ru | CHANGED | rc=0 >>
root

    Если команда возвращает права с административными полномочиями, значит, sudo настроен правильно на управляемых узлах и работает повышение привилегий.

Дополнительные ресурсы:

Справочная страница: ssh-keygen(1).