Katello и Foreman в процессе patch management
Введение
Это публикация о некоторых функциях системы Katello и Foreman, касающихся процесса Patch Management.
Katello — это модульная часть системы Foreman, управляющая сторонними или локальными репозиториями pip, rpm, deb пакетов, podman, docker образов. Katello предоставляет возможность использовать абстракцию Lifecycle Environment: назначать целевым хостам доступность определенных состояний репозиториев (фиксированные версии пакетов или теги контейнеров).
В статье рассмотрена функциональность Foreman и Katello:
Lifecycle Environment.
Filter по пакетам, использование Tracer.
Репозиторий Podman и Filter по тегам.
Audit.
Возможности Foreman и Katello описаны с точки зрения пользователя платформы. Техническая реализация демо стенда рассматриваться не будет.
Это вторая статья из цикла, посвященного платформе Foreman. Предыдущая публикация находится тут.
Компоненты стенда:
Используем операционную систему Centos Stream 8, Foreman 3.9, Katello 4.11.
Lifecycle Environment
Ландшафт инфраструктуры может сильно меняться в зависимости от назначения систем, но везде присутствует логическое деление серверов по выполняемым ими функциям. Например, какая-то часть может использоваться для обработки внутренних данных системы, для пользовательских данных, в качестве тестовые окружений и т.д. В качестве серверов могут выступать как виртуальные машины, так и физические сервера. Часто процесс обслуживания инфраструктурного парка становится трудоемким, особенно при выполнении задачи Patch management.
Foreman и его плагин Katello предназначены для облегчения этого процесса.
Сейчас рассмотрим одну из самых полезных абстракций плагина Katello — Lifecycle Ennvironments.
Для того, чтобы разобраться с Lifecycle Environments, необходимо ознакомиться с ее составной частью — Content View (CV).
Это фиксированное состояние пакетов, docker образов и другого содержимого какого-либо репозитория (в дальнейшем будем называть это «контент»).
Основные этапы работы с Content View:
Запрос всех версий контента из доступных репозиториев
Фиксация версий контента и релиз новой версии Content View
Проверка состояния Content View на тестовой среде с последующей доставкой контента в более критичные среды
Content View могут быть объединены в Composite Content View для наследования контента.
Вернемся к Lifecycle Environments. Lifecycle Environments нужна для возможности продвижения конкретных версий Content View из одной среды к другой. В качестве простой схемы можно привести следующее: Dev → QA → Prod. Набор и порядок платформ настраиваются пользователем.
Далее рассмотрим использование Content View и Lifecycle Environment подробнее на примере нашего демо стенда.
Вводные данные: сервер centos8.example.com находится в организации «Example of an organization» в среде Dev environment.
Задача:
Требуется провести Patch management для сервера, обрабатывающего критичные данные. Перед этим нам бы хотелось протестировать этот процесс на тестовом сервере, выявить ошибки, проверить надежность, безопасность самого процесса обновления.
Используется заранее настроенный Foreman с установленным плагином Katello, созданными организациями, средами и добавленными репозиториями.
Для публикации новой версии доступных пакетов в репозиториях и продвижения их к проверочной среде Dev environment выполним следующие шаги:
Шаг 1. Проверим что публичные репозитории добавлены в наш инстанс Katello и синхронизированы.
Шаг 2. Создадим новую версию состояния репозиториев.
Шаг 3. Продвигаем новую версию состояния репозиториев в среду Dev environment.
Шаг 4. Убеждаемся, что сервер в среде Dev environment может получить последние версии пакетов
И проверяем доступные репозитории для хоста.
Шаг 5. Проверим установленную версию пакета bash и убедимся, что для него доступно обновление.
В результате среда подготовлена за 5 шагов: мы вручную выполнили синхронизацию с внешними репозиториями, опубликовали новое состояние пакетов и готовы к проведению процесса Patch management.
В случае успешного обновления нашего тестового сервера в среде Dev можно продвинуть состояние репозиториев к следующим средам: Test, Prod. В случае неуспеха можно вернуться к предыдущему состоянию репозиториев, выбрав стабильную версию и назначив ей среду (как это было сделано во втором шаге).
Важно заметить, что речь идет об откате версии пакета в репозитории, а не на конкретном сервере.
Filter по пакетам, использование Tracer.
Гибкий функционал Katello дает возможность управлять доступными версиями пакетов с помощью правил (Filter), получать данные о необходимости рестарта компонентов ОС после их обновления (Tracer).
Перейдем к практическому примеру.
Задача:
Необходимо обновить все пакеты за исключением Bash и получить информацию о том, какие компоненты будут требовать перезагрузки после выполненных работ.
Решение:
Шаг 1. В абстракции Content view cоздаем фильтр для rpm пакетов, назовем его example_filter.
Шаг 2. Добавим в фильтр правило для пакета bash.
Опубликуем новое состояние view.
Шаг 3. Во вкладке «Content» проверим доступные версии пакета bash. На скриншоте видно, что доступных версий для обновления нет.
Подробности пакета bash.
Шаг 4. Запускаем джоб обновления пакетов на целевом хосте с использованием плагина Remote Execution.
Отдельно отметим, что для автоматизации подобных действий можно использовать API. Приведем пример скрипта на Python для запуска задания обновления всех пакетов.
import requests
import json
import urllib3
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)
auth1 = {'user': 'admin', 'pass': 'notpassword'}
api_url = 'https://foreman.example.com/api/job_invocations/'
json = {
"job_invocation": {
"inputs": {
"package": ""
},
"job_template_id": 184,
"targeting_type": "static_query",
"search_query": "name ^ (centos8.example.com)"
}
}
api_respone = requests.post(
api_url,
auth=(auth1['user'], auth1['pass']),
json=json,
verify=False
)
print(api_respone.json())
job_template_id = 184 — это внутренний идентификатор шаблона задания в вашем инстансе, этот id может отличаться в каждой инсталляции платформы.
Шаг 5. Дожидаемся завершения задачи обновления.
Шаг 6. При помощи Tracer получаем информацию о компонентах, требующих перезагрузки сервера. В данном случае был обновлен systemd, и отображается сообщение о необходимости рестарта сервера.
Tracer — это python модуль который собирает с хостов список служб и приложений, которые после обновления требуют перезапуска.
Также список компонентов, требующих рестарта, можно получить с использованием SQL запрос в базу данных Foreman:
SELECT hosts.id, name, application, helper, last_compile
FROM katello_host_tracers
JOIN public.hosts ON katello_host_tracers.host_id=hosts.id
WHERE helper like '%You will have to reboot your computer%'
Также можно проверить, что версия пакета Bash не изменилась после обновления.
SELECT h.name, nvra
FROM katello_host_installed_packages k
JOIN public.hosts h ON k.host_id=h.id
JOIN public.katello_installed_packages kp ON k.installed_package_id=kp.id
WHERE h.name like '%centos8.example.com%' and nvra like '%bash%'
Как уже говорилось выше, Katello собирает данные обо всех установленных пакетах в ОС. С этими данными можно взаимодействовать как внутри Katello, так и применяя любой инструмент визуализации, используя в качестве источника данных БД Foreman.
В этом разделе было настроено ограничение версии пакета Bash с использованием Package Filter, обновлены пакеты ОС на сервере с использованием плагина Remote Execution и получена информация о компонентах, требующих рестарта, при помощи Tracer.
Репозиторий Podman и Filter по тегам.
Рассмотрим один из способов управления доступными версиями образов и состояниями репозиториев образов.
Katello не может быть использован в качестве локального репозитория образов: он выполняет функцию прокси репозитория с возможностью создания фильтров по тегам и разграничением контента по средам .
Задача:
Необходимо ограничить доступность образа foreman/custom-image по тегу latest для среды Dev environment.
Для ознакомления с функциональностью и решения нашей задачи выполним следующие шаги:
Шаг 1. Проверим корректность настройки репозитория custom-image с podman registry.
Шаг 2. Синхронизируем репозиторий и проверим доступность контейнеров, тегов.
Шаг 3. Проверим доступные версии образа foreman/custom-image. Напомню, что Content View хранит версии состояний репозитория и предоставляет их для среды Dev environment.
Шаг 4. Создадим Filter для исключения тега latest аналогично пакету bash в предыдущем разделе статьи.
Шаг 5. Добавим правило для фильтрации по тегу latest.
Опубликуем новое состояние репозитория для среды Dev environment.
Шаг 6. На целевом хосте проверим, что мы действительно не имеем доступ к отфильтрованному ранее образу с тегом latest
В этом пункте мы рассмотрели использование репозитория образов и создали фильтр для тега. При помощи Composite Content View можно комбинировать Content View репозитория образов с Content View, содержащим слепок репозитория пакетов, что может быть удобным в некоторых сценариях использования.
Audit.
Foreman имеет возможность гибкого управления правами доступа.
В рамках статьи не были настроены системы авторизации, был использован пользователь по умолчанию. При необходимости есть возможность настройки ограничений для учетных записей с использованием групп, организаций, локаций.
Сейчас мы рассмотрим функции аудита компонентов и абстракций внутри Foreman/Katello.
Пользователь по умолчанию — это admin.
Foreman отслеживает вызовы API, нажатие кнопок и других действий, результат аудита хранится в журнале. Рассмотрим, как могут выглядеть сообщения этого журнала на примере базовых действий.
Пример аудита действий с репозиторием.
Синхронизируем репозиторий и переходим во вкладку Audits.
Внутри отображаются выполненные действия, а также дополнительные детали, такие как обновление счетчиков взаимодействия с контентом и сообщения о синхронизации репозитория.
Все данные аудита можно получить напрямую из БД:
select * from audits a
where "action" = 'update'
order by id DESCq
Также можно использовать поиск по журналам аудита c использованием атрибутов разных абстракций, таких как имя сервера или название организации.
Рассмотрим поиск по выражению «podman_organization».
В результате отображаются сообщения о создании репозитория для этой организации.
Произведем поиск по названию сервера «centos8.example.com» и получим сведения о нашем тестовом хосте.
С увеличением инстанса Foreman/Katello растет необходимость в аудите действий с абстракциями. Аудит необходим для обеспечения прозрачности, контроля и безопасности в управлении организациями, локациями, серверами, группами, Foreman Proxy и правами пользователей.
Заключение
Платформа Foreman с плагином Katello представляет собой эффективный инструмент для управления обновлениями программного обеспечения. Эта комбинация обеспечивает возможность оперативного устранения уязвимостей и обновления контента, что способствует оптимизации времени обслуживания серверов. Кроме того, она облегчает создание отчетности и ведение аудита в процессе Patch management.
Благодарим, что вы дочитали до этого пункта. Эта публикация — попытка передать пользовательский опыт. Мы кратко коснулись функционала, который связан с процессом Patch Management, стараясь не перегружать текст техническими подробностями.
Контакты:
Почтовый адрес george.article.feedback@gmail.com
Авторы публикации:
Минашвили Георгий, Воля Яна, Бочаров Михаил.
