SaltStack Config и vRealize Automation 8.3 – Aleksandr Mykhalchenko`s Blog

В нашей статье «VMware vRealize Automation 8.3 Release Notes» название «SaltStack Config» нами упоминалось впервые в контексте рапорта VMware о внесении этого мощного компонента управления конфигурацией софта в vRA. Давайте с ним познакомимся поближе. SaltStack Config помогает легко определять оптимизированные, безопасные состояния ПО и применять их по всем типам сред – виртуализированным, гибридным или публичным облачным, – опираясь на гибкую и интуитивно понятную автоматизацию конфигурации. Изменения при этом вносятся сразу же, благодаря масштабируемому удаленному выполнению.

Использование SaltStack Config, сразу оговоримся, является опциональным и влечет за собой дополнительные траты на лицензирование. Тем не менее, технология интереснейшая, поэтому поговорим о ней подробнее.

Что такое SaltStack Config?

Наряду с Cloud Assembly, Service Broker и Code Stream, SaltStack Config является сервисным компонентом VMware vRealize Automation, в задачи которого входит поддержка IaC, конвейерная обработка и бесшовная интеграция с собственным управлением состояния и сторонними инструментами, например, Ansible, Puppet и Terraform. Автоматизация конвейером релиза достигается участием Code Stream, при этом расширенное покрытие для инфраструктуры и конвейеров приложений – через удобный каталог самообслуживания.

Улучшенная аналитика и обзорность предоставляют сквозное представление всех конвейеров и их актуального состояния. Кроме того, нельзя не отметить сопутствующую автоматизацию инфраструктуры Kubernetes, интеграцию vSphere с Tanzu, позволяя администратору облака создавать пространства имен и назначать их проектам.

Среди возможностей SaltStack Config:

Простой разворот по всем виртуализированным, гибридным и публичным облачным средам с созданием доступного IaC для предоставления и настройки систем и софта где-угодно в них;
Конфигурирование и контроль над всеми операционными системами с абстрактным управлением для Linux, Windows, MacOS и Unix;
Автоматическое применение желаемого состояния по всему IT-пространству, быстрый и простой аудит, понимание конфигурационного статуса всей экосистемы;
Возможность поддержки актуальности и защиты критического софта с помощью апдейтов на основе событий;
Управление ВМ виртуальных, публичных и приватных облаков с мощной автоматизацией и оркестровкой;
Контроль над всем дата-центром с помощью гибкого агента, вообще без агента и опираясь на API-опции управления;
Определение статуса соответствия со встроенным CIS и DISA STIG контентом и автоматизированное его применение;
Создание полностью автоматизированных и полуавтономных рабочих процессов, уведомляющих администраторов с помощью сторонних интеграций, и ITSM-тикетов, когда система нуждается во внимании;
Немедленное внесение изменений в весь имеющийся парк быстрым и масштабируемым удаленным выполнением.

Архитектура

Главные компоненты архитектуры SaltStack Config можно проиллюстрировать следующей схемой:

Salt-мастер выступает главным связующим звеном между SaltStack Config и остальными нодами в сети, называемыми миньонами. Отдаваемая из SaltStack Config команда сначала поступает в мастер, а затем распределяется по целевым миньонам. На мастере инсталлируется Master Plugin для обеспечения связи с RaaS-нодой (Returner as a Service) – он позволяет мастеру получить доступ к инициированным SaltStack Config заданиям и процессам, а внешние файлы и опорные данные хранятся в PostgreSQL БД.

Модель Salt относится к классу «издатель-подписчик». Мастер публикует задания, миньоны на них подписываются, происходит применение задания к миньону, и он его выполняет, после чего отправляет данные ответа на задание обратно мастеру:

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

Важно! К SaltStack Config можно подключать более одного мастера, но в этом случае нужно проинсталлировать Master Plugin на каждом.

RaaS предоставляет конечные точки RPC для получения управляющих команд из пользовательского интерфейса SaltStack Config, а RPC контролирует взаимодействие конечных точек с подключенными мастерами. Вся коммуникация происходит с использованием вызовов RPC API по WebSockets или HTTP(s):

БД PostgreSQL используется RaaS для хранения данных миньонов, ответов на задания, данных событий, файлов и опорных данных, аккаунтов локальных пользователей, а также дополнительных настроек UI.

БД Redis используется RaaS для хранения определенных типов данных во временном хранилище, например, данных кэша. Кроме того, в ее задачи входит распределение поставленных в очередь заданий для квалифицированных работников.

Архитектура Salt относится к классу модульных и демонстрирует удивительную гибкость:

Ниже расскажем подробнее о ряде других важных составляющих архитектуры Salt и процессах, описывающих ее функционал.

Цели и зерна

Одними из ключевых понятий в архитектуре Salt являются понятия «цели» и «зерен». Цель – это группа миньонов, к которым применяется команда задания от одного или нескольких мастеров.

Важно! Мастер аналогично может быть целью – им можно управлять как миньоном, если на нем запущена служба salt-minion.

Зерна – это общие характеристики или черты миньонов. У Salt есть интерфейс для получения информации о базовой системе. Он называется интерфейсом зерен, так как презентует Salt с зернами информации. Зерна собираются для операционной системы, доменного имени, IP-адреса, ядра, типа ОС, памяти и многих других системных характеристик. Можно создавать свои собственные зерна данных.

Данные по зерну относительно статичны. Тем не менее они обновляются, когда меняется системная информация (например, параметры сети) или, когда новое значение присваивается пользовательскому зерну.

Шина событий (открытая система событий)

Также пару слов обязательно нужно сказать и о шине событий – т. н. открытой системе событий. Она используется для процессов внутренней коммуникации между мастером и миньонами. В ней события видны и мастеру, и миньонам, они могут ими же отслеживаться и оцениваться. В целом, именно шина событий закладывает основу для оркестровки и мониторинга в режиме реального времени. В системе ивентов миньоны видят все опубликованные задания и результаты подписки на события.

В Salt используется подключаемая система событий с двумя уровнями: ZeroMQ (0MQ) (текущая дефолтная библиотека уровня сокета в качестве гибкого транспортного уровня) и Tornado (основанный только на TCP транспортный уровень).

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

Состояния Salt

Помимо удаленного выполнения, Salt предлагает другой метод настройки миньонов путем декларирования, в каком состоянии они должны находиться (состояние Salt). Благодаря состояниям Salt можно управлять конфигурациями, использовать их для разворота и управления инфраструктурой с применением простых файлов YAML (для справки, в нашем блоге опубликован для всех интересующихся краткий учебник по этому языку, рекомендуем ознакомиться с ним перед дальнейшим прочтением), автоматизировать повторяющиеся и предсказуемые задачи путем постановки заданий в очередь для Salt, причем все это – без необходимости выполнять операции ввода пользователем. Также к файлам состояния может быть добавлена более сложная условная логика при помощи Jinja.

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

Опоры в Salt

Еще одним ключевым компонентом архитектуры Salt является функция опоры (pillar), которая берет определенные на мастере данные и распределяет их по миньонам при необходимости. Она используется, в основном, для хранения секретной информации или других высокочувствительных данных, например, данных учетных записей аккаунтов, криптографические ключи или пароли. Также она может быть полезна в хранении несекретных данных, которые не хочется помещать напрямую в файлы состояний – данные конфигурации и пр. Опоры вносят данные в кластер с противоположной стороны от зерен. В то время как миньоны генерируют зерна, в опорах данные создаются мастером.

Организация опор похожа на организацию состояний – это дерево состояний опор, где top.sls работает как координатор данных опоры для сред и миньонов, имеющих доступ к этим данным. Переносимая с помощью опор информация обладает словарем, сгенерированным для целевого миньона и зашифрованным с помощью ключа этого миньона для безопасности. Шифрование данных опор производится по-миньонно, а их хранение – в разрезе такого конкретного миньона.

Маяки и реакторы

Система маяков – это инструмент мониторинга, опрашивающий все разнообразие систем процессов на миньонах. Маяки могут запускать реакторы, помогающие впоследствии в применении изменений или траблшутинге проблемы. Их функционал лежит в области автоматического создания отчетов, доставки логов ошибок, мониторинга микро-сервисов, активности пользовательской оболочки и слежения за ресурсами. В тандеме с реакторами они могут создавать автоматизированные заранее прописанные ответы проблемам инфраструктуры и приложений, с их помощью легче кастомизировать уникальные состояния с учетом специфических нужд.

Реакторы же расширяют возможности Salt автоматизированными ответами с использованием предварительно написанных состояний исправлений. Они применяются в масштабировании инфраструктуры, оповещении администраторов, перезапуске засбоивших приложений и в автоматическом откате.

Раннеры Salt

Раннеры представляют собой выполняемые командой salt-run приложения, и работают они по аналогии с модулями выполнения. Однако, применяются они к мастеру, а не к миньонам. Раннер Salt может быть простым клиентским вызовом или же комплексным приложением.

Модуль состояния раннеров используется в выполнении состояний на мастере оркестровкой, координируя активности множества машин централизованно и дополнительно контролируя последовательности наступления определенных событий конфигурации.

Аддоны

С целью устранения уязвимостей и обеспечения требований безопасности к SaltStack Config предлагается два аддона: SaltStack Comply и SaltStack Protect. Они используют управляемую событиями технологию автоматизации.

SaltStack Comply отвечает за автоматизацию обнаружения несоответствий и последующего их исправления в инфраструктуре. Для просмотра и использования рабочего пространства SecOps Compliance в UI SaltStack Config и через командную строку RaaS требуется лицензия SaltStack Comply. Контент SaltStack Comply регулярно обновляется и поддерживает настройку соответствия, а также предоставляет библиотеку материалов о соответствии.

SaltStack Protect предлагает автоматизацию сканирования уязвимостей с последующим восстановлением для инфраструктуры. Для просмотра и использования рабочего пространства SecOps Vulnerability в UI SaltStack Config и через командную строку RaaS требуется лицензия SaltStack Protect. Эта надстройка аналогично включает обновляемый контент, но уже по изменениям стандартов безопасности и выпуску новых рекомендаций в этой сфере.

Оба аддона поддерживают автоматическую или ручную загрузку нового выпущенного SaltStack контента.

Сценарии имплементации SaltStack Config

Инсталляция SaltStack Config может проводится в одном из двух форм-факторов:

Одна нода (Salt-мастер, SaltStack Config, базы данных Redis и PostgreSQL будут запускаться на одной ноде);
Мульти-нодовый (4 ноды, каждая – под отдельный компонент структуры, например, по одной ноде на: Salt-мастер, базу данных PostgreSQL, базу данных Redis и SaltStack Config, последняя нода чаще называется RaaS).

Второй сценарий разворота, в принципе, не декларативен: можно запустить мастер-сервис на одной ноде и скомбинировать два или даже больше других сервисов на отдельных. Однако, в таких случаях, отступающих от генеральной линии рекомендаций VMware, лучше консультироваться со специалистами.

Главной и первичной нодой в имплементации SaltStack является мастер – именно он будет настраивать мульти-нодную среду, инсталлировать основную архитектуру SaltStack Config на трех других нодах.

Важно! Оркестровка – одна из причин, почему SaltStack настолько мощный инструмент управления конфигурацией. Ручная инсталляция и настройка каждой ноды в системе чересчур трудоемкий, ресурсоемкий и утомительный процесс.

Выбор конкретного типа сценария зависит от того, какой, оценивая свои нужды, цели и исходные данные, будет дан ответ на следующие вопросы, являющиеся краеугольными в дизайне интеграции vRealize Automation SaltStack Config:

Сколько нод в сети? Придется ли SaltStack управлять ими всеми, или только некоторыми?
Нужна ли сети НА, в т. ч. функции балансировки нагрузки и автоматического переключения в случае падений?
Какова вообще цель инсталляции SaltStack Config? Хочется просто посмотреть на возможности или нужен серьезный разворот для продакшена?

Вообще же, выбор сценария с одной нодой адекватен в случае, если в сети не более 1 000 миньонов (именно этим количеством нод будет управлять Salt) и хочется установить систему очень быстро, и быстро же произвести оценку ее пользы перед тем, как разворачивать в продакшен-среде. Для рабочей корпоративной среды эта схема, конечно же, не рекомендуется, ведь, в первую очередь, стоит учесть, что, если наша единственная нода упадет, вся экосистема SaltStack Config рухнет вместе с ней.

Что же касается мульти-нодового варианта, он прекрасен своей масштабируемостью и приспосабливаемостью к росту сети, а его функциональность не зависит от доступности одной ноды. Однако, стоит учесть, что такой разворот будет куда более сложным, он потребует более скрупулезного планирования, а при необходимости НА, возможно, понадобится поддержка со стороны.

Требования к среде под SaltStack Config

Единственным важным и серьезным требованием, без учета которого применение SaltStack Config будет невозможным, это отключение режима FIPS. В остальном, все зависит от того, какой сценарий имплементации мы выбрали.

Требования по виртуальному железу при одно-нодовом развороте SaltStack

В случае размещения на единственной ноде и мастера, и SaltStack Config, БД Redis и PostgreSQL нам понадобится до 1 000 нод (миньонов), а также:

CPU	8 ядер
Память	16 ГБ
Диск	40 ГБ, минимум

Учтите, что нужда в дисковом пространстве растет пропорционально количеству данных, возвращаемых миньонами.

Требования по виртуальному железу при мульти-нодовом развороте SaltStack

Если мы разносим все главные архитектурные компоненты SaltStack по разным нодам (случай с комбинацией 1+1, 1+2 и т.д. – индивидуален и здесь рассматриваться не будет), у нас должно быть от 1 000 нод для миньонов, причем, требования по «железу» будут разными, в зависимости от взятого кол-ва нод:

Хост	1 000 – 2 500 миньонов	2 500 – 5 000 миньонов	> 5 000 миньонов
Мастер-нода Salt			Рекомендовано рассмотреть вариант с несколькими мастерами
– CPU, ядер	4	8
– память, ГБ	8	16
RaaS-нода			На каждые 5 000 миньонов организовывается дополнительная нода SaltStack Config позади предпочитаемого LB
– CPU, ядер	4	8
– память, ГБ	8	16
Нода для Redis			Чем больше – тем выше производительность
– CPU, ядер	2	4
– память, ГБ	4	8
Нода для PostgreSQL			Чем больше – тем выше производительность
– CPU, ядер	4	8
– память, ГБ	8	16

Независимо от типа разворачиваемой ноды, дискового пространства понадобится:

для 1 000 – 2 500 миньонов, минимум – 40 ГБ;
для 2 500 – 5 000 миньонов, минимум – 80 ГБ;
для более 5 000 миньонов – столько, сколько нужно для случая «2 500 – 5 000», помноженное на количество блоков по 5 000.

Так же, как и для одно-нодовой ситуации, помните, что требования по дисковому пространству растут пропорционально количеству данных, возвращаемых миньонами.

Требования к ОС

SaltStack Config идеально совместим с:

RedHat 7.4 or higher (RHEL 7),

Важно! Версии RHEL ниже 7.4 нуждаются в апдейте OpenSSL до 1.0.2k. Если это недоступно через yum-обновление, или же сервер не имеет прямого доступа в интернет, достаньте пакеты openssl-1.0.2k-12.el7.x86_64.rpm и openssl-libs-1.0.2k-12.el7.x86_64.rpm от RedHat или с предпочитаемого публичного зеркала.

CentOS 7 (CentOS7).

Поддерживаются и системы:

Oracle Linux 7,
SUSE Linux Enterprise Server 15 (SLES 15),
SUSE Linux Enterprise Server 12 (SLES 12),

хотя они не рекомендованы.

Это списки поддерживаемых ОС для RaaS-ноды. Мастера сами в состоянии быть операционными системами и могут управлять нодами большинства стандартных ОС.

Версионность БД

Доступна поддержка БД PostgreSQL, начиная с версии 9.6, но рекомендовано пользоваться 12.4. Рекомендованная версия включена в инсталлятор SaltStack Config.

Важно! Учтите, что так как PostgreSQL является open source сторонней БД, будущим техобслуживанием, бэкапированием и другими административными задачами придется заниматься самостоятельно. Всю необходимую информацию можно почерпнуть отсюда.

Важно! Если в организации уже есть работающий PostgreSQL-сервер, приспособить его под SaltStack можно, руководствуясь этим гайдом .

Версионность Salt

SaltStack Config совместим с большинством версий Salt, но крайне рекомендуется, в любом случае, пользоваться самой последней его версией.

Важно! Если планируется использовать аддон SaltStack Comply с серверами Windows, Windows-миньоны должны быть на Salt 3000 и свежее.

Требования к сети

Ключевым требованием по сети в отношении имплементации SaltStack является ее выход в интернет. Однако, некоторые сети (air-gapped system) не обладают таким постоянным доступом по ряду специфических причин. С ними масса сложностей, причем не только в процессе начальной инсталляции, но и впоследствии – в обеспечении актуальности SaltStack Config. Чтобы избежать их, рекомендуется обратиться в службу поддержки.

Важно! Хосты Redis и PostgreSQL БД требуют статические IP-адреса или DNS-имена, и они должны найти отражение в конфигурационных файлах. Динамическая адресация может непоправимо изменить среду и привести к ее краху.

Требования к браузеру

Пользовательский интерфейс SaltStack Conf поддерживает последние версии Google Chrome и Mozilla Firefox.

Лицензирование

Для SaltStack Conf доступна 14-дневная триальная лицензия. По истечению этого срока, все сервисы RaaS станут неактивными, поэтому надо позаботиться о том, чтобы после установки файл с лицензией был помещен на RaaS-ноду в «/etc/raas/raas.license». Как это делать – поучимся ниже в разделе пост-инсталляционных задач. Сейчас лишь заметим, что нужный файл приходит в приветственном письме от саппорта продукта.

Подготовка к развороту и использованию SaltStack Config

Внедрение SaltStack – процесс многоэтапный, и, обычно, для достижения успеха в него включаются следующие шаги:

Разработка и верификация планируемой архитектуры SaltStack Config, предваряющие установку планирование и подготовка;
Трансфер и импорт файлов, необходимых в процессе инсталляции;
Процедура инсталляции/апгрейда (одно-нодовая или мульти-нодная);
Пост-инсталляционные задачи:

- установка лицензионного ключа,
- установка и настройка Master Plugin,
- первый вход и смена дефолтных учетных данных,
- соглашение с мастер-ключом Salt и бэкапирование данных,
- установка SSL-сертификатов,
- настройка SaltStack Comply (опционально),
- настройка Salt Stack Protect (опционально),
- интеграция Splunk (опционально),
- установка SSO(опционально).

Что касается этапов подготовки к инсталляции, для начала нам нужно определиться с тем, какой из сценариев имплементации является оптимальным для нашей сети. Затем рассчитывается hardware и софт, в т. ч., сколько нод нам нужно выделить, какая на них будет ОС и т. д., готовится сеть (в частности, проверяется ее доступ в интернет). И, наконец, загружаются инсталляционные файлы отсюда:

если будем делать все из vRealize Suite Lifecycle Manager. Или отсюда. Здесь можно найти все для установки или обновления SaltStack Config, в т. ч. аддоны SaltStack Comply и SaltStack Protect, а также SecOps Compliance Custom Content SDK и дополнительные файлы. Учтите, что одни и те же файлы идут как под одно-нодовый сценарий, так и под мульти-нодовый.

Касаемо инсталляционных файлов, их нужно поместить в корневую папку вовлеченных в процесс нод. Для одно-нодового сценария их трансфер следует осуществить на ноду, где будут проинсталлированы все компоненты: Salt master, SaltStack Config, Redis и PostgreSQL. При мульти-нодовой установке, файлы следует скопировать только на мастер-ноду.

Важно! Если используем «.zip», файлы инсталлятора нужно извлечь (туда же). Для этого в терминале устанавливаем приложение для извлечения файлов (если еще нет):

sudo yum install unzip

И выполняем непосредственно извлечение:

unzip SaltStack_Enterprise-_Installer.zip

Еще обязательно нужно выписать ID миньонов. Это – уникальное имя, по которому миньоны идентифицируют себя по отношению к мастеру. По дефолту они опираются на имя хоста системы, однако можно назначать и пользовательские, описывающие какие-то функции или местоположение в сети. Ниже, мы поучимся присваивать миньонам пользовательские ID, если появится такое желание. Заметим, операция доступна исключительно при мульти-нодовом сценарии.

Апгрейд и/или инсталляция Salt и Python

Важно! Актуальные пакеты SaltStack Config несут на борту собственный Python версии 3.7, причем он автономен и не затрагивает тот, которым вы пользовались до интеграции технологии, не требуя, в том числе и его обновление. Но, конечно же, рекомендуется держать у себя только последнюю версию Python.

Вообще же текущему релизу SaltStack Config требуется Python, не древнее 3.5.3. Чтобы проверить версионность на RedHat и CentOS, запускаем в терминале на интересующей ноде:

python3 –version

Если нужно обновить, используем команду:

sudo yum upgrade python3

Без Salt наш SaltStack Config, по понятным причинам, не существует. Он должен быть проинсталлирован на нодах, вовлеченных в процесс начальной интеграции SaltStack Config, независимо от выбранного сценария развертывания, но, впоследствии, может случиться, что потребуется от случая к случаю подключать к управлению решением другую инфраструктуру – и вот на ней потребуется прямая установка Salt. И здесь нет других вариантов, кроме как вначале установить Salt на этой инфраструктуре, а потом уже назначать ее взаимодействие с текущим разворотом.

Единственным исключением являются air-gapped-системы (упоминались выше). Так как доступа в интернет они не имеют и автоматическое обновление Salt для них недоступно, придется все делать вручную. Нужную версию можно отыскать в пакете Salt Crystal – именно он является жизненно важным при имплементации SaltStack Config в общем смысле. Механизм очень простой:

Пакет Salt Crystal помещается в корневую папку мастер-ноды;
Инсталлятор SaltStack Config проверяет наличие сервисных пакетов Salt-мастера и Salt-миньонов. Если обнаруживает, просто идет дальше, если же нет – устанавливает эти сервисы из пакета Salt Crystal.

Но, именно в air-gapped-системах крайне рекомендуется устанавливать Salt заранее, а не с помощью Salt Crystal, так как невозможность регулярного его обновления через интернет может стать серьезной проблемой для такой специфической сети.

Если же речь не идет об ограничении доступа в интернет, проапдейтить Salt можно командами:

sudo yum install https://repo.ius.io/ius-release-el7.rpm https://dl.fedoraproject. ,→org/pub/epel/epel-release-latest-7.noarch.rpm

sudo yum install python36-pyOpenSSL

После чего требуется перезапуск обновленных сервисов:

sudo systemctl restart salt-minion

Полезную информацию, касающуюся апгрейда Salt на других ОС можно найти здесь.

А установить его с нуля на мастер-ноде:

sudo yum install https://repo.saltstack.com/py3/redhat/salt-py3-repo-latest.el7. ,→noarch.rpm

Этот скрипт установит последнюю версию Salt на Redhat/Centos 7 PY3. Если система другая, скрипт не заработает. Чтобы поставить ее на других системах, обратитесь к рекомендациям отсюда.

После этого нужно очистить кэш:

sudo yum clean expire-cache

И проинсталлировать сервисы salt-master и salt-minion на мастер-ноде:

sudo yum install salt-master

sudo yum install salt-minion

Теперь нужно отредактировать файл «master.conf» из директории «/etc/salt/minion» с целью установить указание на самое себя IP-адреса мастера:

master: localhost

И запустить эти сервисы:

sudo systemctl start salt-master

sudo systemctl enable salt-minion

sudo systemctl start salt-minion

Для перезапуска миньонов вводим:

service salt-minion restart

Если у нас одно-нодовый сценарий, на этом останавливаемся. Если работаем с мульти-нодовой конфигурацией, после инсталляции Salt на мастере устанавливаем сервис salt-minion на остальных трех нодах:

sudo yum install salt-minion

(отвечаем «y» на все вопросы). Затем устанавливаем связь каждого миньона с мастером, редактируя в директории «/etc/ salt/minion» файл «master.conf», где прописываем IP мастера, например:

master: 192.0.2.1

Теперь запускаем сервис salt-minion:

sudo systemctl enable salt-minion

sudo systemctl start salt-minion

Перезапускаем миньонов командой:

service salt-minion restart

Повторяем все шаги для каждой ноды.

Присвоение пользовательского ID миньонам

В терминале миньона проходим в директорию «etc/salt/minion.d», содержащую файл «id.conf», и открываем его на редактирование. Находим соответствующую строчку и меняем ее, например, вот так:

id: postgres-database-1

После этого ключи миньона нужно принять (или перепринять) на мастере. Для этого в терминале мастера, выводим список всех ключей, которые есть на мастере:

salt-key –L

Проверяем, выведены ли новые ID миньонов в «Unaccepted keys» (если они уже в «Accepted keys», дальнейшие действия пропускаем). Далее вводим команду:

salt-key –a <minion-ID>

Эта операция примет все ключи по тому или иному миньону. На все вопросы отвечаем «y». Для проверки, все ли получилось, запускаем команду:

salt-key –L

– ключи должны появиться в «Accepted keys».

Инсталляция зависимостей инсталлятора SaltStack Config

SaltStack Config нуждается в нескольких важных пакетах:

OpenSSL,
Extra Packages для Enterprise Linux (EPEL),
Python cryptography,
Python OpenSSL библиотеке.

При одно-нодовой инсталляции все зависимости нужно установить на хосте мастера, а при мульти-нодовой – на всех нодах компонентов. В противном случае инсталлятор SaltStack Config не пойдет.

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

sudo yum list installed | grep openssl

sudo yum list installed | grep epel-release

sudo yum list installed | grep python36-cryptography

sudo yum list installed | grep python36-pyOpenSSL

Если ответ отрицательный, устанавливаем их:

sudo yum install openssl

sudo yum install epel-release -y

sudo yum install python36-cryptography

sudo yum install python36-pyOpenSSL

Важно! Предварительно должен быть установлен пакет «python36-pyOpenSSL». Конфигурировать SSL будем учиться позднее.

Сеть

Перед установкой SaltStack важно убедиться, что открыт порт 443 на файерволе для всех соответствующих систем (для мастеров, пользовательских веб-интерфейсов, удаленных систем вызова API (RaaS) и т. д.). Так как сам скрипт инсталлятора правила файервола не модифицирует.

При мульти-нодовой инсталляции нужны такие порты для следующих нод:

Нода	Дефолтный порт	Кем применяется
PostgreSQL	5432	eAPI-сервера
Redis	6379	eAPI-сервера
eAPI конечные точки	443	Мастера, веб-интерфейсы пользователей, удаленные системы вызова Enterprise API
Мастера	4505/4506	Все миньоны, настроенные на использование связанного мастера

Также нужно выписать себе IP-адреса или имена DNS нод, которые будут вовлечены в процесс инсталляции. Для нод баз данных адреса должны быть статическими обязательно, под RaaS тоже желательно выделить аналогичного типа, так как динамическая адресация может изменить и разрушить построенную среду – на этом мы уже акцентировали внимание выше.

Важно! Если речь о виртуализированной среде, адрес должен быть внутренним, а не публичным.

Верификация файлов инсталлятора

Хорошей практикой считается проверка загруженных на вовлеченные в процесс ноды файлов инсталлятора. Валидация заключается в сравнении SHA-256 хэша с тем, что в списке в таблице загрузок. На практике делаем следующее (RedHat/CentOS):

На машине с этими файлами открываем терминал и проходим в директорию, их содержащую;
Используем «ls», чтобы вывести список точных имен файлов;
Вводим команду, перемещающую точное имя файла:

sha256sum file-name.zip

Она возвращает SHA-256 для файла;

Сравниваем вывод с SHA-256 таблицы.

Импорт «.asc»-файлов ключей

Существует необходимость импортирования файлов ключей «.asc» из инсталлятора SaltStack Config в упаковочную систему RPM. Для этого проходим в директорию «sse-installer» на ноде, где будут инсталлироваться компоненты SaltStack Config, и запускаем команду:

sudo rpmkeys –import keys/*.asc

Повторяем это для всех нод.

Разворот SaltStack

В случае, когда целевые машины не могут подключиться к интернету для автоматического получения правильных публичных ключей (даже несмотря на то, что они могут быть настроены для валидации сигнатур RPM-пакетов) – эти ключи можно найти в составе «.zip»-файла инсталлятора. Вот, собственно, они, с каноническими местонахождениями:

Имя ключа	ID ключа	Локация
Fedora EPEL	352C64E5	https://getfedora.org/static/keys/352C64E5.txt
IUS Community Project	9CD4953F	https://dl.iuscommunity.org/pub/IUS-COMMUNITY-GPG-KEY
PostgreSQL Global Dev Group	442DF0F8	https://download.postgresql.org/pub/repos/yum/RPM-GPG-KEY-PGDG-96
SaltStack Packaging Team	DE57BFBE	https://repo.saltstack.com/yum/redhat/7/x86_64/3000/ SALTSTACK-GPG-KEY.pub

Инсталляция в одно-нодовом сценарии

Для запуска скрипта инсталляции в терминале вводим команду:

sudo ./setup_single_node.sh

Должно появится сообщение вида (может висеть несколько минут):

Installing SaltStack Enterprise…

Во время отработки этого скрипта поставится последняя стабильная версия Python и Salt, если ранее их не было, а нода будет сконфигурирована как мастер и миньон. Затем он займется БД PostgreSQL и Redis, а также RaaS.

Инсталляция в мульти-нодовом сценарии

В этом случае используется высокоуровневая оркестровка, запускаемая на мастере и устанавливающая самостоятельно мульти-нодовую среду в виде ядра архитектуры SaltStack на трех других нодах. Учтите, что даже если предварительно был разработан дизайн структуры с несколькими мастерами, вначале все равно начинаем ставить с одного первого, а далее – по проторенной дорожке.

В итоге мы получим 4 ноды, каждую – со своим функционалом.

На деле это будет выглядеть так. Копируем и редактируем конфигурационные файлы оркестровки:

На мастере заходим в директорию «sse-installer» и копируем опорный файл и файл состояния из этой директории на «pillar_roots» и «file_roots» миньона:

sudo mkdir /srv/salt

sudo cp -r salt/sse /srv/salt/

sudo mkdir /srv/pillar

sudo cp -r pillar/sse /srv/pillar/

sudo cp -r pillar/top.sls /srv/pillar/

sudo cp -r salt/top.sls /srv/salt/

Теперь в директории «/srv/pillar/» будет файл «top.sls»;

Открываем его в редакторе, чтобы определить список ID миньонов (не IP-адреса или DNS-имена) для всех функциональных нод (эти ID мы записывали ранее – в процессе подготовки), например, вот так:

{# Pillar Top File #}

{# Define SSE Servers #}

{% load_yaml as sse_servers %}

– postgres-database-1

– redis-database-1

– saltstack-enterprise-api-server-1

– saltmaster-1

{% endload %}

base:

{# Assign Pillar Data to SSE Servers #}

{% for server in sse_servers %}

‘{{ server }}’:

– sse

{% endfor %}

Также в этом файле должно быть следующее:

base:

{# Target SSE Servers, according to Pillar data #}

# SSE PostgreSQL Server

‘I@sse_pg_server:{{ grains.id }}’:

– sse.eapi_database

# SSE Redis Server

‘I@sse_redis_server:{{ grains.id }}’:

– sse.eapi_cache

# SSE eAPI Servers

‘I@sse_eapi_servers:{{ grains.id }}’:

– sse.eapi_service

# SSE Salt Masters

‘I@sse_salt_masters:{{ grains.id }}’:

– sse.eapi_plugin

Теперь нам нужно отредактировать настройки опорного файла SaltStack Config в пяти разных секциях сопоставления параметров. Они будут использоваться в файлах конфигурации состояния для разворота и управления развертыванием SaltStack Config. Чтобы скопировать и отредактировать настройки файла состояния:

На мастере проходим в директорию «/srv/pillar/sse/» и открываем на редактирование файл «sse_settings.yaml». В его первой секции будут четыре переменные, соответствующие четырем нодам – их меняем на ID миньонов, соответственно, например, вот так:

# PostgreSQL Server (Single value)

pg_server: postgres-database-1

# Redis Server (Single value)

redis_server: redis-database-1

# SaltStack Enterprise Servers (List one or more)

eapi_servers:

– saltstack-enterprise-api-server-1

# Salt Masters (List one or more)

salt_masters:

– saltmaster-1

Во второй секции редактируем переменные с целью указать конечные точки и порт ноды PostgreSQL:

«pg_endpoint» – здесь меняем значение IP или DNS нашей PostgreSQL;

«pg_port» – здесь будет указан стандартный порт PostgreSQL (при желании можно изменить);

«pg_username» и «pg_password» – здесь вводим данные учетной записи пользователя, который будет использовать API (RaaS) для аутентификации в PostgreSQL (этот пользователь создался, когда запускалась высокоуровневая оркестровка);

Важно! Переменная указывается как «pg_endpoint», так как в некоторых установках может быть настроен отдельный PostgreSQL-сервер (или кластер), не управляемый этим процессом установки. В этом случае не следует применять highstate к серверу PostgreSQL при «Apply» highstate к нодам на более позднем этапе установки.

Повторяем п. 2 при редактировании секции № 3 файла, но, указываем все уже для ноды Redis;
В секции 4 редактируем переменные, касающиеся ноды RaaS.

Важно! Если это первая установка SaltStack ни в коем случае не меняем дефолтные значения переменных «eapi_username» и «eapi_password» – при необходимости поменяем пароль позднее, в операциях пост-инсталляции.

Для переменной «eapi_endpoint» меняем значение IP-адреса или DNS ноды RaaS (переменная указана именно таким образом, так как некоторые инсталляции могут хостить множество eAPI-серверов за балансировщиком нагрузки);

Значение переменных «eapi_ssl_enabled» («True»), «eapi_standalone» («False») и «eapi_failover_master» («False») оставляем по дефолту;

Переменная «eapi_key» определяет ключ шифрования, который использует SaltStack Config для управления зашифрованными данными в БД PostgreSQL. Под каждую инсталляцию этот ключ должен быть уникальным. Предоставляется дефолтный, но можно сгенерировать и пользовательский, запустив в отдельном терминале вне редактора команду:

openssl rand -hex 32

В секции 5 редактируем переменные, чтобы добавить уникальные пользовательские идентификаторы:

Переменная «customer_id» уникально идентифицирует разворот SaltStack и становится суффиксом имени схемы БД raas_** (API (RaaS)) в PostgreSQL. Сейчас в файле дефолтное ее значение, но можно проставить пользовательское, сгенерировав ключ в отдельном терминале вне редактора командой:

cat /proc/sys/kernel/random/uuid

Переменная «cluster_id» определяет ID для набора мастеров, если он настроен либо в Active, либо Failover Multi-Master-режиме. Он предотвращает возможность миньонов отвечать множество раз черезSaltStack Config, если они должны общаться со многими мастерами.

Сохраняем настройки.

Теперь нам нужно применить highstate к нодам. Это означает обновление системных данных и запуск оркестровки, которая настроит все компоненты SaltStack Config. Для этого:

На мастере синхронизируем зерна для подтверждения того, что у мастера есть все данные зерен по каждому миньону (убедимся, что опорные данные правильно сгенерировались для функциональности SaltStack Config), командой по всем миньонам:

sudo salt \* saltutil.refresh_grains

или по целевому их списку:

sudo salt -L ‘salt-master-1,postgres-database-1,redis-database-1, ,→saltstack-enterprise-api-server-1’ saltutil.refresh_grains

Обновляем данные опоры для всех миньонов:

sudo salt \* saltutil.refresh_pillar

или для списка конкретных:

sudo salt -L ‘salt-master-1,postgres-database-1,redis-database-1, ,→saltstack-enterprise-api-server-1’ saltutil.refresh_pillar

Это поможет подтвердить, что все миньоны получили опорные данные, определенные в файле «sse_settings. yaml» и они отобразились, как надо;

Подтверждаем, что возвратные данные для нашей опоры корректны:

sudo salt \* pillar.items

Запускаем команду, которая применяет высокоуровневую оркестровку к PostgreSQL-серверу (используем ID миньона, выписанного ранее для PostgreSQL-сервера):

sudo salt postgres-database-1 state.highstate

Повторяем п. 4 для нод Redis, RaaS и мастера.

Важно! При первом применении highstate к мастеру может появиться ошибка вида: «Authentication error occurred». Это происходит потому, что мастер пока не аутентифицировал ноду RaaS, однако состояние инсталляции Master Plugin перезапустит сервис salt-master и проблема решится автоматически.

Кластеризация RaaS

Чтобы несколько RaaS-нод могли совместно использовать одну PostgreSQL базу данных и одну – Redis, в их организации применяется метод кластеризации. Здесь есть несколько важных моментов. Во-первых, помимо актуальности доступа к единой PostgreSQL БД, объединенные в кластер ноды должны разделять общее пространство ключей. Во-вторых, им вменяется использовать одинаковые файлы «/etc/raas/pki/.raas.key» и «/etc/raas/raas.secconf».

Сам же процесс довольно прост. Вначале нужно проинсталлировать две отдельные RaaS-ноды по одно-нодовому сценарию каждую. В результате у каждой из них будет своя локальная версия PostgreSQL и Redis. Теперь на первой ноде останавливаем сервисы Redis и PostgreSQL командами:

systemctl stop raas

systemctl stop redis

systemctl stop postgresql-12

Апдейтим на ней же наш файл «postgresql pg_hba.conf», чтобы позволить удаленное соединение с другой RaaS-ноды. Чтобы разрешить такие соединения добавляем в этот файл строку:

# Allow connection from RaaS 2

host all all 127.31.4.137/32 trust

заменив IP на IP второй ноды.

Теперь обновляем файл «r /etc/redis.conf», чтобы позволить привязку ко всем интерфейсам (по дефолту привязка существует только к локальному хосту), добавив в него:

#bind 127.0.0.1

Запускаем сервисы и проверяем их статус командами:

systemctl start postgresql-12

systemctl status postgresql-12

systemctl start redis

systemctl status redis

systemctl start raas

systemctl status raas

Пробуем зайти в UI SaltStack Config через URL первой ноды, чтобы убедиться, что она работает нормально.

Теперь переходим к настройке второй ноды, чтобы добиться ее совместной работы с первой. На ней останавливаем сервисы RaaS, Redis и PostgreSQL:

systemctl stop raas

systemctl stop redis

systemctl stop postgresql-12

Обновляем ее файл «e /etc/raas/raas», проследив, чтобы настройка «customer_id» была одинаковой для обеих, например, вот так:

customer_id: 43cab1f4-de60-4ab1-85b5-1d883c5c5d09

sql:

dialect: postgresql

host: 172.31.8.237

port: 5432

driver: psycopg2

ssl: True

redis:

url: redis://172.31.8.237:6379

Копируем «/etc/raas/pki/.raas.key» и «/etc/raas/secconf» с первой ноды на вторую, охватив доступ и разрешения, как в этом примере:

# ls -l /etc/raas/raas.secconf

-rw——-. 1 raas raas 313 Jan 21 17:21 /etc/raas/raas.secconf

# ls -l /etc/raas/pki/.raas.key

-rwx——. 1 raas raas 77 Jan 21 17:17 /etc/raas/pki/.raas.key

Осталось запустить сервис RaaS и убедиться, что его статус правильный, командами:

systemctl start raas

systemctl status raas

Теперь заходим в UI SaltStack Config через URL второй ноды, чтобы убедиться, что все работает правильно и на ней.

Установка SaltStack Config через vLCM

Можно ставить SaltStack через vLCM. Правда, при этом мы имеем дело исключительно с одно-нодовой конфигурацией и недоступны опции вертикального масштабирования. Чтобы добиться интеграции с vRA, частью которой SaltStack Config, начиная с версии 8.3.0 и является, вначале с помощью vLCM устанавливается vRA. Одновременно с интеграцией SaltStack Config с vRA устанавливается мастер Salt и происходит настройка необходимой группы свойств в vRA. Если в этом случае не включена мульти-тенантность, инстанс SaltStack ассоциируется с базовым тенантом vRA. Когда же мульти-тенантность настроена, SaltStack Config ассоциируется с новыми добавленными тенантами и после этого продолжает инсталляцию. При импорте тенантов vRA, ассоциированные с ними инстансы SaltStack Config также импортируются.

Установка vRealize Automation SaltStack Config начинается с выбора этого продукта для новой инсталляции в «Product Details» визарда vLCM (см. нашу предыдущую статью из серии автоматизации виртуализации «Разворот и базовая настройка VMware vRealize Automation 8.3»). Далее в «Product Properties» выбираем «Tenant ID» из выпадающего меню, а в «Components» вводим имя виртуальной машины, FQDN и VIP. Важно помнить, что интеграция SaltStack Config должна получить ассоциацию с указанным хостом еще в процессе инсталляции.

Каждый тенант vRA поддерживает одну интеграцию SaltStack Config и одного Salt-мастера, при этом мастер может поддерживать множество миньонов:

Важно! Интеграция SaltStack Config, в отличии от других типов интеграций vRA, не может разворачиваться из UI автоматизации путем выбора «Infrastructure» – «Connections» – «Integrations» – «Add Integration» – только через vLCM.

Сама инсталляция, естественно, производится под учетной записью администратора vRA и под уровнем рута в SaltStack Config. Также необходим будет доступ под правами сервис-администратора в Cloud Assembly. Существует два ее метода:

Из UI vRA через встроенный механизм адаптации интеграций;
Импорт специально созданного и подготовленного облачного шаблона.

Интеграция SaltStack Config через Cloud Assembly

Для начала нам нужно добавить SaltStack Config в набор сервисов vRA. Для этого заходим в vLCM в «Environments» бокового меню. Далее кликаем правой кнопкой и в появившемся выпадающем меню выбираем «Add Product»:

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

Либо же заходим в интерфейс компонента Cloud Assembly и на вкладке «Infrastructure» в боковом меню выбираем «Integrations» под «Connections». Справа увидим готовый тайтл под «SaltStack Config», внизу которого нажимаем на «Open»:

Заполняем появившуюся форму:

введя информативное описание (имя интеграции, как и имя хоста, мы заводили еще при инсталляции продукта через vLCM), имя пользователя с правами администратора и пароль (работающие для указанного хоста). Теперь нужно кликнуть на «Validate», чтобы проверить валидность доступа, и опционально можно ввести теги возможностей, после чего сохранить все по «Save».

Если все прошло успешно, интеграция SaltStack Config появится не только на странице интеграций («Integrations»), но и будет доступна с сервисной консоли vRA:

Первый вход в нее запросит данные учетной записи администратора:

После чего можно полноценно пользоваться функционалом SaltStack Config через удобный UI:

Интеграция SaltStack Config через облачный шаблон

В качестве альтернативы разработан удобный и достаточно несложный облачный шаблон для получения сетапа Salt Master и миньона. Он просто импортируется прямо в vRA, либо же предложенный код YAML вставляется в новый облачный шаблон. Вот, собственно, его пример:

formatVersion:

inputs:

user:

type: string

title: Username for SSH

description: The username you would like to have for the installation.

default: demouser

password:

type: string

pattern: ‘[a-z0-9A-Z@#$]+’

encrypted: true

default: VMware123

title: Admin Account Password

description: The password you would like to use for the System.

saltmasterhostname:

type: string

title: Salt Master Hostname

saltminionhostname:

type: string

title: Salt Minion Hostname

resources:

Salt-Minion:

type: Cloud.Machine

dependsOn:

– Salt-Master

properties:

image: Ubuntu-18

flavor: medium

constraints:

– tag: ‘env:vsphere’

cloudConfig: |

#cloud-config

hostname: ${input.saltminionhostname}

users:

– name: ${input.user}

sudo: [‘ALL=(ALL) NOPASSWD:ALL’]

groups: sudo

shell: /bin/bash

runcmd:

– PASS=${input.password}

– USER=${input.user}

– echo $USER:$PASS | /usr/sbin/chpasswd

– sed -i “s/PasswordAuthentication no/PasswordAuthentication yes/g” /etc/ssh/sshd_config

– service ssh reload

– curl -L https://bootstrap.saltstack.com -o install_salt.sh

– sudo sh install_salt.sh -A ${resource.Salt-Master.address}

networks:

– network: ‘${resource.Cloud_Network_1.id}’

Salt-Master:

type: Cloud.Machine

properties:

image: Ubuntu-18

flavor: medium

constraints:

– tag: ‘env:vsphere’

cloudConfig: |

#cloud-config

hostname: ${input.saltmasterhostname}

users:

– name: ${input.user}

sudo: [‘ALL=(ALL) NOPASSWD:ALL’]

groups: sudo

shell: /bin/bash

runcmd:

– PASS=${input.password}

– USER=${input.user}

– echo $USER:$PASS | /usr/sbin/chpasswd

– sed -i “s/PasswordAuthentication no/PasswordAuthentication yes/g” /etc/ssh/sshd_config

– service ssh reload

– curl -L https://bootstrap.saltstack.com -o install_salt.sh

– sudo sh install_salt.sh -M

networks:

– network: ‘${resource.Cloud_Network_1.id}’

Cloud_Network_1:

type: Cloud.Network

properties:

constraints:

– tag: ‘env:vsphere’

networkType: existing

Как только он будет загружен, в UI он получит, примерно, такой вид:

По итогу у нас в наличии две ВМ и единая сеть. Одна из машин – это Salt Master, работающий на демоне Salt и посылающий команды миньонам. Миньоны, в свою очередь, это сервера, запускаемые этим же демоном, и слушающие команды от мастера. Учтите, что здесь есть несколько вводов имен пользователей, паролей, имен хостов и т.д. На них будут запросы в процессе разворота. Также можно изменить YAML, при желании, чтобы отразить ограничения по размещению ВМ и идентификации сети.

Следующим шагом будет нажатие кнопки «Deploy» вверху экрана, либо же публикация этого облачного шаблона в каталоге Service Broker и создание тайтла для самообслуживания, например, вот такого:

Если нажать на «Request», появится окно для ввода нового запроса, в котором нужно будет заполнить все поля:

По окончанию разворота, если кликнуть на Deployment Tile, можно попасть в его детали. На вкладке «Topology» увидим две ВМ и сеть:

Теперь можно зайти по SSH в мастер Salt, чтобы настроить его для запуска команд миньонам. В первую очередь нас попросят принять ключ (команда «salt-key –accept-all»:

вот так, примерно, будет выглядеть вывод). Чтобы проверить связь, вводим команду пингования миньона с мастера: «salt ‘*’ test.ping». А вот ее вывод:

После этого интеграцию SaltStack Config во vRA можно считать завершенной и приступать к ее использованию.

Пост-инсталляционные операции

Как уже упоминалось выше в «Подготовке», когда мы планировали всю предстоящую работу по имплементации SaltStack Config, после инсталляции по выбранному сценарию нам нужно установить лицензионный ключ, поставить и настроить Master Plugin, войти в первый раз и изменить дефолтные данные учетной записи, принять ключ для мастера и данные бэкапирования и установить SSL-сертификаты. Еще опционально можно настроить SaltStack Comply и SaltStack Protect, установить интеграцию Splunk и SSO.

Установка лицензионного ключа

При развороте RaaS-ноды нужно добавить лицензионный ключ в папку «/etc/raas». После этого следует установить владельца файла в пользователях «raas» следующим образом:

sudo chown raas:raas /etc/raas/raas.license

sudo chmod 400 /etc/raas/raas.license

Установка и настройка Master Plugin

Все, что нужно знать о Master Plugin, можно почерпнуть из подраздела «Архитектура» выше. Обычно, он устанавливается на каждом связывающемся с SaltStack Config мастере среды, если речь о мульти-нодовом сценарии с несколькими мастерами. В случае единственной ноды, несущей на себе все компоненты, или одиночного мульти-нодового разворота (с одним мастером) инсталлятор автоматически устанавливает Master Plugin на мастере.

При нескольких мастерах в среде может понадобиться вручную проинсталлировать Master Plugin. Для этого:

Заходим на наш мастер (если нужно, загружаем механизм Master Plugin – найти можно там же в загрузках, все описывалось выше в разделе «Подготовка…»);
На RHEL/CentOS запускаем команду:

sudo pip3 install SSEAPE-file-name.whl –prefix /usr

На Ubuntu:

sudo pip3 install SSEAPE-file-name.whl

Важно! Иногда синтаксис конкретной ОС может потребовать «pip3.6» или «pip36».

Для настройки Master Plugin заходим на наш мастер и убеждаемся, что существует директория «/etc/salt/master.d» (либо ее следует создать специально). Затем генерируем параметры конфигурации мастера командой:

sudo sseapi-config –all > /etc/salt/master.d/raas.conf

Теперь нужно отредактировать сгенерированный файл «raas.conf» и обновить значения с целью валидации пользователей сертификата API (RaaS) и установки его IP-адреса таким образом:

Параметр «sseapi_ssl_validate_cert» валидирует сертификат пользователя API (RaaS). По дефолту здесь «True». Если нужно установить свой собственный СА-сертификат, настраиваются параметры «sseapi_ssl_ca, sseapi_ssl_cert» и «sseapi_ssl_cert:»;
Параметр «sseapi_server» – задается HTTP IP-адрес ноды RaaS;
Параметр «sseapi_command_age_limit» – проставляется возраст (в секундах), после которого потенциально стабильные задания пропускаются. Например, вот так:

sseapi_command_age_limit: 86400

если нужно пропускать задания, старше одного дня. Пропущенные задания продолжат существовать в базе данных и показываться со статусом «Completed» в UI SaltStack Config.

Важно! В некоторых средах необходимо, чтобы мастер находился в оффлайне длительные периоды времени, но, когда он вернется, ему придется запустить все поставленные в очередь задания. В этом случае рекомендуется устанавливать по этому параметру значение «0».

Теперь перезапускаем сервис salt-master командой:

sudo systemctl restart salt-master

Чтобы проверить, включил ли Master Plugin связь между мастером и нодой RaaS, можно запустить тестовую задачу:

salt -v ‘*’ test.ping

Изменение пароля дефолтной учетной записи

Заходим в UI SaltStack Config через браузер, вбив в адресную строку адрес IP ноды RaaS или ее DNS имя. Дефолтное имя пользователя – «root», а пароль – «salt».

Чтобы поменять пароль, в верхней навигационной панели слева кликаем на три вертикальные точки (меню), выбираем «Administration» и заходим на вкладку «Local Users». В боковом меню нажимаем на «root» и в рабочем поле в «Password» вводим новый пароль и такой же – строчкой ниже для подтверждения. Сохраняем настройку «Save».

Принятие ключа Salt master и бэкапирование данных

В процессе установки мастера генерируется файл публичного ключа. Если его не принять, мастер будет запускаться, но связь с нодой RaaS будет потеряна. Для этого заходим в UI SaltStack Config и в верхней навигационной панели нажимаем на три вертикальные точки (меню), выбираем «Administration» и заходим на вкладку «Master Keys». Из бокового меню выбираем «Pending», чтобы показало список ожидающих принятия мастер-ключей:

Ставим галочку напротив нужного ключа и затем нажимаем на кнопку «Accept Key». После этого появится предупреждение, что у нас еще есть непринятые ключи – это ключи миньонов, и чтобы их принять, переходим на вкладку «Minion Keys», выбираем в левой панели так же «Pending», ставим галочки напротив конкретных ключей и нажимаем на «Accept Key».

Последнее действие переведет миньонов на вкладку «Accepted» и их рабочее пространство станет доступным.

Теперь нам нужно удалить опорный top-файл, созданный в процессе инсталляции. Это важно сделать, так как в противном случае данные содержания этого файла могут генерироваться вновь и вновь при каждом обновлении опорных данных в будущем, что очень плохо.

Важно! Удалять top-файл можно только после первого успешного входа в пользовательский интерфейс.

И, наконец, переходим к бэкапированию критически важных данных – это актуально, если не используется полное решение системного бэкапирования, которое может восстановить сервер SaltStack Config целиком. Вот список важнейших файлов, которые нуждаются в сохранении:

/etc/raas/pki (директория, содержащая скрытый файл «.raas.key», используемый в шифровании данных в состоянии покоя в БД);

/etc/raas/raas (содержит данные конфигурации SaltStack Config);

/etc/raas/raas.secconf (содержит данные конфигурации SaltStack Config);

Также нужно сделать бэкап базы данных RaaS, настроив регулярные бэкапы для PostgreSQL.

Установка SSL-сертификатов

Важно! Пакет «python36-pyOpenSSL» жизненно необходим.

Для создания SSL-сертификатов создаем и устанавливаем разрешения для папки сертификата в сервисе RaaS:

sudo mkdir -p /etc/raas/pki

sudo chown raas:raas /etc/raas/pki

sudo chmod 750 /etc/raas/pki

Создаем ключи с помощью Salt или предоставляем собственные:

sudo salt-call –local tls.create_self_signed_cert tls_dir=raas

sudo chown raas:raas /etc/pki/raas/certs/localhost.crt

sudo chown raas:raas /etc/pki/raas/certs/localhost.key

sudo chmod 400 /etc/pki/raas/certs/localhost.crt

sudo chmod 400 /etc/pki/raas/certs/localhost.key

Чтобы включить связь по SSL к UI SaltStack Config, создаем PEM-зашифрованный сертификат (либо убеждаемся, что такой уже существует и доступен).

Сохраняем файлы «.crt» и «.key» в «/etc/pki/raas/certs» RaaS-ноды и обновляем конфигурацию сервиса RaaS, открыв на редактирование «/etc/raas/raas»:

tls_crt: /etc/pki/raas/certs/<filename>.crt

tls_key: /etc/pki/raas/certs/<filename>.key

port: 443

где <filename> – имя SSL-сертификата.

Теперь нам осталось перезапустить сервис RaaS:

sudo systemctl restart raas

И убедиться, что он запущен:

sudo systemctl status raas

Тестирование базового функционала

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

Чтобы импортировать этот пример контента, нужно на мастере или компьютере, куда загружались файлы инсталлятора, пройти в директорию «sse-installer/ salt/sse/eapi_service/files» и переместить файл «sample-resource-types.raas» на RaaS-ноду. Зайдя на RaaS-ноду, запускаем команду:

/usr/bin/raas-dump –insecure –server –auth : ,→ –mode import < /tmp/sample-resource-types.raas

Теперь, в UI, если пройдем в «Elements» – «Jobs», увидим, что некоторые примеры заданий появились в рабочем пространстве. Протестируем функционал:

Связь. Запустим команду «test.ping» на целевых миньонах, чтобы убедиться в успешности связи;
Включение присутствия миньонов. Это задание позволит более аккуратно обнаружить присутствие миньонов. Его полезно запускать на регулярной основе, чтобы получить уверенность в наделении статусом «Present» в целевых рабочих пространствах подключенных миньонов, а, значит, и в том, что SaltStack Config получает любые данные заданий с заданным интервалом. Механизм лежит в задании проинсталлировать Salt Beacon, посылающий периодические опросы с каждого миньона. Рекомендуется использовать его на всех миньонах. Чтобы его запустить, в UI заходим под правами superuser, кликаем на «Targets» и из бокового меню выбираем «All Minions». Нажимаем на «Run Job» и выбираем «Enable Presence».

Чтобы протестировать остальные доступные в примере контента функции, обращайтесь к гайду.

Подготовка к использованию SaltStack Comply

Об аддоне SaltStack Comply мы писали выше в теоретической информации о решении. Чтобы поработать с ним, для начала нам нужно проинсталлировать библиотеки Python 3 rpm. С этой целью запускаем команду:

yum install -y epel-release

для инсталляции репозитория EPEL. А затем и самой библиотеки Python 3 rpm:

yum install -y python3-rpm

В случае инсталляции SaltStack Config 8.3.0, и при одно-нодовой, и при мульти-нодовой организации, автоматический прием контента уже настроен и ничего больше делать не требуется. Если же была предпринята ручная инсталляция, для настройки автоматического приема контента нужно добавить в секцию «sec» конфигурационного файла сервиса RaaS «/etc/raas/raas» следующее:

sec: stats_snapshot_interval: 3600

username: secops

content_url: https://enterprise.saltstack.com/secops_downloads

ingest_saltstack_override: true

ingest_custom_override: true

locke_dir: locke

post_ingest_cleanup: true

download_enabled: true

download_frequency: 86400

compile_stats_interval: 10

archive_interval: 300

old_policy_file_lifespan: 2

delete_old_policy_files_interval: 86400

ingest_on_boot: true

content_lock_timeout: 60

content_lock_block_timeout: 120

и сохранить файл, после чего перезапустить сервис RaaS:

systemctl restart raas

Процесс может занять до 5 минут, в зависимости от качества связи.

Если нужен прием контента через http(s)-прокси, нужно дополнить сервис RaaS, добавив новые переменные среды для http proxy и https proxy. Для этого проделываем все, что описывалось только что для настройки автоматического приема, а затем на мастере вводим:

systemctl edit raas

И добавляем такие строки в сгенерированный файл:

[Service]

Environment=”http_proxy=http://:234″

Environment=”https_proxy=https://:234″

Environment=”HTTP_PROXY=http://:234″

Environment=”HTTPS_PROXY=http://:234″

Если прокси требует аутентификацию по паролю, в части переменных среды прокси должно быть такое:

Environment=”HTTP_PROXY=http://USER:PASSWORD@:234″

Если прокси использует внутреннюю СА, может потребоваться установка переменной среды «REQUESTS_CA_BUNDLE»:

Environment=”REQUESTS_CA_BUNDLE=/etc/pki/tls/certs/ca-bundle.crt”

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

В случае, когда контент приходится принимать вручную (Air-gapped API (RaaS) системы, в конфигурации назначено по параметру «sec/download_enabled = False»), нужно загрузить контент SaltStack Comply со страницы загрузок (ссылка была выше), зайти на ноду RaaS, скопировать тарбол контента SaltStack Comply на нее (рекомендуется tmp) и принять контент:

su – raas -c “raas ingest /path/to/locke.tar.gz.e”

Возврат при этом будет выглядеть так:

Extracting: /tmp/locke.tar.gz -> /tmp/extracted-1551290468.5497127

Cleaning up: /tmp/extracted-1551290468.5497127

Results:

{‘errors‘: [], ‘success‘: True}

Подготовка к использованию SaltStack Protect

Об аддоне SaltStack Protect мы писали выше в теоретической информации о решении. Чтобы начать с ним работу, инсталлируем библиотеки Python 3 rpm по рекомендациям, приведенным выше в подразделе «Настройка SaltStack Comply».

vman:

vman_dir: vman

download_enabled: true

download_frequency: 86400

username: vman

content_url: ‘https://enterprise.saltstack.com/vman_downloads’

ingest_on_boot: true

compile_stats_interval: 60

stats_snapshot_interval: 3600

old_policy_file_lifespan: 2

delete_old_policy_files_interval: 86400

tenable_asset_import_enabled: True

tenable_asset_import_grains: [‘fqdn’, ‘ipv4’, ‘ipv6’, ‘hostname’, ‘mac_address’, ,→ ‘netbios_name’, ‘bios_uuid’, ‘manufacturer_tpm_id’, ‘ssh_ ,→fingerprint’, ‘mcafee_epo_guid’, ‘mcafee_epo_agent_guid’, ,→’symantec_ep_hardware_key’, ‘qualys_asset_id’, ‘qualys_host_id’, ‘servicenow_ ,→sys_id’, ‘gcp_project_id’, ‘gcp_zone’, ‘gcp_instance_id’, ‘azure_vm_id’, ,→’azure_resource_id’, ‘aws_availability_zone’, ‘aws_ec2_instance_ami_id ,→’, ‘aws_ec2_instance_group_name’, ‘aws_ec2_instance_ ,→state_name’, ‘aws_ec2_instance_type’, ‘aws_ec2_name’, ‘aws_ec2_ ,→product_code’, ‘aws_owner_id’, ‘aws_region’, ‘aws_subnet_id’, ,→’aws_vpc_id’, ‘installed_software’, ‘bigfix_asset_id’ ]

Сохраняем файл и перезапускаем сервис RaaS:

systemctl restart raas

Что касается настройки приема контента через прокси – все аналогично случаю с SaltStack Comply.

В случае, когда контент приходится принимать вручную (Air-gapped API (RaaS) системы, в конфигурации назначено по параметру «vman/download_enabled = False»), нужно загрузить контент SaltStack Protect со страницы загрузок (ссылка была выше), зайти на ноду RaaS, скопировать тарбол контента SaltStack Protect на нее (рекомендуется tmp) и принять контент:

su – raas -c “raas vman_ingest /path/to/vman.tar.gz.e”

Это вернет:

Extracting: /tmp/vman.tar.gz -> /tmp/extracted-1551290468.5497127

Cleaning up: /tmp/extracted-1551290468.5497127

Results:

{‘errors’: [], ‘success’: True}

Установка интеграции со Splunk

В теоретической части Splunk мы внимания не уделяли, сконцентрировавшись на главных и жизненно важных функциях и компонентах SaltStack. Что ж, исправим этот недочет, ведь интеграция с ним помогает оптимизировать и сделать более безопасной свою цифровую инфраструктуру.

Splunk – это тоже аддон к SaltStack Config и его описание, а также опцию загрузки инсталлятора можно найти здесь. Он использует преимущества новой, совместимой с Prometheus конечной точки метрик, которая отвечает за более 25 уникальных метрик SaltStack Config. Эти метрики позволяют оценить здоровье инфраструктуры, и доступ к ним полезен для слежения за сбоями, выявления аномальной активности и прочих вещей. Кроме того, с помощью этого аддона можно выполнять некоторые автоматические действия, опирающиеся на определенное событие Splunk. О том, как инсталлировать и работать со Splunk написано в подробностях здесь.

Установка SSO

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

Сервисы директорий, использующие LDAP-протокол, в т. ч. AD,
SSO для IdP, который использует SAML или OAuth протоколы.

Исчерпывающие инструкции по вопросу их интеграции можно найти прямо во встроенном в UI SaltStack Config хелпере. Для доступа к нему нужно кликнуть на панели управления на «Help» – «Help Documentation» и выбрать, что конкретно интересует: «Authentication with SAML», «Authentication with LDAP» или «Authentication with OAuth and OIDC». Ниже, в секции администрирования SaltStack Config, мы научимся их интегрировать и работать с каждой из этих систем аутентификации.

Управление и администрирование SaltStack

GUI SaltStack Config представляет собой веб-приложение для работы с RaaS. Он напрямую взаимодействует с API, отводя своим рабочим областям различные задачи управления миньонами, пользователями, ролями, заданиями и многим другим.

Управлять миньонами можно двумя способами: прямой отдачей команды на удаленное выполнение или же управлением конфигурации (теория по обоим вариантам рассматривалась выше в «Архитектура и сценарии имплементации SaltStack Config»). Рассмотрим пример: нужно, чтобы миньоны установили у себя приложение Vim. В первом случае от мастера с терминала запускаем компанду:

salt -v ‘*’ pkg.install vim

Значок «‘*’» указывает на цель – в данном случае это все миньоны. Вместо «звездочки» можно подставлять специфический для каждого миньона ID, общие черты или характеристики некоторых миньонов – зерна. В результате на всех указанных миньонах программа удаленно проинсталлируется.

В случае управления конфигурацией нам нужно будет написать файл состояния на YAML, который проверит, был ли уже установлен Vim на миньонах. После этого этот файл к ним применится. Изнутри это выглядит так: система проверяет, проинсталлирована ли программа на целевых миньонах, Salt анализирует файл состояния и определяет, что нужно сделать, чтобы достичь соответствия этому файлу, после чего автоматизирует процессы по инсталляции. Обсуждаемый нами файл выглядит так:

# File:/srv/salt/vim_install.sls

install_vim_now:

pkg.installed:

– pkgs:

– vim

А чтобы применить это состояние к миньонам, можно использовать модуль state.apply, например, вот такой:

salt ‘*’ state.apply vim_install

Эта команда применит состояние vim_install ко всем миньонам.

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

Файл top.sls (Сопоставляет состояния Salt с тем, что назначено для доступных миньонов);
Выполнение Highstate (запускает все состояния Salt, очерченные в top.sls в качестве одиночного выполнения).

Top-файл может выглядеть, например, вот так:

# File: /srv/salt/top.sls

base:

‘*’:

– all_server_setup

’01webserver’:

– web_server_setup

где «base» – это среда Salt, являющаяся дефолтной. Кстати, можно указать более одной среды при необходимости (prod, dev, QA и т. д.).

Группы миньонов определены под средой, а состояния выведены в списках по каждому набору миньонов. Top-файл показывает, что состояние «all_server_setup» должно примениться ко всем миньонам (‘*’), а состояние «web_server_setup» – к миньонам «01webserver». Теперь можно запустить Salt-команду функцией state.highstate:

salt \* state.highstate

– она применит top-файл к целевым миньонам.

Это был очень узкоспециализированный пример одной стороны функционирования продукта. Теперь же изучим его GUI в деталях и попробуем рассмотреть большинство самых важных и распространенных задач, решаемых с его помощью, а также задачи, работать с которыми можно только через API.

О GUI SaltStack Config

Пользовательский интерфейс SaltStack Config облегчает управление всеми системами в среде. В нем можно, помимо всего прочего, добавлять отчеты на панель мониторинга в Home workspace для визуализации собираемых RaaS метрик – весьма полезная возможность для мониторинга системы и диагностики производительности.

Чтобы зайти в него, нужно вбить в адресную строку браузера URL SaltStack Config – получим страницу логина, где попросят ввести имя пользователя и пароль, после чего кликнуть на «Log In». Пробежимся по самому яркому функционалу с точки зрения применения элементов GUI.

Важно! Некоторые задачи можно выполнять исключительно через API (RaaS). Справочник по API для SaltStack Config выложен здесь.

User Preferences

Рабочая область «User Preferences» содержит множество полезных на практике настроек. Здесь можно менять пароль, а также:

Переключаться с темной на светлую тему экрана («Theme»);
Контролировать время таймаута сеанса (выбирается кол-во минут неактивности, после которого произойдет автоматический логаут – «Session timeout»);
Определять максимальное кол-во миньонов, отображаемых на различных панелях, таблицах и графиках в рабочем пространстве «Reports», а также в возвратах заданий. Параметр влияет только на визуальную демонстрацию, а не на реальную функциональность, и его использование позитивно сказывается на улучшении производительности UI («Set Limit»);
Если по «Set Limit» назначили «Enabled», появляется возможность задать конкретное число ограничения по миньонам – см. выше («Minion Limit»).

Попасть в нее можно из боковой панели, нажав на «Settings» – «User Preferences». Каждый раз, поменяв что-либо, сохраняемся кнопочкой «Save».

Помимо «User Preferences» меню «Settings» также включает в себя рабочее пространство «Connectors», если конфигурируются API-ключи для подключения и импорта сканов безопасности от сторонних вендоров – рассмотрим ниже.

Смена пароля

Как менять дефолтный пароль при первом входе мы рассматривали выше – в пост-инсталляционных задачах. Если же аналогичная операция понадобится для рядового пользователя в будущем, нужно в боковом меню кликнуть на «Settings» – «User Preferences», и под «Change Password» ввести новый пароль в соответствующем поле, повторить его и сохранить настройку кнопкой «Save».

Доступ к документации продукта

SaltStack отличается прекрасным по своей информативности и полезности хелпером, в котором можно найти ответы на множество интересующих в процессе администрирования и настройки вопросов. Чтобы попасть в его документацию, независимо от того, в каком конкретно рабочем пространстве находимся, ищем в правом верхнем углу кнопку с вопросиком («Help») и выбираем «Help Documentation». Очень удобно, что документация открывается в новой вкладке.

Рабочие пространства (Workspaces)

Все управление функционалом SaltStack Config выполняется в рабочих пространствах:

Панель мониторинга («Dashboard») – визуализация самых разнообразных видов системных метрик и данных сети. Доступны для отображения отчеты (в виде графиков и диаграмм);
Отчеты («Reports») – можно добавить отчеты на панель мониторинга для визуализации собранных API (RaaS) системных метрик. Удобны в мониторинге системных событий и диагностике производительности, а также в получении видения системы в целом;
Цели («Targets») – просмотр информации о миньонах, запущенных заданиях и сохранение новых целей. Через это рабочее пространство можно запускать задания, принимать или отклонять ключи, назначать роли или опоры целям;
Ключи миньонов («Minion Keys») – просмотр и управление ключами миньонов в разрезе их приема, отклонения, помещения в статус ожидающих или отклоненных;
Активность («Activity») – Мониторинг статуса заданий и других операций. Можно приостанавливать или останавливать вообще прогрессирующие операции, пропускать предстоящие итерации запланированной задачи;
Конфигурация («Config») – управление системными настройками для приведения своих систем, сервером и софта в желаемое согласованное состояние. Создание и построение таких компонентов, как:
- задания (Jobs),
- расписание (Schedules),
- опоры (Pillars),
- активность (Activity),
- файловый сервер (File Server);
Соответствие («Comply») – создание политик соответствия, сканирование и восстановление активов инфраструктуры для обеспечения соответствия диапазону отраслевых тестов безопасности;
Защита («Protect») – создание политик безопасности, сканирование активов инфраструктуры для оценки статуса уязвимости в связи с последними рекомендациями по безопасности, включая соответствие «Common Vulnerabilities and Exposures (CVE)». Исправление в соответствии с полученными рекомендациями, если доступен пакет восстановления;
Настройки («Settings») – управление пользовательскими интерфейсами и испорт сканов безопасности, сгенерированных широким диапазоном продуктов сторонних вендоров;
Администрирование («Administration») – управление пользователями, разрешениями и предпочтениями в развороте SaltStack Config.

Некоторые распространенные задачи в SaltStack Config

О смене пароля, доступе к помощнику и некоторых полезных настройках User Preferences мы уже поговорили. Настало время научиться полноценно пользоваться возможностями SaltStack Config. Что нам необходимо сделать, чтобы получить минимально, но достаточно функционирующую систему, хорошо иллюстрирует диаграмма:

Вот по ее рекомендациям мы и пойдем последовательно.

Создание целей и управление ими

Знакомство с понятием «целей» произошло выше, в теоретической части этой статьи. Давайте теперь перейдем к практике управления их жизненным циклом. Боковая панель включает список целей, и здесь можно определять цель для задания или операции, прикреплять опорные данные к разным целям и делать другие полезные вещи. По дефолту, когда открывается рабочее пространство, цель «All Minions» активна и выводит список всех миньонов, которые имеют разрешение на доступ.

Также в рабочем пространстве можно найти контроль «Run Command», который позволяет запускать одиночную команду (ad-hoc) на 1+ миньоне без создания повторно используемого задания. Функция полезна для быстрого выполнения команд или запуска эксклюзивных заданий, не являющихся частью ежедневного рабочего процесса (траблшутинг, начальная конфигурация и т. д.).

Вообще же ad-hoc-задания или команды в рабочем пространстве «Targets» могут запускаться для:

одного миньона,
списка миньонов,
мастера/всех мастеров (последнее – это «salt-run»),
цели.

В «Target», кроме всего прочего, можно запускать поиск по миньону или по типу миньонов, опираясь на их ID или другие системные свойства (зерна).

Просмотр информации о миньоне

Чтобы увидеть все данные по миньону, в рабочем пространстве «Targets» выбираем его ID в колонке «Minion ID». Откроется страница с его информацией, где будет доступен список зерен и прочего. Здесь также можно запускать ad-hoc-задание по этому миньону. И, наконец, на вкладке «Activity» есть просмотр истории заданий по миньонам.

Здесь колонка «Presence» показывает, получал ли SaltStack Config какие-либо данные по заданиям от миньонов недавно (в соответствии с определенным интервалом «raas_presence_expiration»). По дефолту этот интервал равен 3 600 секунд. Это еще один механизм получения информации о здоровье машины с помощью проинсталлированного на миньонах маяка «Presence». Этот маяк заставляет миньонов посылать периодический статус рабочей загрузки на их мастеров. Вообще же маяки используются для мониторинга не относящихся к Salt процессов. Когда отслеживаемая активность появляется, событие посылается и может быть настроено как триггер реактора. Проверить, какие маяки проинсталлированы и активны на миньоне можно запуском задания с «beacons.list».

Отображаемые статусы миньонов:

Unknown (никогда не было ответа от этого миньона – дефолтный статус для впервые подключенных миньонов, но, как только они получат хоть какую-то команду, статус обновится до «Present»);
Present (SaltStack Config видит ответы от миньонов с интервалом – см. выше);
Disconnected (ранее ответы от миньонов были видны, но в последний «raas_presence_expiration»-интервал их не было).

Выгрузка данных по миньону

Чтобы выгрузить данные по миньону в «Targets» кликаем на «More actions». В открывшемся меню под «Download table» выбираем нужный формат, после чего запустится выгрузка.

Поиск миньона

Чтобы найти нужного миньона, в «Targets» кликаем на пиктограммку фильтрации по колонке, в которой хотим произвести поиск. Также можно начать вводить критерий поиска, чтобы увидеть строки поиска быстрее, например, в колонке «Minion» – впечатать ID миньона и т. д.

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

Чтобы очистить фильтрацию, нажимаем на кнопку «Clear Filters» вверху таблицы с миньонами. Кроме того, можно отсортировать колонку, выбрав ее имя. Для настройки, что будет показывать та или иная колонка в таблице, нажимаем на кнопку «Show columns» в углу под таблицей.

Запуск ad-hoc-задания и команды

В рабочем пространстве «Targets» выбираем конкретного миньона, список миньонов (ставим галочки в боксах напротив нужных в таблице) или цель (выбираем имя цели в боковой панели «Targets» – оно покажется над списком миньонов). Затем кликаем на «Run job» и в диалоговом окне выбираем задание, которое хотим запустить, после чего подтверждаем свой выбор. Также можно выбрать дополнительные опции, если необходимо, после чего старт задания инициируется кнопкой «Run now».

В «Targets» выбираем миньона, их список, либо цель (см. выше как) и нажимаем на «Run Command». В диалоговом окне подтверждаем правильную команду и цель, обозначив их, затем выбираем функцию.

Важно! Если выбирается команда «salt-run», доступен выбор запуска команды на всех мастерах, либо на указанном мастере (Salt runner – см. выше).

Включаем любые нужные аргументы и окончательно жмем на «Run Command», чтобы команда начала выполняться.

Создание новой цели

Главными критериями каждой цели являются имя, ее мастер и цель. Чтобы создать новую цель, в «Targets» кликаем в боковой панели на «All Minions», затем на кнопку «Create target». В появившемся диалоговом окне вводим имя новой цели (желательно информативное). Учтите, что по дефолту параметр «All masters» является включенным, то есть в цель включены все миньоны, управляемые любым мастером. Можно нажать на эту кнопку, чтобы эта цель применялась только к подмножеству миньонов, ассоциированных с одним или большим кол-вом мастеров. Если этот параметр отключить, появится меню, в котором можно выбрать, конкретного мастера(ов), к которым будет применяться цель.

Затем следует нажать на меню «Grain», чтобы выбрать тип цели (зерна, глобы, списки или их сочетания). В зависимости от сделанного выбора, появится возможность определять дальнейшие критерии и параметры. Например, если выбрано «Compound», придется следовать синтаксису таргетинга, включенному в Salt Targeting Reference, в том числе включать любой вторичный критерий в определение составной цели. Конкретно по этим критериям, они бывают следующих видов:

Grain – соответствие указанному значению зерна (например, «osfullname» – «Debian»);
Glob – подстановочный знак, использующий ID миньона (например, «webserver*», чтобы выбрать множество миньонов с именами «webserver01», «webserver02» и т.д.);
List – указывается список миньонов для включения в цель (например, «dc3-north-db1»), удобно для динамического доступа к целям и предотвращения попадания в цель новых, соответствующих динамическому критерию, миньонов автоматически;
Compound – комбинация множества интерфейсов целей, отделенных операторами and, or и not.

Важно! В SaltStack Config нельзя добавлять другие критерии в редактор целей.

Когда все назначения будут сделаны, запускаем создание новой цели кнопкой «Save».

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

В «Targets» кликаем на «All Minions» в боковой панели;
Ставим галочки на тех миньонов, которые должны быть включены в список, и нажимаем на «Create target» (для удобства можно использовать функции фильтрации и сортировки);
Вводим имя цели и определяем любые нужные ее дополнительные параметры (поле «Master» – по дефолту «All Masters», но можно выбрать и конкретные; критерий – см. выше);
Запускаем процесс создания кнопкой «Save».

Назначение опоры цели

В «Targets» выбираем цель из боковой панели и нажимаем на «More actions». Появится меню, в котором кликаем на «Attach Pillar». В диалоговом окне выбираем опоры, которые хотим применить к цели (можно дополнительно выбрать «Refresh pillar», чтобы опора стала доступной выбранной цели моментально). После всего нажимаем на «Update Target».

Это же действие доступно и из рабочего пространства опор (Pillars).

Создание заданий и управление ими

О том, что такое задания, зачем они нужны и как работают в системе SaltStack, мы писали выше в разделе «Что такое SaltStack Config?». Сейчас же поучимся практическому их созданию и другим с ними операциям (просмотр, редактирование, запуск, удаление).

Для начала отметим, что задания можно создавать из нескольких рабочих пространств, например, не только непосредственно из «Jobs», но и из «Targets» (см. выше), и даже из других разделов UI, в зависимости от природы самого задания. Также стоит отметить, что при создании типового задания, можно оставить цель пока не определенной, подготовив необходимый базис заранее, а потом просто применить его так, как необходимо. А при запуске можно использовать как регулярное расписание, так и инициацию по требованию.

Каждое задание в рабочем пространстве «Jobs» обладает предустановленными настройками. Их можно отредактировать на уже готовом задании либо же создать полностью новое с уникальными параметрами. В их числе обязательно присутствует функция (задача задания), цель/мастер/комплект мастеров, разрешения на основе ролей.

Создание и редактирование нового задания

В рабочем пространстве «Jobs» кликаем на «Create job», вводим данные задания и нажимаем на «Save», после чего задание готово к запуску.

Данные включают в себя, в первую очередь:

имя (будет показываться во всех остальных рабочих пространствах),
опционально – описание,
команду (выбор из «salt», определяющей запуск на целевой группе миньонов, или «salt-run» – на мастере или группе мастеров),
цели (см. выше),
функция (Single remote execution jobs – одиночное задание удаленного выполнения, кроме выбора самой функции, нужно задать некоторые аргументы:

State file jobs – применяет состояние к цели, опирается минимум на одну команду. Функция состояния – это функция, содержащаяся внутри модуля состояния, который управляет приложением конкретного состояния к системе. Она часто вызывает один или несколько модулей исполнения для выполнения данной задачи. Нighstate, к примеру, применяет все состояния, определенные в top-файле. Просматривать и добавлять файлы состояния можно на файловом сервере. Чтобы применить файл состояния к заданию, нужно использовать функцию «state.apply». В этом случае появляются дополнительные поля, где можно выбрать файлы состояния, которые хочется применить. Также можно передать необязательные переопределения столбцов в формате JSON.

Salt runners – salt-run (см. выше);

разрешения, и чтобы их определить, нужно кликнуть на «Role Access», после чего в диалоговом окне выбрать уровень доступа (включенный для разных ролей) и нажать там «Save»,
среды (выбор среды, где файл состояния или оркестровки расположен – подкаталог корневого каталога на файловом сервере).

Если в команде было выбрано «salt-run», появится параметр «All Masters», по дефолту назначающий задание для всех мастеров, но, если его отключить, станет доступным меню «Master», где выбираются конкретные.

Чтобы протестировать наше новое задание, можно выбрать опцию «Test (dry run)». Учтите, что она доступна только для некоторых функций. Для уточнения используйте документацию к продукту.

Отредактировать задание можно, выбрав его в списке и открыв, после чего изменения нужно сохранить кнопкой «Save».

Запуск заданий по расписанию и по требованию

Для начала заметим, что запуск заданий можно осуществлять и с другой стороны – из рабочего пространства «Minions» Перед тем, как приступать к запуску заданий в «Jobs», у нас должна быть определена цель для них, функция (запускаемая команда/применяемое состояние) и разрешения для тех, кто может запускать задание для цели. После определения этих параметров, задания можно запускать по регулярному графику, либо же вручную именно тогда, когда это нужно (т. н. «ad-hoc jobs»).

Запуск заданий в соответствии с назначенным графиком означает, что мы определяем регулярные интервалы, через которые это будет происходить, либо же указываем точное время (связанное событие – например, окно техобслуживания). В этом случае задания создаются через рабочее пространство «Schedules». Кстати, оно помогает автоматизировать выполнение заданий, а именно:

Планировать разовые или повторяющиеся задания для слежения за средой;
Запускать задания постоянно в любой момент;
Отключать расписания и пропускать задания;
Запускать задание по расписанию.

Помимо непосредственного «Schedules» получить доступ к заданиям по расписанию можно и из рабочего пространства «Activity» (см. ниже) – там можно узнать о их статусе (ожидаемое/выполненное) и пр. Зайти в рабочее пространство заданий по расписанию можно через «Config» – «Schedules» в боковом меню. Там можно создать новое расписание, кликнув на «Create Schedule», введя его имя и определив пользовательские параметры:

задание,
цель,
временная зона (задания выполняются по UTC, независимо от того, что сервер RaaS автоматически определяет местную зону из браузера)
частота расписания:

«Recurring» – назначение интервала с опциональными полями даты начала и конца, расширения и максимального кол-ва параллельных заданий;

«Repeat Date & Time» – повторение расписания еженедельно или ежедневно с опциональными полями даты начала и конца, а также максимальным кол-вом параллельных заданий;

«Once» – указание даты и времени запуска задания;

«Cron» («Cron Expression») – ввод cron-выражения для определения пользовательского расписания на основе синтаксиса Croniter. Учебник по синтаксису выложен здесь.

Важно! Для совершенствования результатов работы с Cron Expression избегайте включения в расписание заданий с менее чем 60-секундным интервалом.

После этого сохраняем настройку кнопкой «Save». А если в будущем расписание понадобится отредактировать, заходим в него и нажимаем на «Edit Schedule», и после сделанных изменений, сохраняем их тем же «Save».

Чтобы проверить статус задания (помимо упомянутого способа через «Activity») нужно в «Schedules» кликнуть на имя расписания, после чего откроется доступ к разным вкладкам статуса (задания в прогрессе, предстоящие и выполненные, ассоциированные с этим расписанием). А статус самого расписания может быть «Enabled» (включенное) или «Disabled» (выключенное).

Запуск задания по расписанию может производиться, в т. ч., из рабочего пространства «Schedules», где нужно поставить галочки напротив нужного задания и кликнуть на «Run now», после чего появится всплывающее окно, где нужно тоже нажать на «Run now». Кстати, таким образом можно запускать сразу несколько заданий.

Важно! Если кнопки «Run now» серые, у пользователя нет прав на запуск расписаний по этой цели или в UI SaltStack Config, вообще. См. раздел о ролях и разрешениях ниже.

Также можно пропустить инстанс задания по расписанию из «Schedules», кликнув на имя расписания и пройдя на вкладку «Upcoming». Там ставим галочки в нужном инстансе задания и кликаем на «Skip». В подтверждающем диалоговом окне жмем точно такую же кнопку. И, наконец, чтобы выключить расписание целиком нам нужно выбрать нужное галочкой в «Schedules» и кликнуть на кнопку «Disable», после чего в подтверждающем диалоговом окне снова нажать на «Disable». Однажды выключенное расписание впоследствии аналогичным нехитрым методом можно включить.

А задания типа «ad-hoc» могут запускаться через рабочее пространство «Jobs» или «Targets», кликнув на три вертикальные точки по нему и выбрав «Run Now»:

Если задание сконфигурировано под включение цели или мастера, вылетит окно подтверждения, с которым нужно согласиться. Далее выбираем дополнительные опции: предпочитаемый способ оповещения, а также «Run as Test (dry run)», чтобы протестировать запуск и убедиться, что все пойдет как надо. И, наконец, нажимаем на «Run Now» для окончательной инициации запуска.

Поиск задания

По дефолту в списке заданий на «Jobs» выводится по 20 позиций. Чтобы задать просмотр большего кол-ва, внизу списка кликаем на меню «Items per page» и выбираем нужное число.

Для поиска конкретного задания используем значок фильтрации по колонке, в которой хочется осуществить поиск. Выбираем критерий поиска или начинаем его печатать, чтобы произвести моментальный вывод. Так, например, можно осуществить поиск задания по Salt module в колонке «Function». Наконец, доступна сортировка по колонке в восходящем или нисходящем порядке путем нажатия на ее название. Очистка фильтра и настройка того, что будет показывать колонка в таблице доступна, как и по всем другим рабочим пространствам по кнопкам «Clear Filters» и «Show columns», соответственно.

Ответ (возврат результата) заданий

Слежение за возвратом результата заданий от миньона – важный момент в администрировании SaltStack Config. Делать это можно из рабочего пространства «Activity» (см. ниже) или напрямую из «Minions», выбрав ID интересующего миньона и на странице «Details» зайдя на вкладку «Activity». Там происходит вывод последних 500 заданий, выполняемых выбранным миньоном, и чтобы посмотреть информацию о конкретном, следует ввести JID (идентификатор задания) в соответствующей колонке.

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

Title – страница, определяющая функцию задания и JID,

Subtitle – зависит от типа задания и может включать имя задания, цель, указание на связанного мастера(ов), имя пользователя, запустившего задание, и детали возврата,

Job detail views – здесь можно выбрать формат возврата задания, отметив «Summary» (список миньонов, являющихся целью для задания – каждого тоже можно просмотреть), «Custom outputter» (пользовательское представление вывода, настроенное с помощью ассоциированных с заданием функций, в т. ч. State jobs/test.ping/disk.usage/status.cpuinfo/network.routes/network.ipaddrs/network.netstat/cmd.run/cmd.script/pkg.list_pkgs/User Information), «Raw» (необработанная структура данных JSON с минимальным форматированием), «Job info» (высокоуровневая информация о задания, включающая ожидаемых миньонов, возвращающих это задание, а также тех, кто этого не сделал).

Результаты выполнения задания можно выгрузить при необходимости. Для этого нужно просто нажать на «Download» в верхнем правом углу данных по ответу задания, откроется меню, в котором придется выбрать подходящий тип файла загрузки, например, JSON.

Работа с опорами (Pillars)

За создание и управление опорами отвечает рабочее пространство «Pillars». Необходимую теоретическую информацию об этом логическом компоненте SaltStack Config можно почерпнуть выше в соответствующем разделе. Данные опоры могут храниться либо в виде частной опоры в рабочем пространстве «Pillars», либо в настройках задания, либо в других корневых опорах на API (RaaS) сервере.

Важно! Хранение данных опоры в задании менее защищено, чем данные в стандартной опоре, так как любой пользователь с доступом к заданию может также просматривать данные и по опоре.

В рабочем пространстве «Pillars» можно создавать новые опоры и назначать их целям, а пройти в него можно из «Config» – «Pillars» бокового меню. Чтобы создать новую опору, здесь нужно нажать на «Create», ввести ее данные в JSON-формате (в актуальной редакции на момент написания этой статьи YAML пока не поддерживается) и сохранить настройку кнопкой «Save».

Важно! Имена опор необязательно должны быть уникальными.

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

В рабочем пространстве «Pillars» выбираем нужную опору;
Кликаем на «Update Targets»;
В появившемся диалоговом окне выбираем цели. Также можно тут же нажать на «Refresh pillar», чтобы опора стала доступной выбранной цели сразу же;
Сохраняем настройку кнопкой «Save».

Аналогичную операцию можно проделать в рабочем пространстве «Targets» (см. выше).

Несколько замечаний:

Цели «All Minions» нельзя назначить данные опоры (цель только для чтения). Чтобы назначить данные опоры всем миньонам, нужно создать новую цель, которая будет включать всех миньонов (*);
Если одни и те же данные опоры определены в нескольких источниках, SaltStack Config выбирает их для применения с такой приоритизацией:

1. Значения, передаваемые напрямую на задание;
2. Значения в UI SaltStack Config (рабочее пространство «Pillars»);
3. Значения в других корневых опорах.

Данный порядок можно поменять, если изменить порядок pillar_roots в конфигурации мастера Salt.

Резюмируя тему опор, можно сказать, что это очень полезный инструмент в передаче данных в состояния, на реакторы и другие типы файлов – связи с такими соответствующими файлами задаются в опорах. Второй важнейшей их функцией является ассоциация запущенных заданий с целью через прикрепление данных опоры к цели.

Работа с файловым сервером

Доступ к рабочему пространству «File Server» осуществляется из «Config» – «File Server» бокового меню. В нем можно создавать новые файлы, клонировать существующие, редактировать их и удалять.

Создание/клонирование/удаление файлов

Чтобы создать новый файл здесь нажимаем на «Create», и под «base» вводим имя базовой среды, а под «Path Name» – путь к этому файлу, а также само имя файла:

Важно! Имена файлов могут не быть уникальными, если пути к ним различны, либо же они относятся к разным средам.

Учтите, что на файловом сервере SaltStack Config существует возможность определить несколько сред для файла, позволяющих изолировать файлы с одинаковым путем и именем. По умолчанию, данные опор и файлы находятся в базовой среде – именно она выбирается, когда создается состояние запуска задания:

После этого вводим само тело файла и сохраняем его кнопкой «Save». Теперь этот новый файл появится на файловом сервере, однако для просмотра созданных другими пользователями файлов нужно быть наделенным правами Superuser.

Клонирование файла (копирование) производится в этом же рабочем пространстве, где нужно выбрать файл, для которого требуется подобная операция, после чего нажимается кнопка «Clone». Копия появится на файловом сервере с добавлением «-2» к имени файла.

Удаляем файл, выбрав его и нажав на «Delete». После этого появится окно подтверждения, где нужно согласиться кнопкой «Confirm».

Интеграция с существующими файловыми серверами

Если в наличии уже есть настроенный файловый сервер, например, Git или S3, они продолжат свою работу, как и всегда, а создаваемые и выполняемые из UI работы могут использовать эти бэкенды без дополнительной конфигурации. Однако, если в планах применять файловый сервер SaltStack Config с другими файловыми серверами, учтите, что существующие в UI файлы имеют приоритет, если они присутствуют и на других серверах.

Порядок бэкенда задается так:

fileserver_backend:

– sseapi

– roots

– git

Но, при желании его можно и поменять, реорганизовав эти строки в секции «fileserver_backend» файла «/etc/ salt/master.d/raas.conf».

Доступ к файловому серверу

Для начала оговоримся, что пользователям для запуска заданий совершенно не нужны привилегии на файловом сервере. К примеру, администратор создал задание, запускающее файл «apache/init.sls» («state.apply apache»). Пользователи с доступом к этому заданию могут его запускать, даже если просматривать, редактировать и удалять сам файл «apache/init.sls» напрямую не в праве. Как уже отмечалось выше, только Superuser может просматривать созданные другими пользователями файлы. А дефолтные роли Superuser и Admin обладают доступом к просмотру и изменениям на файловом сервере (о ролях поговорим ниже).

Определение ролей

Определение ролей – важнейший этап подготовки системы к работе и дальнейшего ею управления. Каждая роль, по сути, должна иметь доступ только к указанным нодам или заданиям, и каждый наделенный ею член административного штата SaltStack Config, опираясь на нее, должен быть авторизирован для этого доступа. Подобная организация укладывается в рамки стратегии RBAC (контроль доступа на основе ролей) и нивелирует возможность потребления ресурсов не теми, кому это разрешено, и кому – действительно необходимо, а также позволяет выполнять свои трудовые обязанности максимально таргетированно и эффективно.

Разрешения и роли определяются нативным способом в самом SaltStack Config, либо же сопоставляются доступ и цели/задания к RBAC-системе организации (например, если отдано предпочтение AD, SAML-системам вроде Google и т. д.).

В SaltStack Config есть масса встроенных не удаляемых ролей, но в дополнение к ним можно создать пользовательские, нужные конкретной организации. И доступ к ним, а также к процедуре создания новых ролей, назначения источников доступа, определения разрешений получается из рабочего пространства «Roles» («Administration» – «Roles» бокового меню). Помимо базовых инструментов там можно найти и расширенный редактор, пользоваться которым рекомендовано только продвинутым пользователям SaltStack Config.

Вообще же в SaltStack Config можно найти такие типы встроенных ролей:

User. По дефолту назначается всем новым локальным пользователям и пользователям LDAP. Покрывает фундаментальные разрешения («Read», запуск заданий, просмотр истории заданий, ответов на задания, отчеты по конкретным миньонам и типам работ);
Administrator. Помимо всего, что разрешено для User, доступ к System Administration, просмотр и иногда редактирование чувствительных данных в опорах и пользовательских настройках, создание/обновление/удаление ресурсов (файлов, заданий, целей), управление ключами;
Superuser. Любые операции в SaltStack Config, включая системного администрирования. Пример – «root». Не может быть удалена, склонирована или отредактирована, но к ней можно добавлять любые группы пользователей или индивидуальных лиц.

Важно! Доступ к ресурсам для определенных их типов и функциональных областей следует определять в API (RaaS), а не в редакторе ролей.

Создание/клонирование/редактирование роли

Чтобы создать новую роль, заходим в соответствующее рабочее пространство и нажимаем на «Create», после чего вводим имя роли, а под «Tasks» выбираем разрешенные для нее действия:

Создание и удаление новых целей;
Изменение данных опоры;
Изменения файлового сервера;
Запуск произвольных команд на миньонах;
Прием, удаление и отклонение ключей;
Чтение и изменение пользователей, ролей, разрешений (применяется только для встроенных ролей Administrator и Superuser);
Запуск команд на мастерах Salt (в т.ч. доступ к опции «salt-run» в функции «Run command» на вкладке «Minions»);
Соответствие – создание, редактирование, удаление и оценка (политики SaltStack Comply при наличии лицензии на оную. Важное замечание: кроме наделения разрешениями этой задачи, следует также определить доступ к источнику для любой цели, по которой будут применяться действия ассоциированной с задачей роли. Например, если роли Oracle Linux Admin нужно определять политики для цели Oracle Linux, кроме этого разрешения нужно предоставить доступ на чтение («Read») цели Oracle Linux);
Соответствие – восстановление (восстановление обнаруженных SaltStack Comply несоответствующих миньонов, требуется соответствующая лицензия на аддон);
Соответствие – апдейт контента SaltStack Comply (загрузка апдейтов и обновление библиотеки SaltStack Comply, требуется соответствующая лицензия на аддон);
Уязвимость – создание, редактирование, удаление и оценка (политики SaltStack Protect при наличии лицензии на оную. Важное замечание: кроме наделения разрешениями этой задачи, следует также определить доступ к источнику для любой цели, по которой будут применяться действия ассоциированной с задачей роли);
Уязвимость – восстановление (восстановление обнаруженных SaltStack Protect уязвимостей, требуется соответствующая лицензия на аддон).

И сохраняем настройку кнопкой «Save».

Отношения с целями строятся по трем сценариям: Read Only (только просмотр), Read/Write (просмотр и редактирование), Read/Write/Delete (просмотр, редактирование и удаление). А отношения с заданиями – по четырем: Read Only (только просмотр), Read/Run (просмотр и запуск), Read/Run/Write (просмотр, запуск и редактирование), Read/Run/Write/Delete (просмотр, запуск, редактирование и удаление).

Для клонирования роли там же выбираем роль, с которой нужно снять копию, нажимаем на «Clone», вводим имя новой роли и сохраняем настройку по «Save». Учтите, что склонированные роли наследуют разрешенные задачи от оригинальной по дефолту, однако не доступ к ресурсам – он задается отдельно.

Важно! Встроенная роль Superuser не может быть склонирована.

Важно! В ряде случаев клонирование роли является более предпочтительной операцией, по сравнению с созданием полностью новой. При этом после получения клона он просто редактируется, как нужно.

Чтобы отредактировать роль с помощью стандартного редактора (расширенный рассмотрим ниже), выбираем ее в списке, а затем переходим по тем ее вкладкам, в которые нужно внести изменения (Tasks, Resource Access, Groups, Users). Сохраняем настройки кнопкой «Save».

Некоторые из этих вкладок нуждаются в более детальном рассмотрении.

Resource Access. Здесь находится требуемое задание или цель, после чего выбирается желаемый уровень доступа. Например, чтобы позволить этой роли запускать задания, нужно выбрать «Read/Run» для задания. Если источник не отображается, следует нажать на «Show all Targets» или «Show all Jobs», в зависимости от того, что ищем:

Groups. На этой вкладке можно добавлять или удалять группы. Они импортируются через подключение сервиса директорий. Если искомая группа не видна, следует перепроверить, добавлено ли это подключение и проведена ли синхронизация групп. Любая удаляемая группа выводится из подключения Directory Service и архивируется – ее все равно видно в «Roles», хоть она и неактивна, и ее пользователям отказано в доступе.

Users. Пользователи, вообще, наследуют разрешения от своей группы, и по best practice лучше избегать прямого добавления индивидуальных пользователей к роли – их нужно просто добавить в группу, а далее все произойдет само собой. Если же это, все-таки, нужно сделать напрямую, задействуется соответствующая вкладка в роли.

Важно! Отредактировать параметры индивидуальных пользователей, включенных в группу Directory Service, можно только после осуществления ими первого логина.

Расширенные разрешения

Иногда разрешения роли нуждаются в более детальной настройке. Для этого можно воспользоваться вкладкой «Advanced», выбрав роль в боковой панели «Roles», которую следует настроить:

Здесь просто проставляются галочки в нужных чек-боксах, в зависимости от того, что хотим разрешить для этой конкретной роли. И готовая настройка сохраняется кнопкой «Save».

Полный список конкретизируемых назначений (галочки проставляются в колонках по ним, обозначенных как Read, Run, Write, Delete, и отвечающих определенному типу действия):

All Minions Commands (запуск команд для цели «All Minions»);
Admin (административные привилегии для UI SaltStack Config, не включая административный доступ к API (RaaS));
Audit Log (доступ к записям о любых активностях в SaltStack Config, включая деятельность пользователей);
Commands (задачи, выполняемые как часть задания, и включающие информацию о цели, функции и опциональные аргументы);
File Server (доступ к работе с файловым сервером);
Groups (управление группами пользователей);
Jobs (управление заданиями, применение состояний, запуск раннеров Salt);
License (управление лицензиями, в т. ч. просмотр их деталей, включающих информацию о количестве разрешенных мастеров и миньонов, даты истечения и пр.);
Master Configuration (доступ к конфигурационному файлу с ID мастера, порту публикации, поведению кэширования и др.);
Master Resources (управление мастером);
Metadata auth (использование AUTH-интерфейса для управления пользователями, группами, ролями через RPC API);
Minion Resources (управление миньонами);
Pillar (управление опорами);
Returner Data (управление данными с получателей информации о выполненных заданиях от миньонов);
Roles (управление ролями);
Runner Commands (задачи раннера, выполняемые как часть задания, и включающие информацию о цели, функции и опциональные аргументы);
Compliance Assessment (работа с оценкой инстанса проверки набора требований по безопасности комплекта нод – определяется в политике SaltStack Comply);
Compliance Policy (управление политиками SaltStack Comply);
Compliance Remediation (восстановление несоответствующих нод в SaltStack Comply);
Compliance Content Ingest – SaltStack (приемка контента SaltStack Comply);
Compliance Content Ingest – Custom (приемка контента Custom Compliance под SaltStack Comply);
Compliance Custom Content (определение собственных стандартов безопасности);
Schedules (управление расписаниями);
SSH Commands (запуск SSH-команд на миньонах, на которых не проинсталлирован сервис миньонов);
Target Groups (управление целевыми группами);
Users (управление пользователями);
Vulnerability Assessment (оценка инстанса сканирования коллекции нод на предмет уязвимостей – определяется в политике SaltStack Protect);
Vulnerability Policy (управление политиками SaltStack Protect);
Vulnerability Remediation (восстановление после обнаружения уязвимостей SaltStack Protect);
Vulnerability Content Ingest (приемка контента SaltStack Protect);
Vulnerability Vendor Import (приемка контента сторонних вендоров, поддерживаемого SaltStack Protect);
Wheel Commands (запуск команд механизма контроля над работой мастера, управление ключами).

Для встроенной роли User данная таблица задания расширенных разрешений выглядит, например, так:

Для Administrator – вот так:

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

Управление ключами миньонов («Minion Keys»)

Управление ключами миньонов производится в рабочем пространстве «Minion Keys». Немного о начальном их принятии писалось выше в подразделе «Принятие ключа Salt master и бекапирование данных» пост-инсталляционных задач. В целом же, это рабочее пространство позволяет получить фильтрацию по всем миньонам в разрезе статуса их ключа, и делится на 4 секции, в зависимости от того, как отреагировал мастер на публичный ключ миньона:

Accepted – ключ принят, коммуникация с мастером разрешена;
Pending – ожидает решения по себе (не принято, и не отклонено), коммуникация не происходит, задания не поступают;
Rejected – ключ отклонен явным способом (командой «Reject Key»), подключение не происходит, задания не выполняются;
Denied – отклонен автоматически (причина может быть в дублированном ID, перестройке миньона или обладании им новыми сгенерированными ключами, в то время как старые удалены с мастера не были), подключения нет, задания не выполняются.

Эти секции можно увидеть, если в боковом меню выбрать «Minion Keys».

В рабочем пространстве «Minion Keys» можно принимать, отклонять или удалять ключи миньона, а также управлять мастер-ключами. Перед приемом нового ключа миньона следует проверить, проинсталлирован ли сервис миньона на ноде и настроен ли он для коммуникации с мастером. Удаление ключа миньона полезно в перезапуске связи миньона (с последующим принятием его, естественно).

Прием/отклонение/удаление нового ключа миньона

Все новые ключи, ожидающие по себе действий, высвечиваются в «Minion Keys» в статусе «Pending», о чем оповещается пользователь при его входе в систему. Чтобы их принять, делаем следующее:

В соответствующем рабочем пространстве кликаем на «Pending» в боковой панели;
Ставим галочки напротив ключа(ей), которые хотим принять и нажимаем на «Accept Key»;
В появившемся диалоге подтверждения кликаем на «Accept».

После принятия они появятся на вкладке «Accepted» и в рабочем пространстве «Minions Key».

Важно! В случае мульти-мастерной среды ключи следует принимать по каждому мастеру отдельно.

Чтобы отклонить ключ миньона, заходим туда же в «Pending» (если решение по ключу еще не принималось, или же ищем его на вкладке «Accepted»), выделяем галочками нужные ключи и нажимаем на «Reject Key». Такие ключи появятся на вкладке «Rejected».

Чтобы удалить ключ миньона, заходим в «Pending»/«Accepted», выделяем нужные ключи и кликаем на «Delete Key». Через несколько секунд они пропадут.

Поиск миньона по ключу

В боковом меню кликаем на статус ключа, который ищем (если не уверены в статусе, и не хочется кликать по всем секциям, просто делаем это через «Targets»), и нажимаем на пиктораммку фильтра по колонке, которую хотим найти. Начинаем вводить критерий поиска (например, ID миньона, если ищем в колонке «Minion») – фильтрация произойдет мгновенно. Вывод отфильтрованной колонки можно отсортировать в нисходящем или восходящем порядке, кликнув на ее название.

Вообще же работа с сортировкой и фильтрация здесь полностью аналогична тому, что мы делали, когда искали миньонов в «Targets».

Использование рабочего пространства «Activity»

Это рабочее пространство позволяет следить за статусом заданий и других активностей (задания по расписанию, аd-hoc-задания, оценка соответствия или уязвимостей и т. д.). Для последних двух, кстати, нужны лицензии SaltStack Comply и SaltStack Protect – о включении этих аддонов мы говорили выше в подразделах «Подготовка к использованию SaltStack Protect» и «Подготовка к использованию SaltStack Comply» пост-инсталляционных задач, а о конфигурировании расскажем ниже в этом же разделе в «Опции настройки SaltStack Comply» и «Опции настройки SaltStack Protect».

В целом, в «Activity» можно попасть из бокового одноименного меню, а сортировка заданий и других активностей там производится в трех секциях:

Completed – выполненные,
In Progress – в прогрессе,
Upcoming – вот-вот начнут исполняться.

По каждой секции выводится таблица, где размещена вся сопровождающая информация (в т. ч. можно отображать происхождение того или иного события, целевую информацию и многое другое). В процессе продвижения по своему жизненному циклу предмет внимания этой вкладки перемещается из «Upcoming» в «In Progress», а оттуда – в «Completed».

При этом данные по статусу могут дополнительно конкретизироваться. Например, в «Completed» задание может отображаться как «Partial», если произошел сбой у миньонов при проверке их состояния мастером в отношении данного задания (неправильная конфигурация системы, сбой сети, проблемы с клиентом или машиной). Либо же Completed (успешно завершено), Skipped (не запустилось по расписанию), Disabled (является частью выключенного расписания – не запустилось), Stopped (остановлено и не доступно для перезапуска), Failed (пошло, но произошел сбой на одном или большем кол-ве миньонов). Что же касается конкретизации по «In Progress», это могут быть такие суб-статусы: Running (запущено), Paused (приостановлено), Pausing (будет приостановлено в подходящий момент, например, между выполнением разных задач), Resuming (продолжило работу после приостановки), Queued (пытается запуститься), Stopping (остановлено). А по «Upcoming» соответствующая расшифровка: Scheduled (запустится по расписанию – точное время запуска указано в колонке «Start time»), Skipping (не запустится в указанное для него время по расписанию), Disabled (не запустится, потому что расписание для него выключено).

Приостановка/остановка/пропуск задания или активности

Если задание нужно поставить на паузу, в «Activity» кликаем на подменю «In Progress», ставим галочку на нужном задании (нескольких) и нажимаем на «Pause», а потом на такую же кнопку – в подтверждающем диалоговом окне.

Если задание(я) нужно остановить, там же ставим галочки на нем/них и нажимаем на «Stop», а затем на «Stop» в диалоговом окне подтверждения.

Важно! Если задание небольшое, постановка на паузу/остановка может произойти позже, чем оно завершится нормальным ходом.

В «Activity» заходим в «Upcoming», выбираем задания или активности, которые нужно скипнуть, и нажимаем на кнопку «Skip», после чего на такую же – в подтверждающем диалоговом окне.

Поиск задания/активности

За раз на странице по каждой секции рабочего пространства «Activity» выводится всего по 20 строк по дефолту. Это кол-во можно увеличить, если кликнуть на меню «Items per page» внизу таблицы и выбрать предпочитаемое число активностей.

Для поиска конкретного задания или активности, выбираем подменю его текущего состояния («Completed»/«In Progress»/«Upcoming») и кликаем на пиктограмму фильтра по колонке, в которой хотим произвести поиск. Далее выбираем критерий поиска или начинаем его вводить, чтобы произошел соответствующий вывод. Как и всегда, данные по колонке можно отсортировать в нисходящем или восходящем порядке, кликнув на ее название. По аналогии с «Targets», «Minion Keys» и другими рабочими пространствами, очищать фильтрацию можно кнопкой «Clear Filters» (сверху таблицы), а настраивать отображение в колонках – пиктораммой «Show columns» в нижнем левом углу.

Однако, именно у «Activity» в плане фильтрации есть интересная особенность: можно задавать вывод для указанных диапазонов времени, используя фильтрацию или сортировку в колонке «Start time» (фильтр, например, даст выбор из «Past hour»/«Next 7 days» и др. – «Past…» или «Next», в зависимости от того, на вкладке «Completed» мы или на «Upcoming»).

Мониторинг («Dashboard»)

Так как здесь панель мониторинга представляет собой инструмент высокоуровневого обзора, отчеты могут отображать системные данные только за последние сутки или меньше. Чтобы получить детализированный взгляд на системные метрики за более долгий период времени, нужно использовать конечную точку «/metrics». Она экспортирует метрики в сторонние инструменты (например, в Prometheus) или другую систему мониторинга и оповещения.

Виды отчетов и таблиц в панели мониторинга:

Отчет	Описание	Доступные фильтры
События Salt (Salt Events)	Отображает кол-во событий Salt за период времени (заданий, других операций). Удобно для мониторинга ожидаемых или неожиданных пиков сетевой активности	Все мастера/указанные мастера, диапазон времени (с минувшего часа и до суток до него)
Полезная нагрузка события Salt (Salt Event Payload Size)	Отображает полезную нагрузку размера событий Salt за период времени (заданий, других операций). Полезно для мониторинга кол-ва задействованной мощности CPU, памяти	Все мастера/указанные мастера, диапазон времени (с минувшего часа и до суток до него)
Интенсивность очереди Celery (Celery Queue Depth)	Показывает интенсивность очереди Celery, отвечающей кол-ву поставленных в очередь заданий, в то время, как CPU или ресурсы БД остаются доступными. Полезно для выявления узких мест CPU или БД	Все сервера RaaS, диапазон времени (с минувшего часа и до суток до него)
Запросы веб-сервера RaaS (RaaS Webserver Requests)	Показывает число запросов, сделанных сервером API (RaaS) за период времени. Удобно для мониторинга ожидаемых или внезапных пиков серверной активности	Все сервера RaaS, диапазон времени (с минувшего часа и до суток до него)
Время ответа веб-сервера на запросы (Webserver Response Time)	Показывает кол-во времени обработки, затребованное сервером API (RaaS) для ответа на запросы за период времени. Полезно для мониторинга узких мест и общей производительности сервера API (RaaS)	Все сервера RaaS, диапазон времени (с минувшего часа и до суток до него)
Время итерации мастера RaaS (RaaS Master Iteration Time)	Отображает кол-во времени, которое необходимо мастерам для подключения к SaltStack Config для завершения запроса веб-мервера, от начала и до конца, за период времени. Удобно для мониторинга связанной с SaltStack Config нагрузки по каждому мастеру	Все мастера/указанные мастера, диапазон времени (с минувшего часа и до суток до него)
Аутентифицированные пользователи SSE (SSE Users Authenticated)	Отображает кол-во отдельных пользователей, залогинившихся в SaltStack Config за период времени. Полезно для мониторинга ожидаемых и внезапных пиков логгирования пользователей	Диапазон времени (с минувшего часа и до суток до него)
Активность базы данных (Database Activity)	Показывает кол-во действий (удаление, чтение, вставка, обновление) на разных потоках БД PostgreSQL за период времени. Удобно для мониторинга ожидаемых или неожиданных пиков активности операций чтения/записи в БД PostgreSQL	Диапазон времени (с минувшего часа и до суток до него)
Подключения базы данных (Database Connections)	Показывает кол-во подключений PostgreSQL к серверу API (RaaS) за период времени. Полезно для мониторинга ожидаемых или неожиданных пиков активности в БД PostgreSQL	Диапазон времени (с минувшего часа и до суток до него)
Выполненные команды Redis (Redis Commands Executed)	Показывает кол-во команд, выполненных по отношению к серверу Redis за период времени. Удобно для мониторинга кол-ва запросов на информацию на уровне кэша Redis (результаты очереди и пр.)	Диапазон времени (с минувшего часа и до суток до него)
Задания (Jobs)	Отображает кол-во успешно выполненных заданий, потерянных возвратов, фейлов заданий или тех, что сейчас в прогрессе за период времени. Полезно для оценки активности системы в целом и ее производительности	Диапазон времени (с минувшего часа и до суток до него)
Мастера в SSE (Masters in SSE)	Показывает кол-во зарегистрированных в SaltStack Config мастеров за период времени. Полезно для мониторинга ушедших внезапно в даун мастеров, оценки, не появилось ли в системе больше мастеров, чем ожидалось и т.д.	Диапазон времени (с минувшего часа и до суток до него)
Присутствие миньонов (Minion Presence)	Демонстрирует кол-во миньонов, подключенных к мастерам через SaltStack Config за период времени. Удобно для отслеживания внезапно пропавших миньонов, или же обнаружения, вдруг в наличии больше миньонов, чем ожидалось.	Все мастера/указанные мастера, диапазон времени (с минувшего часа и до суток до него)

Доступ к рабочему пространству «Dashboard» осуществляется через одноименный пункт бокового меню.

Действия с отчетами в панели мониторинга

Чтобы добавить отчет на панель мониторинга в соответствующем рабочем пространстве кликаем на «Add Report», после чего в открывшемся меню выбираем название отчета, который хотим добавить. Каждый новодобавленный отчет появится в списке, и, если там уже есть какие-то примеры отчетов, он будет сверху в левом или правом столбце.

Фильтрация в отчетах по отношению ко времени выборки может меняться, и по дефолту выставлено всегда 12 часов. Чтобы поменять это значение, нужно кликнуть на фильтр продолжительности в левом нижнем углу отчета и выбрать интересующее. Прочие доступные фильтры (см. таблицу выше) расположены сверху отчета, и, если на них кликнуть, откроется меню, в котором выбирается интересующая детализация.

Отчеты можно выгружать в формате JSON или CSV. Для этого в рабочем пространстве «Dashboard» нажимаем на кнопку «Download» (стандартная пиктограмма) вверху отчета, который подлежит выгрузке, и выбираем формат – «Download JSON» или «Download CSV».

Важно! Некоторые отчеты могут иметь несколько выгружаемых файлов, если их диаграммы учитывают множество метрик, мастеров или инстансов RaaS. Проверить кол-во выгружаемых файлов можно наведясь мышкой на отчет – кол-во появившихся строчек и будет соответствовать кол-ву выгружаемых файлов.

Массив выгружаемых данных может быть импортирован в сторонние инструменты.

Также отчеты можно перемещать по панели мониторинга, кликнув на значок шести вертикальных точек («drag handle») и удерживая его до точки назначения.

И, наконец, ставшие неактуальными отчеты можно удалять, нажав на пиктограммку «мусорной корзины» («Delete») по ним.

Рабочее пространство отчетов («Reports»)

Доступ к рабочему пространству отчетов осуществляется из одноименного пункта бокового меню. Чтобы просмотреть любой отчет, выбираем его в рабочем пространстве и здесь также доступны разные функции фильтрации и сортировки колонок таблицы. Отфильтровать каждую колонку можно, используя пиктограмму «фильтра» и выбрав (или вбив) критерий фильтрации. Чтобы очистить фильтр, нажимаем на кнопку «Clear Filters» вверху таблицы.

Сортировка колонки осуществляется через выбор имени колонки. Чтобы настроить, какие колонки будут показываться в таблице, кликаем на кнопку «Show columns» в левом нижнем углу таблицы.

Отчеты можно выгружать и из их собственного рабочего пространства, а не только из панели мониторинга. Формат выгрузки аналогично будет JSON или CSV, и для нее нужно кликнуть на вкладку отчета, который нуждается в выгрузке, затем нажимаем на «More actions», чтобы открыть меню и выбрать требуемый формат (JSON/CSV).

Важно! Не все таблицы в Reports позволяют выбирать определенные строки для экспорта. Если по отчету напротив какой-то его строки нет чек-бокса, выбрать ее не получится. Тогда экспортироваться может только все в комплексе по этому отчету.

Интересно, что некоторые отчеты можно отфильтровать по целевой группе. А вообще они предоставляют отображение важных метрик в среде SaltStack Config, в том числе данных, касающихся всех миньонов. Помимо упомянутого в таблице выше по отчетам в целом параметра присутствия (Presence), их можно отфильтровать по состоянию ключа (Key state), лицензии (Licenses) – отчет может включать линейный график истории использования лицензии за период времени (не выгружается), версии мастера (Master version), версии миньона (Minion version) и версии ОС.

Методы аутентификации в SaltStack Config

Как мы уже писали выше в подразделе, посвященном ролям, в SaltStack Config есть нативная система хранения локальных пользователей и управляется она из его UI. Кроме того, доступна синхронизация с LDAP или AD, где эти пользовательские аккаунты настраиваются. Также можно внедрить пользовательскую SSO-аутентификацию от сторонних провайдеров, использующую SAML и OIDC.

Важно! Можно комбинировать несколько разрешенных систем аутентификации для доступа в SaltStack Config, однако не более двух провайдеров SAML или двух провайдеров LDAP единовременно.

Аутентификация средствами SaltStack Config

В UI SaltStack Config существует специальное рабочее пространство для управления пользовательской аутентификацией «Local Users», и пройти в него можно с «Administration» боковой панели. Здесь можно создавать новых пользователей, клонировать уже существующих, обновлять их настройки, в т. ч. менять пароли и пр.

Создание/клонирование локального пользователя, изменение пользовательских настроек

Чтобы создать нового пользователя в рабочем пространстве «Local Users» нужно кликнуть на кнопку «Create», затем ввести его имя и пароль, а также выбрать любые роли, которые хотим, чтобы к нему применялись. По дефолту, любой новый пользователь присоединяется к роли User. Инициация создания происходит после нажатия на «Save».

Важно! Создавать новых пользователей может только Superuser (см. выше) или пользователи, в расширенных настройках роли которых выбрано разрешение «Create user».

Важно! Имена пользователей нечувствительны к регистру.

Клонирование пользовательского аккаунта производится здесь же, но, предварительно выбирается пользователь-оригинал, после чего кликаем на «Clone». Опять-таки вводим новое имя пользователя и его пароль, и выбираем роли, которые хотим ему назначить, а затем сохраняем настройку по «Save».

Чтобы отредактировать настройки пользователя, выбираем его в списке «Local Users», делаем все необходимые изменения, например, меняем его пароль, и нажимаем на «Save».

Аутентификация с SAML

Доступна интеграция с SSO для IdP, использующая протоколы SAML (ADFS, OneLogin, Okta, Shibboleth, SimpleSAMLPHP, Google Suite и др.) или OAuth, а также управление доступом для сервисов директорий на протоколе LDAP (например, Active Directory Domain Services).

Перед настройкой и отладкой SAML-аутентификации в SaltStack Config нужно установить SAML IdP и убедиться в его работоспособности, а также получить доступ к учетной его записи и конфигурационным данным. Далее нам нужно сгенерировать соответствующий сертификат, чтобы добавить в него SaltStack Config как одобренного сервис-провайдера. В процессе, обычно, вводятся значения приватного и публичного ключа в несколько мест. Вкратце, механизм следующий:

Приватный ключ:

openssl genrsa -out cert.pem 2048

Публичный ключ:

openssl req -new -x509 -key cert.pem -out cert.pub -days 1825

Отвечаем на запросы, если выскочат (название страны, штат/провинция, город/другая локаль, название организации, название юнита организации, имя хоста сервера, email-адрес).

Записываем результаты этих вводов где-нибудь себе – далее они нам понадобятся.

Важно! Такая пара ключей генерируется на любой системе – вовсе необязательно, чтобы это был SSE-сервер. Главное, чтобы были установлены утилиты openssl. Альтернативой этому действию может стать генерация само-подписанного сертификата прямо в Salt.

Теперь нам нужно настроить конфигурацию SAML. В UI SaltStack Config заходим в «Administration» – «Authentication» в боковом меню и нажимаем на «Create». Из меню «Configuration Type» выбираем «SAML» – рабочее пространство изменится в соответствии с настройками, которые мы можем задать в этом случае. Далее на вкладке «Settings» заполняем поля для информации о инсталляции SaltStack Config:

имя,
URI базы,
ID объекта,
название компании,
отображаемое имя,
веб-сайт.

А также в поле «Private Key» вносим записанный нами ранее приватный ключ, а в «Public Key» – публичный, соответственно. Далее заполняем контактную информацию (технический специалист, саппорт – имена и еmail), а в секции «Provider Information» рассказываем все про нашего IdP:

ID объекта,
ID пользователя,
еmail,
имя пользователя,
URL,
x509-сертификат.

По дефолту стоит галочка в «Attribute Statement Check», чтобы SaltStack Config проверял SAML Attribute Statements для пользовательских профилей. Это опционально.

Сохраняем всю настройку кнопкой «Save».

Для завершения настройки, нам нужно предоставить нашему IdP «AssertionCustomerService URL» – веб-адрес, который используется сервис-провайдером (для нас сейчас это SaltStack Config) для приема сообщений и артефактов от SAML при установке идентичности вставки, а также публичный ключ x509, сгенерированный и записанный нами ранее. Выглядеть AssertionCustomerService URL может, например, вот так: «https:// /auth/complete/saml <SSE-имя хоста>/auth/complete/saml».

Далее, руководствуясь документацией нашего конкретного IdP-провайдера, производим сопоставление атрибутов по пользователю, а конкретно SaltStack Config нужно предоставить по каждому из них такие данные: ID пользователя, еmail и имя пользователя.

Замечание: Многие организации все три эти атрибута объединяют в корпоративную почту пользователя, уникальную в рамках этой организации.

Настройка RBAC для SAML

Управление RBAC для SAML происходит точно по тому же принципу, что и нативный способ управления пользователями в SaltStack Config. По дефолту, новый пользователь регистрируется в SaltStack Config только после того, как осуществит свой первый вход в SAML. Альтернативно, можно добавлять пользователей вручную для предрегистрации их в SaltStack Config. Для этого:

В рабочем пространстве «Authentication» выбираем нашу SAML-конфигурацию из списка «Authentication Configs» – откроются соответствующие параметры;
Проходим на вкладку «User» и нажимаем кнопку «Create»;
Вводим идентичное имени пользователя в SAML имя в поле «Username»;

Важно! После создания пользователя его имя нельзя будет изменить.

В поле «Roles» выбираем роли, которые хотим для этого пользователя (по дефолту там будет «User»);
«Save».

Важно! Удалить этого пользователя можно только до того, как он впервые залогинится, соответствующей кнопкой. Впоследствии кнопка будет доступна, но работать перестанет.

Редактирование/удаление конфигурации SAML

Чтобы изменить существующую SAML-конфигурацию, нужно пройти в «Administration» – «Authentication» бокового меню, выбрать из списка нужную и отредактировать поля, как необходимо, после чего нажать на «Save».

Если SAML-конфигурацию требуется удалить, в том же рабочем пространстве выбираем нужную из списка, затем жмем на кнопку «Delete» и еще раз на такую же – в подтверждающем диалоговом окне.

Важно! Учтите, что конфигурация SAML удалена, но не ассоциированные с ней пользователи и группы – созданные через этот аутентификационный сервис задания и другие объекты будут оставаться в SaltStack Config и получать собственника от других объектов.

Аутентификация с LDAP

Перед настройкой LDAP вначале надо создать подключение, которое разрешит указанным группам и пользователям LDAP аутентифицироваться в SaltStack Config. Как только это будет сделано, можно определять их RBAC-параметры.

Важно! Опционально, но рекомендовано, перед настройкой LDAP протестировать связь и запросы, используя сторонние инструменты. Например, в случае AD могут помочь LDP или ADSI Edit. Пользователям Linux стоит рассмотреть ldapsearch.

На практике, нам нужно зайти в «Administration» – «Authentication» бокового меню и нажать на «Create». В меню «Configuration Type» выбираем «LDAP». По желанию, под «Settings» можно кликнуть на «Prefill Defaults» и выбрать сервис директорий из выпадающего меню для автозаполнения дефолтными настройками, кастомизированными под имеющийся сервис директорий (AD/OpenLDAP). Однако учтите, что некоторые строки, например, «User Search DN» будут не заполнены – в них значения нужно ввести самостоятельно, в соответствии с вашей схемой сервиса директорий. Вообще же, для ввода доступны следующие параметры, по разделам.

Базовые:

имя,
хост,
порт,
Background Sync (устанавливается интервал в минутах, с которым SaltStack Config будет валидировать всех пользователей и пользовательские группы с бэкендом аутентификации),
SSL (выбираем «Enable SSL», используя указанный в настройках сервера RaaS сертификат, – если этого не сделать, будут применяться системные сертификаты, по best practice обязательно нужно включить, иначе связь будет незащищенной, и выбираем «Validate Certificate»).

Аутентификация:

Auth Base DN (базовое LDAP Distinguished Name – откуда группы и пользователи будут делать запросы, например, «DC=sse, DC=example, DC=com»),
Admin Bind DN (DN администратора, настроенное для сервера LDAP, примеры синтаксиса: «cn=Administrator, cn=Users, dc=example, dc=com»),
Admin Bind DN Password (личный пароль администратора),
Auth Bind DN Filter (фильтр, применяемый в выборе конкретного пользователя, результатом должен быть DN пользователя, применяемый SaltStack Config для привязки к директории и дачи доступа пользователю к себе. Например, для DevOps или Level II-группы пример синтаксиса может быть таким:

(&(objectclass=user)(sAMAccountName= ˓→{username})

(|(memberOf=CN=DevOps,OU=Groups, ˓→OU=Test Company HQ,DC=adtest,DC=com)

(memberOf=Level II,OU=Groups, ˓→DC=adtest,DC=com)))

Но, лучше свериться ldapsearch,

Важно! Если настраивается структура типа леса, это поле оставляем пустым.

Remote Unique ID Attribute Name (имя значения, используемого в идентификации уникальных строк – уникальный ID-атрибут для всех строк. Для AD, например, это «ObjectGUID»).

Группы:

Group Search DN (поисковая база для групп. Например, в AD это должно быть «cn=Groups, dc=example, dc=com»),
Group Search Scope (глубина поиска по директории, указанной в «Group Search DN», может иметь значения:

«baseObject» – соответствует «base», значение 0, только для поиска этого объекта и никакого другого,

«singleLevel» – соответствует «one», значение 1, только для рассмотрения непосредственных дочерних элементов base на предмет совпадений,

«wholeSubtree» – соответствует «sub», значение 2, для поиска базы и всех ее подчиненных на любую глубину,

«subordinateSubtree» – соответствует «subordinates», значение 3, то же самое, что и «wholeSubtree», но строка поиска базы игнорируется),

Group Search DN Filter (фильтр поиска для выделения групп из директории, обычно это «(objectClass=group)», но некоторые конфигурации AD могут использовать «(objectCategory=group)», для большей детализации рассмотреть назначение настройки «Group Class» – см. ниже),
Group Class (имя класса объекта, используемое в определении группы, например, «groupOfNames»),
Group Name Attribute (название атрибута, который хочется использовать в имени группы – должно быть однозначным),
Group Membership Attribute (название атрибута в строке «user», содержащее имя группы, например, «memberOf»).

Пользователи:

User Search DN (поисковая база для пользователей, например, «cn=Users, dc=example, dc=com» в AD или «cn=people, cn=accounts, dc=example, dc=com» в других сервисах),
User Search Scope (показывает глубину поиска по директории из указанной в «User Search DN» базы, может иметь одно из четырех значений – аналогичных «Group Search Scope», см. выше),
User Search DN Filter (поисковый фильтр для извлечения пользователей из директории, обычно, «objectClass=person», но в некоторых конфигурациях AD это может быть «objectCategory=user»),
Person Class (имя класса сервиса директорий, содержащего пользователей, которых хочется включить в систему логгирования, в AD и большинстве других сервисов это «person», но может быть и «user» или «inetOrgPerson»),
User ID Attribute (уникальное имя атрибута пользовательского аккаунта, для AD это «sAMAccountName», для других сервисов, обычно, «uid» или «memberUid»),
User Membership Attribute (имя атрибута в записи группы, содержащее имя пользователя, пример – «member» или «uniquemember»).

После всего этого, чтобы проверить, правильно ли заданы настройки, можно нажать на «Update Preview», и, если все хорошо, окончательно сохраняем их кнопочкой «Save».

Работа с пользователями и группами

Для уверенности, что наши пользователи смогут залогиниться, и настройки групп сервиса директорий проходим в рабочее пространство «Authentication» и выбираем нужную конфигурацию LDAP. На вкладке «Groups» увидим список групп, полученный из LDAP (если групп слишком много, загрузка этой страницы может растянуться на минуту). Теперь выбираем нужную группу и на ее вкладке «Users» получим список всех выгруженных из LDAP пользователей (аналогично – чем их больше, тем дольше будет прорисовываться список). Здесь снимаем галочки со всех пользователей, которым нужно запретить доступ к SaltStack Config (вначале все будут выделены):

И нажимаем «Save» для сохранения настроек.

Также можно удалять целые группы или конкретных пользователей из того же рабочего пространства и соответствующей конфигурации LDAP: первое делается на вкладке «Groups», а второе – на «Users». И там, и там, все имеющие возможность аутентифицироваться выделены галочками – просто их снимаем с тех, кому нужно запретить доступ, и опять сохраняемся по «Save».

Редактирование параметров конфигурации LDAP и ее апдейт/удаление

Если нужно вручную отредактировать конфигурацию LDAP, в рабочем пространстве «Authentication», выбираем ее и просто меняем поля по своему усмотрению, например, в поле «Admin Bind password» можно поменять пароль, если кликнуть на «Change Password» и ввести новый.

LDAP – такая штука, ресинхронизация с которой и получение от которой обновлений жизненно важны, причем постоянно. Добавили ли вы новых пользователей и их нужно инициировать в SaltStack Config или произошло что-то еще – причин может быть масса. С целью апдейта конфигурации LDAP в «Authentication» под нужной конфигурацией LDAP проходим на вкладку «Settings» и кликаем на «Update Preview» – отразится информация о последних пользователях и группах, полученная от сервиса. После чего сохраняем обновление «Save».

Удалить, в случае необходимости, конфигурацию LDAP очень просто: находясь там же, выбираем ее и нажимаем на «Delete»:

После чего в подтверждающем диалоговом окне еще раз нажимаем на «Delete». Учтите, что удаленная конфигурация уйдет вместе со всеми ассоциированными пользователями и группами. Но, созданные ими задания и другие объекты останутся в SaltStack Config под собственником «root».

Аутентификация с OAUTH и OIDC

OAuth Sign-On (SSO) позволяет уменьшить время, затраченное пользователями для подписки на сервисы с одинаковой идентификацией, кроме того ему нужно помнить только один набор данных учетной записи для автоматического доступа ко множеству сервисов. Альтернативой этому протоколу является OIDC (OKTA, Google, Microsoft, GitLab, Zendesk, Apple, Keycloak, Salesforce и другие), однако, следует помнить, что текущая версия SaltStack Config поддерживает только OKTA и Google типы.

Чтобы включить такую аутентификацию, на веб-сайте OAuth следует ввести базовую информацию, касающуюся SaltStack Config (имя, веб-сайт и т.п. – индивидуально, по запросу). После регистрации приложения будут предоставлены секретные данные клиента, которые придется задать в SaltStack Config.

Важно! При описанном создании приложения важно зарегистрировать более одного прямого его URL – они будут использоваться сервисом OAuth 2.0 в перенаправлении пользователя, после того, как они авторизуют приложение.

В клиенте SaltStack Config заходим в «Administration» – «Authentication» бокового меню и нажимаем на «Create»;
В меню «Configuration Type» выбираем «OIDC»;
В поле «Name» присваиваем этой конфигурации информативное имя;
В меню «OIDC Provider» выбираем OKTA/Google;
Заполняем информацию об инсталляции SaltStack Config (базовый URI – URL, используемый организацией для SaltStack Config в формате FQDN или IP-адреса, API URL – только для OKTA, поддерживаем провайдером идентификации, ключ – в OKTA, например, это Client ID, секретные данные – см. выше);
Запускаем создание кнопкой «Save».

Работа с RBAC для OIDC

Чтобы пользователя можно было добавить в локальную базу данных, ему необходимо вначале войти в SaltStack Config. После этого его роли и разрешения управляются точно так же, как и те, что хранятся локально в SaltStack Config на RaaS-сервере. Можно использовать рабочее пространство «Roles», чтобы назначать соответствующие роли и разрешения определенному пользователю – обо всем этом подробно говорилось выше в соответствующем разделе.

Редактирование параметров конфигурации OAuth и OIDC и ее апдейт/удаление

Чтобы поменять единожды заданные настройки OAuth и OIDC, заходим в «Administration» – «Authentication» бокового меню, выбираем нужную конфигурацию, меняем ее поля желаемым образом и сохраняем настройку снова кнопкой «Save».

Если необходимо удалить заведенную конфигурацию, там же выбираем искомую OIDC и нажимаем на «Delete». Появится подтверждающий диалог, в котором еще раз кликаем на «Delete».

Важно! Конфигурация удалится, однако не ассоциированные с ней пользователи и группы. Задания и другие объекты, созданные этими пользователями, останутся в SaltStack Config и получат собственника от других объектов.

Апдейт SSL-сертификатов

Чтобы заменить истекающий TLS-сертификат на SSE-сервере нужно найти конфигурационный файл «/etc/raas/raas» и найти в нем такие строки:

tls_crt: /etc/pki/raas/certs/localhost.crt

tls_key: /etc/pki/raas/certs/localhost.key

И сделать бэкап файлов «tls_crt» и «tls_key». Затем получаем обновленный сертификат и ассоциированный с ним ключ и копируем файлы в ту же локацию, дав им те же имена (в принципе, можно и переместить эти файлы куда-то еще, но нужно будет и изменить вышеупомянутые строки соответствующим образом). Далее убеждаемся, что пользователь raas является собственником этих файлов и разрешения выставлены на 600 (или «-rw——-»), и перезапускаем сервер SSE:

systemctl restart raas

Заходим на URL SSE в браузере и проверяем, обслуживает ли веб-сервер контент. Используя инструменты браузера, убеждаемся в валидности деталей сертификата и в выставлении желаемой даты его истечения.

Добавление/удаление настраиваемого сообщения на экран логина (опционально)

По желанию, на экран логина пользователя можно добавить информационное или предупреждающее сообщение для всех пользователей. Оно может быть любой длины и принадлежать одному из визуальных стилей: info (темно-синий бокс с белым текстом и информационной иконкой) и warning (темно-оранжевый бокс с белым текстом и предупреждающей иконкой).

Чтобы создать такое сообщение:

Из командной строки ноды сервера RaaS проходим в конфигурационный файл «/etc/ raas/raas» и открываем его на редактирование (может понадобиться доступ администратора);
Добавляем в этот файл такую секцию (вместо базовой):

login_banner:

enabled: true # Set to false to disable the message

style: info # Alternate available style: warning

message: >

текст настраиваемого сообщения.

Сохраняем файл;
Перезапускаем сервис RaaS командой:

systemctl restart raas

Чтобы удалить такое сообщение вовсе, проделываем пункты с 1 по 4, но в секции «login_banner» по параметру «enabled» меняем его значение на «false».

Опции настройки SaltStack Comply

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

Для начала, напомним список опций настройки SaltStack Comply:

stats_snapshot_interval – как часто (в секундах) будет собираться статистика SaltStack Comply;

compile_stats_interval – как часто (в секундах) будет компилироваться статистика SaltStack Comply;

username – имя пользователя, участвующее в подключении SaltStack Config для загрузки самого последнего контента SaltStack Comply (по дефолту это «secops»);

content_url – URL, используемый в загрузке контента SaltStack Comply (по дефолту это «enterprise.saltstack.com/docs/downloads. html#saltstack-comply-and-protect-content»);

ingest_override – перезапись существующих ориентиров и проверок при приеме нового контента (по дефолту «True»);

locke_dir – путь, где прием ожидает найти новый контент (по дефолту «locke»). Если используется относительный путь (не начинается с «/»), то он относится к каталогу кэша сервиса RaaS «/var/lib/raas/cache»;

post_ingest_cleanup – удалить весь расширенный контент из файловой системы после приема (по дефолту «True»);

download_enabled – позволено ли загружаться контенту SaltStack Comply (по дефолту «True»). Если air-gapped-система, устанавливаем «False»;

download_frequency – как часто (в секундах) сервис RaaS будет предпринимать попытку загрузить контент SaltStack Comply (по дефолту «86400» – сутки);

ingest_on_boot – нужно ли RaaS-сервису предпринимать попытку загрузить контент SaltStack Comply при каждой загрузке (по дефолту «True»);

content_lock_timeout – как долго (в секундах) будет длиться блокировка загрузки контента (по дефолту «60»);

content_lock_block_timeout – как долго (в секундах) будет блокироваться блокировка загрузки контента до отказа (по дефолту «120»).

Выставив их желаемым образом можно приступать к созданию фундаментальной составляющей SaltStack Comply – политики. Именно на предмет соответствия с ней впоследствии системы будут отсканированы.

Построение, редактирование политики

На домашней странице SaltStack Comply кликаем на «Create policy», вводим ее имя и выбираем цель, к которой она будет применяться. После клика на «Next» делаем следующее:

На вкладке «Benchmarks» выбираем все опорные отметки, которые хотим включить в политику. «Next»;

Важно! Если ни одной опорной отметки не показывается, нужно загрузить контент соответствия.

Важно! При работе с опорными отметками Windows Server, выбирать их стоит только родственного типа. Существующие типы: контент домен-контроллера, контент членов, контент домен-контроллера + контент членов. Например, если включается контент членов («Member»), то, галочки нужно ставить не только на нем, но и на контенте домен-контроллера + членов («Domain controller and member»).

На вкладке «Checks» выбираем все проверки, которые хотим включить в политику (список конкретизируется после выбора опорных отметок). Чтобы видеть больше деталей проверки и ассоциированное восстановление, можно нажать на иконку двойной стрелочки. Проверки SaltStack обозначены значком «щита», а пользовательские – «силуэтом бюста человека». Доступен для удобства фильтр, а, чтобы убрать все ранее использованные фильтры, нужно нажать на «Clear Filters». «Next»;
На вкладке «Variables» вводим или изменяем переменные, либо же применяем их по дефолту. «Next»;

Важно! Рекомендуется использовать дефолтные значения.

В «Schedule» определяем частоту проверок согласно расписанию (Recurring/Repeat Date & Time/Once/Cron – см. выше в рассказе о расписаниях) и жмем «Save». Опционально можно выбрать «Run assessment on save»;

Окончательно кликаем на «Save», чтобы сохранилась наша новая политика. Если выбрана последняя опция, она сразу же запустится на проверку.

Чтобы впоследствии отредактировать готовую политику, выбираем ее в списке и нажимаем на «Edit policy» в верхнем правом углу. Затем вносим изменения и сохраняем их по «Save».

Чуть подробнее стоит остановиться на информативных полях, в которых задаются данные каждой проверки (очень полезно разобраться в них, если собираетесь создавать кастомизированные политики и проверки). В их числе:

Description – краткое описание проверки,

Action – краткое описание действия, которое будет предпринято после исправления,

Break – используется только во внутреннем тестировании,

Global description – детальное описание проверки,

Osfinger – список значений «osfinger», для которых применяется проверка. Этот параметр можно найти по каждому миньону в «grains.items», и он определеяет ОС миньона и версию ее мажорного релиза,

Profile – список конфигурационных профилей для разных опорных отметок (профилей, которые нацелены на различие ролей машины в среде и разные уровни безопасности),

Rationale – описание обоснования проведения проверки,

Refs – перекрестные ссылки соответствия между опорными отметками,

Remediate (присутствует не во всех проверках) – значение, показывающее, может ли SaltStack Comply исправить несоответствующие ноды,

Remediaton – описание, как любые несоответствующие системы будут исправлены, если подобное возможно, в принципе,

Scored – значение CIS опорной отметки (True/False). Рекомендации, отмеченные как «Scored», влияют на оценку опорной отметки цели,

State file – копия Salt State, которая будет применена, чтобы выполнить проверку и, если это возможно, последующее исправление.

Обновление библиотеки соответствия

Под «Administration» – «SecOps» бокового меню выбираем «Compliance Content» – «SaltStack», затем нажимаем на «Check for updates».

Запуск оценки, просмотр и выгрузка ее результатов

Важно! Политики могут включать множество проверок, и оценка иногда занимает существенное количество времени. Также процесс может откладывать другие процедуры, например, запуск заданий.

Чтобы запустить оценку на главной странице SaltStack Comply выбираем нужную политику и на ее страничке кликаем на «Run assessment». Появится окно «Activity». Здесь показываются выполненные оценки с отметкой о статусе, JID и другой информацией. Статус может быть «Queued» (операция запущена, но миньоны еще не подхвачены задачей), «Completed» (завершена) и «Partial» (операция ждет возврата некоторых миньонов, хотя со стороны мастера поступил ответ, что она успешно завершилась).

Важно! В процессе оценки важно избегать каких-либо изменений, даже если система показала несоответствия и предложила их исправить. Исправление ошибок будет доступно позднее.

Результат оценки можно просмотреть, выбрав нужную политику на странице SaltStack Comply (можно воспользоваться фильтром для удобства). Также доступна сортировка результатов после клика на заголовок колонки. Чтобы посмотреть результаты оценки по миньону, нужно зайти на вкладку «Minions». Отчет о произведенной выводится там же по выбранной политике, но на вкладке «Report». Если здесь нажать на «Download» и выбрать в выпадающем меню «JSON», браузер начнет загружать отчет.

Исправление проверок и исключения из него

Вообще, по результатам проверки каждая система вернет один из следующих статусов:

Compliant – все соответствует,

Not compliant – найдены несоответствия с опорными отметками. Рекомендовано исследование причин и исправление,

Not Applicable – неприменимо к этой системе (например, проверка CentOS на AIX),

Unknown – проверка или исправление еще не были запущены,

Error – обнаружена ошибка в процессе оценки или исправления.

Все найденные несоответствия подлежат исправлению. Можно выбрать исправление конкретных проверок или миньонов, либо же исправить все, что было обнаружено сразу и везде. Для последнего на странице SaltStack Comply выбираем политику с самыми свежими результатами оценки и на ее вкладке «Checks» нажимаем в верхнем правом углу на «Remediate all», и снова подтверждаем свое решение аналогичной кнопкой в выскочившем диалоговом окне.

Следить за прогрессом исправления можно на вкладке «Activity». А когда оно завершится, чтобы убедиться, что теперь все системы приведены в состояние соответствия, стоит запустить оценку еще раз.

Если же нужно исправить только то, что касается определенной проверки, на экране политики выбираем последнюю проверку, где результаты будут выведены списком в по-миньонном порядке. Здесь можно воспользоваться фильтром, либо же просто найти всех нужных миньонов, подлежащих исправлению и выбрать их галочками, после чего кликнуть на «Remediate».

Если нужно исправить то, что касается только одного или нескольких миньонов, на экране политики проходим на вкладку «Minions», выбираем нужных и опять-таки нажимаем на «Remediate».

Работа с исключениями из исправления после проверок

Иногда выбирать только подлежащие исправлению проверки или конкретных миньонов нецелесообразно – гораздо проще и быстрее определиться с теми, для кого это делать сейчас не требуется. Для этого существует функция добавления привилегий – освобождения от проверок. На экране политики выбираем проверки, которые хочется исключить из исправления и нажимаем на «Add exemption», вводим резоны, по которым это делается и кликаем на «Add exemption», чтобы зафиксировать привилегии. Впоследствии свой выбор всегда можно будет изменить.

Важно! Исключения можно добавлять, как до проверки, так и после нее. Также можно настроить кастомизированную политику, которая будет исключать проверки.

Аналогично можно заводить исключения по миньону(ам) на вкладке «Minions» экрана политики.

Удаление созданного исключения производится на вкладке «Exemptions», где доступен список всех сохраненных когда-либо исключений. Если их очень много, можно нажать на кол-во миньонов:

И тогда откроется список всех миньонов, к которым применялось исключение. Здесь можно нажать на кнопку «Remove exemption»:

И еще раз на такую же и подтверждающем диалоге.

Использование пользовательского контента

Чтобы пользовательские проверки стали доступны, прежде всего нудна инициализация SaltStack Comply Custom Content SDK, включающего файлы примеров, которые можно менять, чтобы создавать свои собственные проверки – по аналогии с опорными отметками. В SDK также есть тестовая среда на базе Docker, где новый контент тестируется на практике. Созданный и проверенный таким образом контент можно импортировать в SaltStack Comply, чтобы начать с ним работу в продакшене.

Инициализация SDK начинается с загрузки одноименного бинара в ОС отсюда, после чего в командной строке проходим в директорию, где находится скаченный файл, и запускаем его в соответствии с особенностями ОС:

Mac OS/Linux: «./secops_sdk init»;
Windows: «exe init».

После этого в директории будут файлы и папки («benchmarks», «salt/locke/custom», «sample_tests» и «README.md»).

Также необходимо загрузить и проинсталлировать Docker (если не умеете – вот его страница).

Создание пользовательской проверки и опорной отметки

Для создания пользовательской проверки проходим в «salt/locke/custom», делаем копию двух файлов с «.sls» и «.meta»-расширением (пример состояния и его соответствующий мета), переименовываем их и помещаем в ту же директорию, что и базовые (имена обоих должны быть одинаковыми – отличаются только расширениями). Открываем на редактирование файл состояния и меняем в нем то, что нам нужно, после чего сохраняем.

Чтобы создать пользовательскую опорную отметку, проходим в директорию «benchmarks» и копируем пример файла с расширением «.meta», переименовываем его и редактируем содержимое, после чего сохраняем. Учтите, что этот файл написан на YAML (мини-учебник по этому языку уже публиковался в нашем блоге и ознакомиться с ним можно по ссылке).

Тестирование пользовательского контента

В командной строке проходим в директорию «sample_tests» нашего Custom Content SDK и строим докер-образ, например, CentOS7 с Salt для теста, введя:

./build.sh

И для запуска теста контейнера:

./up.sh

Запуск проверок на тест (созданных по рекомендациям выше в директории «salt/locke/custom») может выглядеть, например, вот так:

./test.sh salt-call –local state.apply locke.custom.mounts.my_first_check ˓→test=True

Когда тест завершится, закрыть тестовый контейнер можно командой:

./down.sh

Построение пользовательской библиотеки контента и ее импорт в SaltStack Config

Когда пользовательский контент готов, открываем командную строку и проходим в корневую директорию Custom Content SDK, где вводим:

./secops_sdk build –a

В ней появится поддиректория «_dist», в которой будут два файла «tar.gz», которые можно использовать для импорта контента через UI SaltStack Config или API (RaaS). В первом случае проходим в «Administration» – «SecOps» бокового меню, затем в «Compliance Content» – «SaltStack» и кликаем на «Check for updates». Нажимаем на «Upload Package» и находим наш файл «.tar.gz» в проводнике. После этого пользовательский контент доступен для построения политик, запуска оценок и исправления систем.

Удаление пользовательской проверки и опорной отметки

Чтобы удалить пользовательскую проверку, проходим в «SecOps» – «Checks» и кликаем на меню «три вертикальные точки» напротив той проверки, которую хотим удалить, после чего выбираем «Delete».

Важно! Удалить можно только пользовательский контент (отмеченный значком бюста человечка) – именно поэтому выше в теме о контенте SaltStack мы эту функцию не рассматривали.

Появится диалоговое окно, где в «In Use» будет показан список политик и опорных отметок, включенных в эту проверку. Лучше избегать любых зависимостей в среде, которые могут повредиться, если удалить эту проверку. Если все нас устраивает, нажимаем на «Next», а затем, под «Delete Check» – «Warning» снова кликаем на «Delete». Закрываем диалоговое окно кнопкой «Done».

Для удаления опорной отметки проходим в «SecOps» – «Benchmarks» и кликаем на меню трех вертикальных точек напротив ставшей ненужной отметки, где выбираем «Delete».

Важно! Только пользовательские опорные отметки могут быть удалены.

В диалоговом окне под «In Use» просматриваем список ассоциированных политик и проверок, убеждаемся, что никакие зависимости не пострадают, после чего нажимаем на «Next». В «Delete Benchmark» – «Warning» кликаем на «Deletе», после чего по «Done» закрываем диалоговое окно.

Опции настройки SaltStack Protect

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

Для начала, напомним список опций настройки SaltStack Protect:

vman_dir – путь, где прием ожидает найти новый контент. Если используется относительный путь (не начинается с «/»), то он относится к каталогу кэша сервиса RaaS «/var/lib/raas/cache»;

download_enabled – позволено ли загружаться контенту SaltStack Protect (по дефолту «True»). Если air-gapped-система, устанавливаем «False»;

download_frequency – как часто (в секундах) сервис RaaS будет предпринимать попытку загрузить контент SaltStack Protect;

username – имя пользователя, участвующее в подключении к «enterprise.saltstack.com» для загрузки самого последнего контента;

content_url – URL, откуда будет производиться загрузка контента;

ingest_on_boot – нужно ли RaaS-сервису предпринимать попытку загрузить контент SaltStack Protect при каждой загрузке (по дефолту «True»);

compile_stats_interval – как часто (в секундах) будет компилироваться статистика SaltStack Protect;

stats_snapshot_interval – как часто (в секундах) будет собираться статистика SaltStack Protect;

old_policy_file_lifespan – срок жизни (в днях) файлов старой политики, которые остаются в файловой системе RaaS;

delete_old_policy_files_interval – как часто удалять (в секундах) старые файлы политики SaltStack Protect из файловой системы RaaS;

tenable_asset_import_enabled – разрешение на посылку зерен миньонов в SaltStack Config на Tenable.io для сопоставления активов (по дефолту «True»);

tenable_asset_import_grains – активация импорта списка зерен миньонов на Tenable.io, если по «tenable_asset_import_enabled» значение «True».

Важно! SaltStack Protect поддерживает только SaltStack Protect fqdn, ipv4, ipv6 и имя хоста в поле, но, можно отправлять и другую информацию, если указать настраиваемые зерна. Почитать о написании пользовательских зерен можно здесь.

Доступ к рабочему пространству SaltStack Protect получается через UI, если в боковом меню нажать на «Protect». Здесь доступна соответствующая панель, где отразятся все созданные в будущем политики безопасности и будут доступны с ними действия. Панель, в том числе, полезна и в плане получения общего видения по защите, с ее помощью можно делиться статусами с другими и оценивать уязвимость системы для выработки стратегии управления на любой срок времени.

Панель «Protect» можно сохранить в PDF-формате, если кликнуть на «SecOps», а затем выбрать вкладку «Vulnerability», после чего в меню браузера нажать на «Print».

Создание и редактирование политики

В рабочем пространстве «Protect» нажимаем на «Create policy», вводим ее имя и выбираем цель, к которой хотим, чтобы она была применена. Определяем частоту расписания (Recurring/Repeat Date & Time/Once/Cron Expression) и опционально можно выбрать «Run assessment on save», чтобы оценка запустилась сразу после сохранения политики, которое окончательно создаем кнопкой «Save».

Важно! Сканирование большого кол-ва миньонов может занять много времени, а также задерживать другие процессы, вроде запуска заданий, к примеру.

Чтобы отредактировать единожды созданную политику, выбираем ее в рабочем пространстве и на ее панели кликаем на «Edit policy» в верхнем правом углу. После внесения изменений сохраняем настройку по «Save».

Запуск оценки и работа с ее результатами

В нашем рабочем пространстве выбираем созданную политику и на ее панели (либо прямо из общего списка, поставив галочки напротив нужных политик и нажав на «Run assessment») кликаем на «Run assessment» и на аналогичную кнопку в подтверждающем диалоге.

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

Чтобы отслеживать статус оценки, кликаем либо на саму политику в рабочем пространстве «Protect», либо в панели политики проходим на вкладку «Activity», где будет выведен список всех завершенных, либо еще находящихся в процессе оценки сканирований и исправлений. Начальный статус любой новой запущенной оценки – «Queued». Затем он может поменяться на «Partial» (в прогрессе, но еще не завершена) и на «Completed», когда все миньоны вернут ответ. Иногда в процессе полезно рефрешить браузер.

Чтобы увидеть результаты последней оценки следует открыть саму политику. Больше деталей по каждой может дать иконка «двойной стрелочки». Также можно пройти на вкладку «Minions», чтобы вывести результаты, отсортированные по-нодно. Там, кстати, тоже доступна удобная фильтрация. Выгрузка результатов оценки производится из этой же панели, со вкладки «Report», где нужно нажать на «Download» и выбрать из меню «JSON», после чего веб-браузер начнет загружать отчет.

Импорт сторонних инструментов сканирования безопасности

SaltStack Protect поддерживает сканирование безопасности от многих вендоров. В т. ч. Tenable, Rapid7, Qualys и Kenna Security, или через коннектор Tenable.io. Оно может напрямую импортироваться в SaltStack Config и исправлять по советам обнаружения проблем. Чтобы воспользоваться этой возможностью, нужно импортировать сторонний скан в политику безопасности, и тогда рабочее пространство «Import Staging» покажет список рекомендаций, которые уже были импортированы, а также те, которые сейчас импортировать сюда не получается (неподдерживаемые – обязательно с объяснением, почему).

Рассмотрим работу с ними на примере Tenable. В установленном инструменте запускаем сканирование и экспортируем его в поддерживаемый формат файла (для Tenable это Nessus, для Rapid7 InsightVM Export – XML, Qualys – XML и для KennaSecurity Export – CSV).

Важно! Выбираем сканер, расположенный в той же сети, что и целевые ноды. Затем указываем IP, который хотим сканировать.

Теперь в рабочем пространстве SaltStack Protect создаем политику безопасности, нацеленную на эти же ноды. На панели политики нажимаем на «Policy Menu» (иконка «птички») и выбираем «Import Vendor Scan Data» – откроется рабочее пространство «Import Staging». Здесь кликаем на «Import» – «File Import» и выбираем вендора стороннего сканера. После этого SaltStack Protect сопоставит наших миньонов с нодами, идентифицированными сканом, а также рекомендации относительно их. Когда загрузка завершится, рабочее пространство «Import Staging» покажет список «Supported Vulnerabilities» и список «Unsupported Vulnerabilities» в двух таблицах. Там можно использовать фильтры и стандартную сортировку, чтобы оценить и сгруппировать рекомендации.

Важно! Здесь могут не показываться некоторые дополнительные данные, поднятые сторонним сканером. Чтобы открыть и их, следует нажать на кнопку «Show Columns» и поставить галочки напротив тех типов данных, которые хотим увидеть.

Далее можно нажать на «Import All Supported», чтобы импортировать все поддерживаемые рекомендации, либо же проставить галочки напротив конкретно интересующих и кликнуть на «Import Selected». В результате в оценке на панели политики появятся эти советы и можно будет ими воспользоваться для исправления.

Исправление по рекомендациям

После получения рекомендаций в результате проверки можно запустить исправление всего и вся кнопкой «Remediate all» в верхнем правом углу, зайдя в нужную политику в рабочем пространстве «Protect». Вылетит подтверждающий диалог, в котором жмем точно такую же кнопку. За процессом исправления можно следить на вкладке «Activity» политики.

Также можно запустить исправление по указанным рекомендациям, кликнув на политику, задав нужный фильтр, поставив галочки в выбранном и нажав на кнопку «Remediate». Или же по миньону – из ее вкладки «Minions», проделав то же самое.

Важно! Исправление может потребовать полный ребут системы, а иногда и несколько. Чтобы понять, случится ли перезагрузка, предварительно следует запустить оценку. Проверить, предстоит ли он, можно через рекомендации (вкладка «Advisories» панели политики – колонка «Install Behavior», где может быть один из статусов: Never requires reboot/Always requires reboot/Can require reboot/( – ), последнее – только для Linux-миньонов) или через миньона (вкладка «Minions» панели политики, колонка «Needs Reboot», где может быть значение «false»/«true»).

Если любой из методов подтвердил необходимость перезагрузки, нужно зайти в политику по нуждающемуся в этом действии миньону и нажать на кнопку «Run Command», после чего в меню «Function» выбрать команду «system.reboot», а в поле «Arguments» добавить соответствующие аргументы. Для Windows-нод их два: «timeout» и «in_seconds». Первый выставляем на «0», а второй – на «true». Если речь о Linux-нодах, аргумент будет только один – «at_time». Опционально можно создать расписание, которое будет перезагружать в указанное время, создать задание по перезагрузке миньона и т. п. Когда все выбрано, окончательно жмем на кнопку «Run Command», чтобы отправить ноды в перезагруз.

Важно! Некоторые исправления Windows могут потребовать полной перезагрузки системы.

Добавление и удаление исключений

Некоторых миньонов можно исключать из процесса исправлений по найденным рекомендациям в отношении уязвимостей безопасности. Для этого на панели политики проставляем галочки напротив советов, которые хотим исключить из исправления и нажимаем на «Add exemption», и еще раз на аналогичную – в подтверждающем диалоге, где кроме того нужно будет ввести причину исключения.

Либо же можно это сделать из вкладки «Minions», если хотим задать исключения не по рекомендациям, а по конкретным миньонам. С этой целью просто ставим напротив нужных галочки и снова жмем на «Add exemption». В последующем диалоговом окне – все аналогично.

Если исключение стало неактуальным, от него можно избавиться, если выбрать нашу политику и на ее панели пройти на вкладку «Exemptions», где ищем нужные исключения (либо пользуемся фильтром) и нажимаем на «Remove exemption», а затем еще раз – в подтверждающем диалоге.

Обновление библиотеки уязвимостей

По дефолту библиотека SaltStack Protect принимает последний контент уязвимостей при загрузке сервера SaltStack Config, а также осуществляет проверку на обновления ежедневно. Если по каким-то причинам эти настройки были изменены, апдейтиться может потребоваться вручную, для чего проходим в «Administration» – «SecOps» бокового меню и в «Vulnerability Content» нажимаем на «Check for updates». После этого последний доступный контент начнет загружаться.

Использование интеграции SaltStack Config в vRA

Интеграционная информация и миньоны добавляются в облачные шаблоны vRA при помощи методов управления конфигурацией, в частности сценария cloud-init или Cloudbase-init скриптования. Далее мы можем настроить и использовать SaltStack Config в vRA для предоставления, настройки и разворота ПО на ВМ в любом масштабе с помощью автоматизации на основе событий, а также для определения и применения оптимального, соответствующего состояния софта по всей нашей среде.

Функционал интеграции полностью повторяет все то, что мы рассматривали для классики автономного SaltStack Config, разве что некоторые объекты меню располагаются в других местах: файл-сервер, задания, активности, опоры, миньоны и прочее – все будет доступным:

Из левой боковой панели можно достучаться до управляемых миньонов, зарегистрированных на данный момент в SaltStack Config:

Если кликнуть на один из них, можно увидеть связанные с ним зерна и активности:

А также раздел «File Server» секции «Config»:

И многое другое.

Помимо стандартных операций, рассмотренных нами выше в разделе «Управление и администрирование SaltStack» и других, интеграция позволяет разворачивать миньонов в vRA, а затем авторегистрировать их в системе мастера SaltStack Config. Кроме того, Cloud Assembly дает доступ к некоторым дополнительным улучшениям, помогающим в процессе разворота миньонов. Одним из примеров которых могут служить группы свойств.

Группы свойств Cloud Assembly и разворот миньонов

Если в интерфейсе компонента Cloud Assembly пройти в «Design» – «Property Groups», можно увидеть встроенную группу свойств «SaltStackConfiguration». Здесь по дефолту два постоянных значения свойств: «masterAddress» и «masterFingerPrint»:

Их можно использовать в облачных шаблонах Cloud Assembly для инсталляции миньонов на машине, развернутой через Cloud Assembly. После этого зарегистрированный в SaltStack Config миньон получает все преимущества функций управления конфигурацией, вроде оркестровки, управления состояниями и доставки приложений. Использование облачным шаблоном cloud-config для настройки миньона на машине может выглядеть, например, вот так:

inputs:

environment:

type: string

enum:

– Production

– Development

resources:

LinuxVM-Minion:

type: Cloud.vSphere.Machine

properties:

name: salt-minion-vra

cpuCount: 1

totalMemoryMB: 2048

imageRef: ‘https://build-artifactory.eng.vmware.com/symphony-infra-local/ubuntu/releases/xenial/release-20190605/ubuntu-16.04-server-cloudimg-amd64.ova’

cloudConfig: |

#cloud-config

runcmd:

– curl -L https://bootstrap.saltstack.com -o install_salt.sh

– sudo sh install_salt.sh -A ${propgroup.SaltStackConfiguration.masterAddress}

– sudo salt-call grains.set env ${input.environment} # example to pass grains

remoteAccess:

authentication: publicPrivateKey

sshKey: ssh-rsa your-public-key

networks:

– network: ‘${resource.vSphere_Network.id}’

vSphere_Network:

type: Cloud.Network

properties:

networkType: existing

Каждый раз, когда миньон пытается зарегистрироваться на мастере, дефолтной операцией для администратора станет ручной прием ключа, созданного на миньоне. Благодаря этому SaltStack Config сможет управлять миньоном и запускать для него задания. Кроме того, можно задать некоторые правила оркестровки, запускаемые через файл Reactor, отвечающие за автоматическое принятие миньона согласно ряду критериев. Например, если файл реактора выглядит вот так:

он будет искать события «salt/auth», показывающие, что миньон пытается аутентифицироваться с мастером SaltStack Config. Инструкции файла затем предусматривают поиск файла состояния «accept-key.sls» для дальнейших действий. А тот, в свою очередь, может использовать jinja для дальнейшего уточнения фильтрации, который из миньонов должен быть принят. Чтобы автоматически принимать и регистрировать в мастере миньонов с идентификаторами, начинающимися с, к примеру, «dev» или «oc-cool» следует прописать такое:

Вообще же, чтобы проинсталлировать и развернуть миньонов в облачном шаблоне vRA используется, как мы уже говорили выше, cloud-init (Linux) или Cloudbase-init (Windows) скриптование – что-то из них должно поддерживаться целевой машиной. В целом, нам нужно настроить источник машины в облачном шаблоне со значениями «minionId» и «cloudConfig», в соответствии с группой свойств SaltStackConfiguration. Первое должно отвечать указанному значению «/salt/minion_id» для секции cloudConfig в коде облачного шаблона.

Примером облачного шаблона разворота миньонов для машин на Linux может служить такой скрипт:

inputs: {}

resources:

LinuxVM-Minion:

type: Cloud.vSphere.Machine

properties:

name: salt-minion-vra

cpuCount: 1

totalMemoryMB: 2048

imageRef: ‘https://build-artifactory.eng.vmware.com/symphony-infra-local/ubuntu/releases/xenial/release-20190605/ubuntu-16.04-server-cloudimg-amd64.ova’

minionId: ‘${resource.LinuxVM-Minion.resourceName}’

cloudConfig: |

#cloud-config

runcmd:

– sudo echo ‘${resource.LinuxVM-Minion.resourceName}’ > /etc/salt/minion_id

salt_minion:

pkg_name: ‘salt-minion’

service_name: ‘salt-minion’

config_dir: ‘/etc/salt’

conf:

master: ${propgroup.SaltStackConfiguration.masterAddress}

master_finger: ${propgroup.SaltStackConfiguration.masterFingerPrint}

remoteAccess:

authentication: publicPrivateKey

sshKey: ssh-rsa your-public-key

networks:

– network: ‘${resource.vSphere_Network.id}’

vSphere_Network:

type: Cloud.Network

properties:

networkType: existing

А по миньонам для машин на Windows:

formatVersion: 1

inputs: {}

resources:

WindowsVM-Minion:

type: Cloud.vSphere.Machine

properties:

image: win2016

flavor: medium

customizationSpec: Windows

minionId: ‘${resource.WindowsVM-Minion.resourceName}’

networks:

– network: ‘${resource.wpnet.id}’

name: ‘${wpnet.name}’

assignPublicIpAddress: true

cloudConfig: |

#ps1_sysnative

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12; Invoke-WebRequest -OutFile C:\Salt-Minion-3002.2-Py3-AMD64-Setup.exe -Uri https://repo.saltstack.com/windows/Salt-Minion-3002.2-Py3-AMD64-Setup.exe

Start-Process -Wait -FilePath “C:\Salt-Minion-3002.2-Py3-AMD64-Setup.exe” -ArgumentList “/S” -PassThru

((Get-Content -path C:\salt\conf\minion -Raw) -replace “#master: salt”, “master: ${propgroup.SaltStackConfiguration.masterAddress}”) | Set-Content -Path C:\salt\conf\minion

((Get-Content -path C:\salt\conf\minion -Raw) -replace “#master_finger: ””, “master_finger: ‘${propgroup.SaltStackConfiguration.masterFingerPrint}'”) | Set-Content -Path C:\salt\conf\minion

Set-Content -Path C:\salt\conf\minion_id -Value ‘${resource.WindowsVM-Minion.resourceName}’

C:\salt\salt-call.bat service.restart salt-minion

wpnet:

type: Cloud.Network

properties:

name: wpnet

networkType: existing

Естественно, все что мы говорили в отношении разворота миньонов в разделах выше, действительно и в случае интеграции SaltStack Config в vRA. Речь о работе с миньон-сервисом, в целом, апдейте значения имени хоста и отпечатка в его конфигурации, а также о назначении идентификатора миньона на имя ресурса ВМ, которое будет использоваться для приема миньона на мастере Salt (см. в этой же главе выше).

Использование SaltStack Config для расписания

Попробуем установить планировщика вызовом API в SaltStack Config. Для этого заходим в клиент Python или на мост HTTP-RPC и запускаем скрипт:

schedule.save(name=”name_of_schedule_entry”,

schedule=<schedule description>,

masters=<list of targeted masters or `*` for all of them>,

tgt=<master+minion target description>,

cmd=<one of “local”, “runner”, or “wheel”>,

fun=”<name to schedule>”,

arg=<arguments to function>,

tgt_uuid=<uuid of existing target, use this or tgt, not both>,

job_uuid=<uuid of existing job, use this or fun/arg, not both>,

enabled=<True or False to enable the schedule after saving>)

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

Также можно установить планировщик путем конфигурирования миньонов. Для этого миньон указывается либо функцией «schedule.add», либо запуском состояния «schedule.present» по миньону:

salt <minion_to_schedule> <name_of_job> function=’cmd.run’ job_args=”[some command]” seconds=3600

Или, если необходимо, можно настроить планировщик без мастера, запустив вызов Salt напрямую на миньоне, используя «salt <minion_to_schedule> state.apply schedulestate» и файл «schedulestate.sls», например, вот так:

job1:

schedule.present:

– function: state.sls

– job_args:

– httpd

– job_kwargs:

test: True

– when:

– Monday 5:00pm

– Tuesday 3:00pm

– Wednesday 5:00pm

– Thursday 3:00pm

– Friday 5:00pm

Апгрейд SaltStack Config

Важно! Аддоны SaltStack Comply и SaltStack Protect обновляют свои библиотеки контента независимо от регулярного расписания релизов SaltStack Config. В идеале, клиенты назначают их автоматическую загрузку и прием через интернет или http-прокси. Но, можно делать это и вручную, правда, придется внести в свой график регулярную проверку источников на предмет этих обновлений и вносить все изменения самостоятельно каждый раз.

В процессе подготовки к апгрейду SaltStack Config обязательно следует проследить, чтобы текущий разворот пользовался последней версией Salt. В принципе, если имеем дело с обычной системой с нормальным доступом в интернет, он и так будет вовлечен в пакет обновления, поэтому никаких дополнительных телодвижений со стороны администратора не потребуется. Случай же air-gapped-систем и их отношений с апгрейдом Salt был рассмотрен выше, в подразделе «Апгрейд и/или инсталляция Salt и Python».

Важно! Не используйте инсталлятор для одно-нодовой структуры с целью апгрейда – потенциально это может уничтожить оригинальную имплементацию.

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

Затем, пошагово, нам нужно следовать такому плану:

Бэкапируем данные, включая конкретные файлы и директории, являющиеся критически важными для текущей инсталляции (см. выше);
Обновляем PostgreSQL (опционально, но рекомендовано);
Обновляем инфраструктуру Salt (опционально, но рекомендовано);
Загружаем файлы апгрейда;
Обновляем ноду RaaS;
Обновляем все мастера Salt, использующие Master Plugin.

Если вы уже работали ранее с SaltStack Config, причем это была версия 6.4.0 или более старая, конкретные рекомендации по апгрейду стоит смотреть в инструкциях к релизу каждой версии (там всегда прилагаются подробные гайды в PDF-формате). Кроме того, важно учесть следующие замечания и советы:

Никогда не пренебрегайте бэкапированием данных;
Планируйте апгрейд на часы, когда сетевая активность минимальна (обновление может занять до нескольких часов по времени – учтите это!);
Проверяйте БД на любую старую хранящуюся команду – она может запускаться даже в процессе апгрейда автоматически, при рестарте Master Plugin. Чтобы этого избежать, предварительно почистьте базу от старых команд или же назначьте заданиям функцию пропуска заданий, старше определенного времени;
Тестируйте апгрейд до разворота в тестовой среде;
Внимательно изучайте рекомендации к каждому новому обновлению.

В плане бэкапирования перед обновлением, помимо того, что было описано в подразделе «Принятие ключа Salt master и бекапирование данных» выше, следует создать бэкап схемы БД. Для этого, вначале, записываем себе где-то точное название базы PostgreSQL, а затем копируем ее контент, найдя на сервере файлы «postgres.conf» и «pg_hba.conf», зайдя в postgres как пользователь командой:

sudo su – postgres

и выведя имя БД:

psql

После этого выходим как пользователь из PostgreSQL командой «exit» и копируем контент в файл, например, вот так:

pg_dump -U salt_eapi raas_db_name > postgres_raas_backup_$(date +%Y-%m-%d).sql

Рекомендации по апгрейду PostgreSQL можно найти здесь, а об обновлении Salt мы уже сегодня говорили, когда готовились к развороту.

Чтобы обновить RaaS-ноду, предварительно сохраняем все изменения, сделанные в дефолтных настройках файловой системы, опорных данных и заданий как новые файлы или задания, а также отмечаем любые сделанные опорные назначения по отношению к дефолтным целям – все это мы впоследствии переприменим к нашей системе. Далее останавливаем сервис RaaS командой:

sudo systemctl stop raas

Удаляем файл логов в «/var/log/raas» и установленную версию API (RaaS):

sudo yum remove raas

Затем обновляем ноду RaaS путем установки последнего RPM, например, вот так:

sudo yum install raas-rpm-file-name.rpm

Теперь нужно восстановить данные из бэкапов «/etc/raas/raas», «/etc/raas/raas.secconf» и «/etc/raas/pki/» и проапдейтить разрешения для пользователя raas командой:

sudo chown -R raas:raas /etc/pki/raas/certs

Опционально, если собираетесь пользоваться SaltStack Comply, добавьте новую секцию в файл «/etc/raas/raas»:

sec:

ingest_override: true

locke_dir: locke

post_ingest_cleanup: true

username: ‘secops’

content_url: ‘https://enterprise.saltstack.com/secops_downloads’

download_enabled: true

download_frequency: 86400

stats_snapshot_interval: 3600

compile_stats_interval: 10

ingest_on_boot: True

content_lock_timeout: 60

content_lock_block_timeout: 120

А для SaltStack Protect туда же секцию:

vman:

vman_dir: vman

download_enabled: true

download_frequency: 86400

username: vman

content_url: ‘https://enterprise.saltstack.com/vman_downloads’

ingest_on_boot: true

compile_stats_interval: 60

stats_snapshot_interval: 3600

old_policy_file_lifespan: 2

delete_old_policy_files_interval: 86400

tenable_asset_import_enabled: True

Теперь апгрейдим базу данных сервиса RaaS:

sudo su – raas

raas upgrade

И выходим из сеанса как пользователь raas командой «exit». Теперь нам нужно запустить сервис RaaS:

sudo systemctl enable raas

sudo systemctl start raas

и переходить к апгрейду мастеров с Master Plugin. Для этого останавливаем сервис salt-master:

sudo systemctl stop salt-master

Проверяем версию Python (если 3.6 или выше – просто продолжаем дальше, если старше – удаляем предыдущую версию модуля SSEAPE на RHEL/CentOS:

sudo rm -rf /usr/lib/python3.6/site-packages/SSEAPE*

а на Ubuntu:

sudo rm /usr/lib/python3.6/dist-packages/SSEAPE*

командой).

Обновляем Master Plugin, вручную проинсталлировав проапдейченный механизм Python на RHEL/CentOS:

sudo pip3 install SSEAPE-file-name.whl –prefix /usr

а на Ubuntu:

sudo pip3 install SSEAPE-file-name.whl

Обновляем пути модуля API (RaaS), отредактировав файл «/etc/salt/master.d/eAPIMasterPaths.conf» в соответствии с путями к разным модулям (к примеру, может понадобиться поменять все соответствия «python2.7» на «python3.6»). Теперь секция «engines» в «/etc/salt/master.d/raas.conf» должна выглядеть так:

engines:

– sseapi: {}

– eventqueue: {}

– rpcqueue: {}

– jobcompletion: {}

И запускаем сервис salt-master:

sudo systemctl start salt-master.

Вот, собственно, и все, о чем хотелось сегодня рассказать, знакомясь с SaltStack Config 8.3. Если при реализации описанных выше рекомендаций возникли какие-то проблемы, контактируйте с саппортом продукта или же ищете решения в интернете в материалах по глубокому траблшутингу. Аналогичный совет пригодится, если захочется глубже погрузиться в функционал и возможности этого продукта.