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

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

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

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

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

  • Кокпит (cockpit)

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

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

  • dump ядра (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_firewall значение 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 как зависимость.

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


[root@control-node]# useradd ansible

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


[root@control-node]# su - ansible

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

  1. Создайте открытый и закрытый ключ 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
...

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

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

  2. Создайте ~/.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 утилиту для выполнения задач на управляемых узлах от имени root-пользователя. Из соображений безопасности настройте sudo на управляемых узлах в виде требования введения пароля удаленного пользователя, чтобы стать root пользователем. Укажите 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=hh.hh.hh.hh
managed-node-03.example.ru

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

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

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

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

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

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

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

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

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

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

Процедура:

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


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

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

  1. Установите пароль для 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 для выполнения задач от имени root пользователя.

  1. Установите 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 (192.0.2.100)' 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

  1. Создайте 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"
}
...

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

  2. Используйте command модуль Ansible для запуска 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

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

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

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