Конфигурация сервера управления (master)

На машине, на которой установлен сервер управления (master), задайте настройки его конфигурации, следуя инструкциям в разделах ниже.

По умолчанию сервер управления (master) настраивается через главный файл конфигурации — /etc/salt/master.

Также поддерживается создание файлов конфигураций в каталоге /etc/salt/master.d/, что позволяет группировать логически параметры конфигурации.

Подробную информацию о настройке главного файла конфигурации сервера управления (master) см. в официальной документации.

Создание пользователя, от имени которого будут запускаться процессы SaltStack

Чтобы создать пользователя, от имени которого будут запускаться процессы SaltStack, создайте файл конфигурации сервера управления (master) /etc/salt/master.d/user.conf и задайте в нем значение параметра user.

Пример:

user: <my_user>
Если параметр не задан, по умолчанию процессы SaltStack будут запускаться от имени пользователя root.

Включение модуля salt-api

Чтобы включить модуль salt-api для модуля координации (SaltStack), выполните шаги:

  1. Cоздайте файл конфигурации сервера управления (master) /etc/salt/master.d/salt-api.conf.

    Пример:

    rest_cherrypy:
  port: 8080
  debug: True
  disable_ssl: True

    Где:

    • rest_cherrypy — параметры управления конфигурацией встроенного веб-сервера Cherrypy, который использует salt-api:

      • port — укажите порт, который будет запущен salt-api (например, 8080);

      • debug — (опционально) включите (True) или отключите (False) режим отладки (debug mode) для salt-api;

      • disable_ssl — (опционально) если в первом шаге вы не установили SSL-сертификаты, задайте значение True.

Включение модуля salt-api с использованием SSL-сертификатов

Чтобы включить модуль salt-api для модуля координации (SaltStack) с использованием SSL-сертификатов, выполните шаги:

  1. Сгенерируйте SSL-сертификат и закрытый ключ для сервера управления (master). В качестве примера здесь и далее будет использоваться сертификат salt-api.crt и закрытый ключ salt-api.key.

  2. Скопируйте сертификат salt-api.crt и закрытый ключ salt-api.key в директорию /etc/pki/tls/certs/.

  3. В файле конфигурации сервера управления (master) /etc/salt/master.d/salt-api.conf задайте следующие настройки:

    rest_cherrypy:
  port: 8000
  host: 0.0.0.0
  ssl_crt: /etc/pki/tls/certs/salt-api.crt
  ssl_key: /etc/pki/tls/certs/salt-api.key

    где:

    • port — порт, на котором будет запущен веб-сервер;

    • host — IP-адрес, на котором будет открыт порт для подключения клиентов;

    • ssl_crt — путь до файла с SSL-сертификатом сервера управления (master);

    • ssl_key — путь до закрытого ключа от SSL-сертификата сервера управления (master).

Настройка подключения к S3-совместимому хранилищу

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

  1. Cоздайте файл конфигурации сервера управления (master) /etc/salt/master.d/fileserver_backend.conf и в параметре fileserver_backend укажите имя хранилища, которое вы будете использовать в качестве бэкенда для файлов.

    Пример:

    fileserver_backend:
  - s3fs

  1. Cоздайте файл конфигурации сервера управления (master) /etc/salt/master.d/s3.conf и задайте в нем настройки подключения к S3-совместимому хранилищу.

    Пример:

    s3.service_url: <s3_hostname>:<s3_port>
s3.keyid: <acceess_key>
s3.key: <secret-key>
s3.buckets:
  - salt-bucket
s3.path_style: True
s3.location: <region>

    Где:

    • s3.service_url — URL-адрес и порт для обращения к S3-совместимому хранилищу;

    • s3.keyid — ключ доступа, который обеспечивает авторизацию и доступ к S3-совместимому хранилищу;

    • s3.key — секретный ключ, который обеспечивает авторизацию и доступ к S3-совместимому хранилищу;

    • s3.buckets — имя бакета (например, salt-bucket) для хранения файлов состояния и формул;

    • s3.path_style — стиль представления пути к объектам в S3-совместимом хранилище;

    • s3.location — регион, в котором расположено S3-совместимое хранилище.

      Для хранилища Ceph параметр s3.location не учитывается. Если вы используете Сeph в качестве хранилища, укажите значение default.
      Подробное описание всех параметров приведено в официальной документации.

  2. Cоздайте файл конфигурации сервера управления (master) /etc/salt/master.d/ext_pillar.conf и задайте в нем настройки подключения к S3-совместимому хранилищу для хранения в отдельном бакете данных Pillar.

    Пример:

    ext_pillar:
  - s3:
      service_url: <s3_hostname>:<s3_port>
      keyid: <acceess_key>
      key: <secret_key>
      bucket: pillar-bucket
      multiple_env: False
      environment: base
      prefix: ''
      verify_ssl: False
      s3_cache_expire: 30
      s3_sync_on_update: True
      path_style: True
      https_enable: False

    Где:

    • service_url — URL-адрес и порт для обращения к S3-совместимому хранилищу;

    • keyid — ключ доступа, который обеспечивает авторизацию и доступ к S3-совместимому хранилищу;

    • key — секретный ключ, который обеспечивает авторизацию и доступ к S3-совместимому хранилищу;

    • bucket — имя бакета (например, pillar-bucket), которое будет использоваться для хранения данных Pillar;

    • multiple_env — параметр, который определяет, поддерживается ли использование нескольких окружений (environments) в хранилище Pillar;

    • environment — параметр, который указывает на основное окружение (base environment) для хранилища Pillar;

    • prefix — префикс для путей к данным в S3-хранилище; пустая строка означает отсутствие префикса;

    • verify_ssl — параметр, который указывает, следует ли проверять SSL-сертификаты при обращении к S3-хранилищу;

    • s3_cache_expire — время жизни кэша (в секундах) для данных, полученных из S3-хранилища;

    • s3_sync_on_update — параметр, который определяет, следует ли выполнять синхронизацию данных при обновлении данных Pillar;

    • path_style — стиль представления пути к объектам в S3-хранилище;

    • https_enable — параметр, который указывает, следует ли использовать HTTPS для обращения к S3-хранилищу.

      Подробное описание всех полей приведено в официальной документации.

Настройка подключения к S3-совместимому хранилищу с использованием SSL-сертификатов

Если вы подключаетесь к S3-совместимому хранилищу с использованием SSL-сертификатов, выполните настройки:

  1. В файле конфигурации сервера управления (master) /etc/salt/master.d/s3.conf задайте значения параметров:

    s3.https_enable: True
s3.verify_ssl: False
    При выставлении значения False для параметра verify_ssl валидация сертификата S3-совместимого хранилища выполняться не будет.

  2. В файле конфигурации сервера управления (master) /etc/salt/master.d/ext_pillar.conf задайте значение параметра:

    ext_pillar:
 - s3:
    https_enable: True
    verify_ssl: False
    При выставлении значения False для параметра verify_ssl валидация сертификата S3-совместимого хранилища выполняться не будет.

Если требуется валидация сертификатов S3-совместимого хранилища, выполните следующие действия, выбрав один из двух вариантов, описанных ниже:

  • вариант 1:

    1. Скопируйте файл СА-сертификатов на сервер управления (master).

    2. Определите расположение хранилища сертификатов на сервере управления (master):

      $ /opt/saltstack/salt/bin/python3
Python 3.10.13 (main, Oct  4 2023, 21:54:22) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import certifi
>>> certifi.where()
'/opt/saltstack/salt/lib/python3.10/site-packages/certifi/cacert.pem'

    3. Добавьте сертификат в хранилище.

      Пример команды для добавления сертификата ca.crt:

      cat ca.crt | sudo tee -a /opt/saltstack/salt/lib/python3.10/site-packages/certifi/cacert.pem

    4. В файле конфигурации сервера управления (master) /etc/salt/master.d/s3.conf задайте значение параметра verify_ssl: True (аналогично параметру https_enable: True).

      Пример:

      s3.verify_ssl: True
s3.https_enable: True

    5. В файле конфигурации сервера управления (master) /etc/salt/master.d/ext_pillar.conf задайте значение параметра verify_ssl: True (аналогично параметру https_enable: True) .

      Пример:

      ext_pillar:
- s3:
    https_enable: True
    verify_ssl: True

  • вариант 2:

    1. Разместите файл СА-сертификатов, используемый в качестве Issuer в S3-совместимом хранилище, на сервере управления (master) по пути /etc/salt/pki/ca.crt.

    2. В файле конфигурации сервера управления (master) /etc/salt/master.d/s3.conf задайте значение параметра verify_ssl: /etc/salt/pki/ca.crt.

      Пример:

      s3.verify_ssl: /etc/salt/pki/ca.crt
s3.https_enable: True

    3. В файле конфигурации сервера управления (master) /etc/salt/master.d/ext_pillar.conf задайте значение параметра verify_ssl: /etc/salt/pki/ca.crt.

      Пример:

      ext_pillar:
- s3:
    https_enable: True
    verify_ssl: /etc/salt/pki/ca.crt

Загрузка пользовательских формул в S3-совместимое хранилище

Готовые формулы импортируются в S3-совместимое хранилище автоматически при установке продукта.

Чтобы загрузить пользовательские формулы и формулы-шаблоны используйте API-метод importFormulas.

Настройка интеграции с Apache Kafka

Отправка событий с сервера управления (master) в Apache Kafka выполняется с помощью библиотеки librdkafka.

Cоздайте файл конфигурации сервера управления (master) /etc/salt/master.d/returner.conf.

Пример файла:

returner.kafka_custom.bootstrap:
  - "<kafka_host>:<kafka_port>"
returner.kafka_custom.topic: 'salt-topic'
returner.kafka_custom.security.protocol: ""
returner.kafka_custom.ssl.cipher.suites: ""
returner.kafka_custom.ssl.curves.list: ""
returner.kafka_custom.ssl.sigalgs.list: ""
returner.kafka_custom.ssl.key.location: ""
returner.kafka_custom.ssl.key.password: ""
returner.kafka_custom.ssl.key.pem: ""
returner.kafka_custom.ssl.certificate.location: ""
returner.kafka_custom.ssl.certificate.pem: ""
returner.kafka_custom.ssl.ca.location: ""
returner.kafka_custom.ssl.ca.pem: ""
returner.kafka_custom.ssl.ca.certificate.stores: ""
returner.kafka_custom.ssl.crl.location: ""
returner.kafka_custom.ssl.keystore.location: ""
returner.kafka_custom.ssl.keystore.password: ""
returner.kafka_custom.ssl.providers: ""
returner.kafka_custom.ssl.engine.id: ""
returner.kafka_custom.enable.ssl.certificate.verification: ""
returner.kafka_custom.ssl.endpoint.identification.algorithm: ""
returner.kafka_custom.debug: "all"
returner.kafka_custom.log_level: ""
returner.kafka_custom.allow.auto.create.topics: "true"
event_return: kafka_custom

В таблицах ниже приводится описание параметров из файла.

Обязательные параметры:

Наименование Описание Пример значения

returner.kafka_custom.bootstrap

Список хостов с указанием портов, где запущен брокер сообщений Apache Kafka

"192.168.1.101:9092"

returner.kafka_custom.topic

Топик Apache Kafka

salt-topic

event_return

Выбор способа отправки событий возврата

kafka_custom

Опциональные параметры:

Наименование Описание Пример значения

returner.kafka_custom.security.protocol

Протокол, который используется для соединения с Apache Kafka

plaintext

returner.kafka_custom.ssl.cipher.suites

Набор шифров (именованная комбинация аутентификации, шифрование, MAC-адреса и алгоритмы обмена ключами), используемые для согласования параметров безопасности сетевого подключения по протоколу SSL. Подробнее см. SSL_CTX_set_cipher_list

returner.kafka_custom.ssl.curves.list

Поддерживаемые кривые (supported curves), стандартные/именованные или «явные» GF(2^k) или GF(p) для использования сервером, которые передаются в сообщении TLS ClientHello. Подробнее см. SSL_CTX_set1_curves_list

returner.kafka_custom.ssl.sigalgs.list

Поддерживаемые алгоритмы цифровой подписи для использования сервером, которые передаются в сообщении TLS ClientHello. Подробнее см. SSL_CTX_set1_sigalgs

returner.kafka_custom.ssl.key.location

Путь к закрытому ключу клиента (PEM), который используется для аутентификации

returner.kafka_custom.ssl.key.password

Пароль для закрытого ключа (для использования с ssl.key.location и set_ssl_cert())

returner.kafka_custom.ssl.key.pem

Строка закрытого ключа клиента (в PEM-формате), которая используется для аутентификации

returner.kafka_custom.ssl.certificate.location

Путь к публичному ключу клиента (в PEM-формате), который используется для аутентификации

returner.kafka_custom.ssl.certificate.pem

Строка публичного ключа клиента (в PEM-формате), которая используется для аутентификации

returner.kafka_custom.ssl.ca.location

Путь к файлу или каталогу сертификатов CA (Certificate Authority) для проверки ключа брокера

returner.kafka_custom.ssl.ca.pem

Строка сертификата CA (в PEM-формате) для проверки ключа брокера

returner.kafka_custom.ssl.ca.certificate.stores

Список хранилищ сертификатов Windows (через запятую), из которых можно загрузить сертификаты CA. Сертификаты будут загружены в том же порядке, в котором указаны хранилища

returner.kafka_custom.ssl.crl.location

Путь к CRL для валидации сертификата брокера

returner.kafka_custom.ssl.keystore.location

Путь к хранилищу ключей клиента (PKCS#12), которые используются для аутентификации

returner.kafka_custom.ssl.keystore.password

Пароль хранилища ключей клиента (PKCS#12)

returner.kafka_custom.ssl.providers

Список провайдеров (разделенный запятыми) OpenSSL 3.0.x

returner.kafka_custom.ssl.engine.id

Идентификатор OpenSSL

returner.kafka_custom.enable.ssl.certificate.verification

Включение проверки сертификата встроенного брокера OpenSSL (сервера). Эта проверка может быть расширена приложением путем реализации certificate_verify_cb

returner.kafka_custom.ssl.endpoint.identification.algorithm

Алгоритм идентификации endpoint для проверки имени хоста брокера с использованием сертификата брокера

returner.kafka_custom.debug

Список контекстов отладки (разделенный запятыми), которые необходимо включить

returner.kafka_custom.log_level

Уровень логирования

returner.kafka_custom.allow.auto.create.topics

Разрешение автоматического создания темы в брокере при подписке на несуществующие темы или назначения им тем.

Для корректной работы данной конфигурации брокер должен быть настроен с параметром auto.create.topics.enable=true
В качестве инструкции по генерации сертификатов используйте документ "Using SSL with librdkafka".

Настройка интеграции с Apache Kafka с использованием защищенного TLS-соединения

Если вы настраиваете интеграцию с использованием защищенного TLS-соединения, в файле конфигурации сервера управления (master) /etc/salt/master.d/returner.conf укажите все настройки, приведенные ниже:

returner.kafka_custom.bootstrap:
  - 10.31.0.170:9092
returner.kafka_custom.topic: salt-topic
returner.kafka_custom.security.protocol: "ssl"
returner.kafka_custom.ssl.key.location: "/etc/<span data-markjs="true" class="terms-mark tooltipstered terms-term-selector">salt</span>/pki/salt_kafkaclient.key"
returner.kafka_custom.ssl.key.password: "abcdefgh"
returner.kafka_custom.ssl.certificate.location: "/etc/<span data-markjs="true" class="terms-mark tooltipstered terms-term-selector">salt</span>/pki/salt_kafkaclient.pem"
returner.kafka_custom.ssl.ca.location: "/etc/<span data-markjs="true" class="terms-mark tooltipstered terms-term-selector">salt</span>/pki/salt_kafkaca.crt"
returnet.kafka_custom.ssl.endpoint.identification.algorithm: "none"
returner.kafka_custom.enable.ssl.certificate.verification: "false"
returner.kafka_custom.allow.auto.create.topics: "true"
returner.kafka_custom.debug: "all"
event_return: kafka_custom

Настройка журналирования

Для настройки журналирования сервера управления (master) cоздайте файл конфигурации /etc/salt/master.d/logging.conf и задайте в нем необходимые значения параметров, следуя примеру:

log_level: warning
log_file: /app/inno-osmax/logs/salt-master/master
log_level_logfile: warning
api_logfile: /app/inno-osmax/logs/salt-api/api
key_logfile: /app/inno-osmax/logs/salt-key/key

Где:

  • log_level — настройка уровня журналирования для сообщений, отправляемых на консоль; возможные значения:

    • all —  все сообщения будут записываться в лог-файл;

    • warning — сообщения, содержащие предупреждение о потенциальной проблеме или необычном состоянии, которое не является ошибкой, но требует внимания;

    • info — информационные сообщения о ходе работы модуля;

    • profile — профильная информация о производительности модуля координации (SaltStack);

    • debug — сообщения, содержащие отладочную информацию;

    • trace — сообщения, содержащие детальную отладочную информацию;

    • garbage — сообщения, содержащие более детальную (чем trace) отладочную информацию;

    • error — сообщения об ошибке, которая привела к некритическому сбою;

    • critical — сообщения об ошибке, которая привела к критическому сбою;

    • quiet — сообщения в лог-файл записываться не будут;

  • log_file — лог-файл; локальный путь к лог-файлу сервера управления (master);

  • log_level_logfile — уровень журналирования для сообщений, отправляемых в лог-файл;

    Возможные значения аналогичны значениям параметра log_level.

  • api_logfile — лог-файл; локальный путь к лог-файлу модуля salt-api;

  • key_logfile — лог-файл; локальный путь к лог-файлу модуля salt-key.

Настройка ротации и архивирования

Для настройки ротации и архивирования используется служба logrotate, которая обеспечивает автоматическую ротацию, сжатие, удаление и отправку лог-файлов по почте. Обычно служба logrotate запускается как ежедневное задание Cron в формате Quartz. В зависимости от настроек каждый лог-файл может обрабатываться ежедневно, еженедельно, ежемесячно или при достижении определенного размера.

Чтобы задать необходимые настройки, создайте файл конфигурации /etc/logrotate.d/salt-common.

Пример c минимальными настройками:

/app/inno-osmax/logs/salt-master/master {
daily
missingok
rotate 45
compress
notifempty
}

/app/inno-osmax/logs/salt-api/api {
daily
missingok
rotate 45
compress
notifempty
}

/app/inno-osmax/logs/salt-key/key {
daily
missingok
rotate 45
compress
notifempty
}

Где:

  • /app/inno-osmax/logs/<модуль SaltStack>/<имя лог-файла> — путь до лог-файла;

  • daily — период ротации лог-файла (ежедневно);

  • missingok — если лог-файл отсутствует, будет выполняться переход к следующему файлу без вывода сообщения об ошибке;

  • rotate 45 — лог-файл будет проходить 45 ежедневных ротаций, перед тем как будет удален;

  • compress — файл будет сжат после ротации;

  • notifempty — если лог-файл пустой, ротация выполняться не будет.

Настройка режима мульти-мастер с автоматическим переключением (failover)

Настройки, описанные ниже, являются опциональными и выполняются только при использовании режима мульти-мастер с автоматическим переключением (failover).

  1. Cоздайте файл конфигурации сервера управления (master) /etc/salt/master.d/master_sign_pubkey.conf.

  2. В файле конфигурации сервера управления (master) включите настройку подписи всех открытых ключей, установив значение параметра:

    master_sign_pubkey: True

  3. Перезапустите службу salt-master. После перезапуска сервер управления (master) автоматически создаст новую пару ключей и будет использовать ее для создания подписи открытых ключей, прикрепленной к ответу аутентификации:

    master_sign.pem
master_sign.pub

  4. (Опционально) задайте имя для пары ключей подписи, установив значение параметра:

    master_sign_key_name: <name_without_suffix>

Настройка параметров оптимизации производительности работы сервера управления (master)

При описанной выше настройке сервер управления (master) вычисляет подпись для каждого запроса аутентификации, что требует большого количества ресурсов процессора.

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

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

Чтобы создать такую подпись, выполните команду:

salt-key --gen-signature

В директории сервера управления (master) pki будет создан файл с подписью по умолчанию:

/etc/salt/pki/master/master_pubkey_signature

Это простой текстовый файл с двоичной подписью, преобразованной в base64. Если пара подписи еще не существует, пара подписи и файл подписи будут автоматически созданы за один вызов:

salt-key --gen-signature --auto-create

Чтобы сервер управления (master) использовал пересозданную подпись, установите значение параметра:

master_use_pubkey_signature: True

Для этого в каталоге сервера управления (master) pki должен присутствовать файл master_pubkey_signature с правильной подписью. Если у файла будет другое имя, задайте его, указав значение параметра:

master_pubkey_signature: <filename>

При наличии большого количества серверов управления (masters) и открытых ключей (по умолчанию и для подписи) рекомендуется использовать имя хоста salt-masters для имен файлов подписи. Подписи легко перепутать, поскольку они не несут никакой информации о ключе, из которого была создана подпись.

Подробное описание включения режима мульти-мастер с автоматическим переключением (failover) см. в одноименном разделе.

Настройка включения опции удаленной установки агентов (minions)

Настройки, описанные в разделе являются опциональными и применяются, если вы подключаете опцию удаленной установки агентов (minions).

  1. Cоздайте файл конфигурации сервера управления (master) /etc/salt/master.d/roster.conf:

    roster_defaults:
  sudo: True
  ssh_options:
    - "StrictHostKeyChecking=no"
    - "UserKnownHostsFile=/dev/null"

    Где:

    • roster_defaults — блок параметров, которые используются при управлении удаленными серверами:

      • sudo — параметр, указывающий на то, что при подключении к удаленному серверу через SSH команды выполняются от имени суперпользователя;

      • ssh_options — список опций SSH, которые применяются при подключении к удаленным серверам:

        • StrictHostKeyChecking — опция включения/выключения проверки хост-ключей (host key checking); возможные значения:

          • yes — SSH-клиент строго проверяет ключи хостов при подключении к новым серверам: если ключ хоста не найден в файле known_hosts, SSH-клиент выдает предупреждение и запрашивает разрешение на добавление этого ключа в файл known_hosts;

          • no — отключение проверки ключей хостов;

        • UserKnownHostsFile — опция, указывающая путь к файлу, в котором хранятся известные ключи хостов (known hosts); по умолчанию, SSH клиент сохраняет ключи хостов в файле ~/.ssh/known_hosts.

  2. Создайте файл конфигурации /etc/salt/roster (в формате, указанном в примере ниже) и укажите в нем список устройств, к которым должны применяться настройки ростера, заданные в файле /etc/salt/master.d/roster.conf.

    Пример файла:

    dev-osmax-vm0104.osmax.terra.inno.tech: {}
dev-osmax-vm0105.osmax.terra.inno.tech: {}
...
dev-osmax-vm0109.osmax.terra.inno.tech: {}