KernelCare ePortal для крупных хостинг-инфраструктур

Внедрение KernelCare ePortal в работу автопарка

KernelCare ePortal представляет собой самостоятельно управляемый компонент управления и распределения для агентов KernelCare в крупных средах Linux. Он объединяет наборы патчей, каналы обновлений и регистрационные ключи в одном контролируемом месте. Таким образом, оператор не только решает, получать ли хостам исправления, но и определяет, из какого локального источника и в соответствии с какой логикой утверждения это происходит.

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

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

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

Разграничение понятий «Live-Patching», «KernelCare» и «LibCare»

На сайте Живое исправление Агент KernelCare регулярно проверяет наличие подходящих наборов исправлений. Он загружает их, проверяет и устанавливает в работающее ядро. Благодаря этому исправления безопасности могут вступать в силу без необходимости перезапуска ядра. То, какие наборы исправлений применимы, зависит от установленного ядра и поддерживаемого дистрибутива.

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

Прежнее название KernelCare Plus должно встречаться только при классификации старой документации. С марта 2023 года производитель прекратил поддержку этого продукта и заменил его на KernelCare. Поэтому при проведении инвентаризации важно не отождествлять установленные агенты, договоры и документацию на основе исторических названий продуктов с текущими компонентами или функциональными возможностями.

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

Когда централизованное управление исправлениями оправдывает себя с экономической точки зрения

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

Дополнительная выгода должна оправдывать затраты. Экземпляр ePortal требует ресурсов, обновлений, резервного копирования, защиты доступа и мониторинга; при обеспечении высокой доступности к этому добавляются репликация и сетевая архитектура. Поэтому для небольшого числа однотипных серверов с разрешённым доступом в Интернет прямой доступ через инфраструктуру TuxCare зачастую оказывается проще. Меньшее количество компонентов означает меньшую собственную площадь для размещения оборудования.

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

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

Поэтому при принятии решения об эксплуатации нельзя однозначно утверждать, что „централизованный подход лучше“. ePortal целесообразен в тех случаях, когда локальный контроль, многоуровневое распределение и надежная отслеживаемость отвечают конкретным требованиям. Если таких требований нет, то намеренно упрощенный прямой доступ может оказаться более надежным. На следующем этапе выбранная модель предоставления определяет потребности в хранении данных и внешние зависимости.

Правильный выбор зеркалирования и кэша

Выбор модели распространения определяет, насколько независим парк хостинговых серверов при получении патчей и какой объем инфраструктуры ему необходимо поддерживать для этой цели. При прямом получении агенты KernelCare загружают наборы патчей через инфраструктуру TuxCare. ePortal, напротив, переносит процессы выпуска, локального хранения и распределения в отдельный экземпляр; он может зеркалировать наборы патчей в виде полного или отфильтрованного архива либо временно хранить их по мере необходимости.

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

Der Режим кэширования экономит место в памяти, но не является синонимом полностью изолированной работы. ePortal загружает метаданные и при необходимости получает двоичные данные патчей из источника; согласно документации, загруженные двоичные данные хранятся в локальном кэше в течение двух недель. Для изолированных сетей агентов этого может быть достаточно, при условии что ePortal может использовать разрешённый путь вверх по потоку.

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

Планирование хранилища не должно ограничиваться только размером текущего архива. Компания TuxCare в качестве ориентира для ePortal указывает SSD-накопители с производительностью не менее 100 IOPS, а также рост объёма данных примерно на 4–5 GiB в месяц. Эти данные производителя не заменяют планирование емкости: цели восстановления, параллельные развертывания, сетевые задержки, количество вариантов ядра и требования к мониторингу могут оказывать на архитектуру более сильное влияние, чем свободная емкость дисков.

Создание патч-колец для парков хостинга

Кольца развертывания позволяют организовать контролируемое внедрение на основе набора патчей, доступного на центральном сервере. Сначала разрешение получает небольшая тестовая группа («Canary»), затем следует промежуточная стадия развертывания, после чего — ограниченная производственная группа и, наконец, широкое производственное внедрение. Каждое кольцо требует заранее определённых показателей мониторинга и ответственного подразделения; без этих критериев задержка лишь переносит риск, а не позволяет его оценить.

Для производственных циклов Стабильный предназначенный канал. Канал Testing подходит для отдельного, тщательно контролируемого процесса оценки, поскольку он включает все доступные наборы патчей и, следовательно, может содержать дополнительные наборы патчей, которые ещё не помечены как «Stable». Согласно документации, канал Unstable является каналом раннего доступа и не рекомендуется к использованию. Поэтому каналы «Testing» и «Unstable» не следует рассматривать в качестве общего доказательства работоспособности в производственной среде.

Группы должны формироваться на основе технического сходства, а не только по месту расположения центра обработки данных. Важными факторами являются дистрибутив и серия ядра, аппаратная платформа, виртуализация, панель управления, стек веб-серверов и профиль клиента. Хост-сервер типа «Canary» с другой серией ядра или другой виртуализацией может лишь в ограниченной степени отражать поведение целевой системы в производственной среде. В случае виртуального хостинга следует учитывать профили ресурсов и конфигурации Менеджеры CloudLinux LVE в данную оценку, поскольку они могут влиять на характеристики нагрузки и характеры неисправностей.

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

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

Разделение фидов, ключей и клиентов

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

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

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

Начиная с версии ePortal 2.14-1, ключи API для публичного API можно использовать в качестве альтернативы базовой аутентификации. Система администрирования ePortal позволяет, в частности, назначать API-ключи, которые можно отозвать по отдельности, а также устанавливать опциональную дату истечения срока действия. Это упрощает настройку отдельных прав доступа для подключений к CMDB или автоматизации конфигурации, при условии, что права соответствующей учетной записи пользователя сознательно ограничены.

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

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

Обеспечение отказоустойчивости репликации и TLS

Для распространение патчей с высокой доступностью несколько узлов ePortal объединяются таким образом, что агенты KernelCare обращаются к общему имени DNS кластера или к HTTP-балансировщику нагрузки. Для выполнения административных задач, напротив, используется контролируемая конечная точка администрирования, специфичная для каждого узла. Согласно рекомендациям производителя, общую конечную точку кластера нельзя использовать для операций в интерфейсе администрирования ePortal.

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

Узлы синхронизируют изменения посредством репликации. Эта синхронизация не всегда отображается сразу. В частности, при использовании алгоритма «Round-Robin» только что зарегистрированный агент может сначала обратиться к первому узлу для регистрации, а сразу после этого — к еще не синхронизированному узлу для обновления. Поэтому в автоматизированных процессах следует предусматривать кратковременную паузу или алгоритм повторных попыток с ограниченным количеством повторений, а не рассматривать немедленный вызов патча как надёжное конечное состояние.

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

Репликация осуществляется по протоколу HTTP. Поэтому без надлежащего защиты с помощью TLS данные репликации передаются в незашифрованном виде. Необходимо сегментировать этот трафик как минимум на доверенную сеть или настроить TLS в соответствии с архитектурой. Для конечных точек агентов, доступных извне или через несколько сетей, проверяемая цепочка сертификатов является важным компонентом Терминация TLS; отключение проверки сертификатов не является приемлемым долгосрочным решением.

Если перед ePortal установлен обратный прокси-сервер, необходимо настроить разрешённые имена хостов, чтобы ePortal ограничивал запросы на заголовок хоста. Кроме того, прокси-сервер должен корректно передавать исходный заголовок хоста, а также поле X-Forwarded-Proto. В противном случае могут возникнуть неверные внешние URL-адреса, проблемы с перенаправлением или неверная оценка используемого протокола. Поэтому настройка этих заголовков должна быть частью каждого изменения прокси-сервера и его приёма в эксплуатацию.

Наладить ведение документации, резервное копирование и мониторинг

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

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

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

kc.eportal replication --short-status

ePortal различает архивирование данных и простое резервное копирование базы данных. Полный синтаксис команды выглядит следующим образом: kc.eportal backup <path_to_archive>; она создает архив резервной копии, включая файлы наборов исправлений. С помощью kc.eportal backup-db <path_to_backup> В этом случае вы создаете резервные копии только баз данных без файлов наборов исправлений. Этот второй способ подходит для данных конфигурации и сервера, но не для локального архивирования исправлений.

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

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

Оценка симптомов неисправностей и принятие решений по эксплуатации

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

Исторические указания производителя, касающиеся старых версий компонентов, не следует рассматривать как постоянные требования к версиям. Указание от декабря 2025 года касалось, в частности, KernelCare-Agent 3.x и ePortal 2.20 в контексте нового формата подписанных патчей. Поэтому перед обновлением проверь актуальную Матрица совместимости, фактически установленные версии и утвержденный внутри компании порядок обновлений.

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

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

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

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