Единый образ контейнера, который обеспечивает управление уязвимостями и аудит политик для каждого узла Kubernetes, как на неизменяемых (immutable), так и на изменяемых (mutable) ОС Linux, развертываемый привычным для ваших контейнерных рабочих нагрузок способом.
Основные выводы
- Облачный агент Qualys Cloud Agent теперь доступен в виде образа контейнера на Docker Hub, обеспечивая хостовое управление уязвимостями и аудит политик для каждого узла Kubernetes без вмешательства в менеджер пакетов хоста.
- Он работает как Kubernetes DaemonSet, поэтому каждый узел, присоединяющийся к кластеру, автоматически получает агента. Его можно развертывать и обновлять с помощью манифестов YAML или единого чарта Helm, который также развертывает датчики безопасности контейнеров Qualys для обеспечения полной стековой безопасности за одну установку.
- Единый образ поддерживает операционные системы, оптимизированные для контейнеров, такие как AWS Bottlerocket, Google Container-Optimized OS и Red Hat CoreOS, а также Linux на базе RPM и Debian, включая Azure Linux, как для архитектуры Intel/x64, так и для ARM.
- Аудит политик включает в себя сертифицированные CIS политики для AWS Bottlerocket и Google Container-Optimized OS, а все выявленные проблемы ранжируются с помощью Qualys TruRisk наряду с остальной частью вашей инфраструктуры.
- В сочетании с Qualys TotalCloud Kubernetes and Container Security (KCS) он обеспечивает полную защиту стека на уровне ОС хоста, работающих контейнеров и плоскости управления Kubernetes.
Эпоха ИИ — это эпоха контейнеров
Эпоха ИИ наступает не на «голом» железе. Она приходит на Kubernetes. Конвейеры обучения моделей, службы инференса, векторные базы данных и агентные рабочие нагрузки, которые ими управляют, создаются в виде контейнеров и планируются в кластерах, масштабирующихся вверх и вниз каждую минуту. Единицей вычислений больше не является сервер. Это контейнер и узел, на котором он в данный момент запущен.
Этот сдвиг меняет подход для команд безопасности. Поверхность атаки больше не представляет собой парк серверов, которые можно пересчитать и пропатчить в рамках ежемесячного цикла. Это парк узлов, которые могут существовать в течение нескольких часов, загружаться в операционные системы, не позволяющие устанавливать пакеты, и размещать рабочие нагрузки, перемещающиеся между ними без предупреждения. Каждый из этих узлов является хостом, и каждая операционная система хоста несет свои собственные уязвимости и риски конфигурации, независимо от того, что запущено в контейнерах поверх нее.
Qualys TotalCloud Kubernetes and Container Security (KCS) расширяет возможности покрытия от сборки до среды выполнения для образов, контейнеров и бессерверных рабочих нагрузок.
Проблема: безопасность хостов не была рассчитана на контейнерные платформы
Годами обеспечение безопасности хоста означало одно: установить на него RPM или DEB. Эта модель работала, когда хосты были долговечными и однородными. В контейнерных платформах она дает сбой по двум причинам.
- Операционные системы, оптимизированные для контейнеров, не принимают пакеты. AWS Bottlerocket, Google Container-Optimized OS (COS), Red Hat CoreOS и им подобные намеренно блокируют корневую файловую систему и удаляют менеджер пакетов. Установить что-либо через yum не получится. Средства безопасности должны работать так же, как и все остальное на этих узлах: в виде контейнера.
- Развертывание на основе пакетов не подходит для оркестрируемых сред. Команды Kubernetes управляют всем с помощью манифестов, чартов Helm и конвейеров GitOps. Агент безопасности, который приходится устанавливать вне общего процесса, узел за узлом, — это единственное в кластере, что не декларируется, не версионируется и не согласовывается подобно всему остальному. Он также не успевает за изменениями: пул узлов, который масштабируется с десяти узлов до двухсот во время выполнения задач обучения, нуждается в защите на каждом созданном узле в автоматическом режиме.
Результатом является пробел в защите на базовом уровне. Команды инвестируют средства в сканирование образов контейнеров и мониторинг работающих контейнеров, и это правильно. Но среда выполнения контейнеров, kubelet, ядро и каждая системная библиотека находятся в ОС хоста. Если этот слой не контролируется, чистый образ, запущенный на уязвимом узле, по-прежнему представляет собой уязвимую рабочую нагрузку.
Решение: Облачный агент Qualys Cloud Agent в виде образа контейнера
Облачный агент Qualys Cloud Agent теперь доступен в виде образа контейнера, опубликованного непосредственно на Docker Hub под проверенной учетной записью издателя Qualys. Он работает на каждом узле вашего кластера как DaemonSet и обеспечивает те же функции управления уязвимостями и аудита политик на основе хоста, которые Qualys Cloud Agent предоставляет на любой другой платформе, без вмешательства в менеджер пакетов хоста.
Образ поставляется с предварительно установленным агентом Qualys Cloud Agent и динамически загружает необходимые во время выполнения компоненты, такие как манифесты приложений и вспомогательные утилиты, поэтому он остается легковесным и при этом полностью функциональным. Поскольку развертывание осуществляется через Kubernetes, оркестратор выполняет работу, которую раньше выполняли ваши сценарии подготовки: каждый узел, присоединяющийся к кластеру, получает агента, а каждый узел, покидающий его, забирает своего агента с собой.
- Образ Intel/x64: qualys/cloud-agent-container-x64
- Образ ARM: qualys/cloud-agent-container-arm
После скачивания образа вы можете загрузить манифесты YAML для развертывания, а чарт Qualys Helm chart опубликован на Artifact Hub, что позволяет устанавливать, версионировать и обновлять агента через тот же рабочий процесс Helm, что и остальную часть вашего кластера.
Почему это важно: преимущества
В сочетании с TotalCloud KCS контейнеризированный облачный агент обеспечивает полную защиту стека на уровне ОС хоста, работающих контейнеров и плоскости управления Kubernetes в отношении уязвимостей, аудита и состояния безопасности, а также безопасности среды выполнения, дрейфа конфигураций и обнаружения угроз.
Полная защита хостов для контейнеризированных и неизменяемых (immutable) операционных систем
Неизменяемые операционные системы — правильный выбор для контейнерных платформ: меньшая поверхность атаки, атомарные обновления и корневая файловая система, которая не подвержена дрейфу конфигураций. Но неизменяемость имеет и обратную сторону. Если вы ничего не можете установить, вы не можете установить традиционный агент, и многие команды работали с такими узлами вслепую. Контейнеризированный облачный агент устраняет этот пробел. Он работает как привилегированный контейнер с необходимыми монтированиями хоста для оценки базовой ОС, благодаря чему узлы Bottlerocket, COS и CoreOS получают те же возможности видимости уязвимостей и соответствия требованиям, что и обычный сервер Red Hat Enterprise Linux (RHEL), без каких-либо изменений в образе хоста и без ущерба для неизменяемости, из-за которой вы изначально выбрали эту ОС.
Qualys уже много лет выстраивает такую защиту на основных облачных платформах:
- Обеспечение безопасности Red Hat CoreOS в OpenShift
- Сканирование AWS Bottlerocket в Amazon EKS и Amazon ECS
- Сканирование Container-Optimized OS в Google Kubernetes Engine
- Qualys для Microsoft Azure Linux в AKS и Azure Container Instances
Возможность выбора агента и для изменяемой (mutable) ОС Linux
Контейнеризированный агент Cloud Agent не ограничивается неизменяемыми операционными системами. Он также работает в дистрибутивах на базе RPM и Debian, которые составляют основу большинства самоуправляемых и облачных узлов Kubernetes сегодня. Это существенное изменение. Раньше узел RHEL или Ubuntu означал обязательную установку RPM- или DEB-пакета, и точка. Теперь у вас есть выбор. Команды, использующие комбинацию виртуальных машин (ВМ) и контейнеров, могут сохранить пакет на ВМ и использовать контейнеризированный Cloud Agent на узлах кластера. Команды, полностью перешедшие на Kubernetes, могут везде стандартизировать использование контейнеризированного Cloud Agent и больше никогда не управлять пакетами для хостов. В любом случае данные попадают в одно и то же место, с теми же методами обнаружения и оценкой TruRisk.
Развертывание, соответствующее вашим принципам работы с Kubernetes
Контейнеризированный Cloud Agent представляет собой DaemonSet, что означает гарантированное оркестратором наличие одного агента на узел, на каждом узле в течение всего жизненного цикла кластера. Автомасштабирование пулов узлов, спотовые инстансы, которые могут быть отозваны, и обновления кластера, заменяющие каждый узел, выполняются без тикетов, скриптов или участия человека. Покрытие становится свойством кластера, а не задачей, о которой кто-то должен помнить.
Поскольку агент поставляется в виде чарта Helm и манифестов YAML, он находится в том же репозитории GitOps, что и ваши рабочие нагрузки. Обновление представляет собой изменение тега и запрос на слияние (pull request). Откат изменений выполняется через операцию revert. Селекторы узлов и правила толерантности (tolerations) позволяют нацеливаться на определенные пулы, а один и тот же манифест работает в средах разработки, тестирования и производства. Безопасность перестает быть исключением из вашей модели развертывания.
Один образ для любой операционной системы
Вам больше не нужны сборки для Bottlerocket, CoreOS и Ubuntu. Единый образ контейнеризированного Cloud Agent работает во всех поддерживаемых операционных системах. Это сокращает вашу матрицу развертывания: один образ для проверки в рамках средств контроля цепочки поставок, один образ для закрепления версии, один манифест DaemonSet для поддержки. При выходе нового релиза агента достаточно обновить один тег во всей инфраструктуре. Образы, соответствующие федеральным стандартам обработки информации (FIPS), доступны для сред, где это требуется.
Полное покрытие для Intel и ARM
Пулы узлов кластера все чаще объединяют инстансы x86 и ARM, причем Graviton, Cobalt и Axion используются наряду с традиционными узлами Intel и AMD. Образы публикуются как для Intel/x64, так и для ARM, поэтому многоархитектурный кластер получает стабильное покрытие без необходимости настраивать исключения для каждого пула.
Полностековое покрытие с первого взгляда
Контейнеризированный Cloud Agent запускает полноценный Qualys Cloud Agent на каждом узле, оценивая ОС хоста на наличие уязвимостей по базе знаний Qualys KnowledgeBase и на соответствие контрольным показателям Центра безопасности интернета (CIS) с помощью аудита политик Qualys Policy Audit. Вот как распределяется покрытие по стеку:
Результаты как управления уязвимостями (Vulnerability Management), так и аудита политик (Policy Audit) поступают в те же представления, дашборды и рабочие процессы Enterprise TruRisk Platform, которые ваши команды уже используют. Узел Kubernetes — это просто еще один актив с оценкой Qualys TruRisk, находящийся рядом с виртуальной машиной, ноутбуком и облачной учетной записью и обрабатываемый в рамках единого приоритета.
Начало работы
- Получите образ из Docker Hub: или .
- Загрузите YAML-файлы развертывания или используйте Qualys Helm chart.
- Разверните в кластере в качестве DaemonSet с вашим ключом активации агента, следуя руководству по началу работы Intel или ARM.
Руководства для конкретных платформ доступны для AWS Bottlerocket, Google COS и Red Hat CoreOS.
Новинки в Cloud Agent 2.9.0
Сегодня образы доступны в Docker Hub. Начиная с релиза Cloud Agent 2.9.0 вы сможете загружать пакет контейнеризированного Cloud Agent напрямую с платформы Qualys наряду с любыми другими инсталляторами Cloud Agent. Вкладки общих контейнеров появятся в рабочем процессе загрузки и установки Cloud Agent вместе с вашим ключом активации, списком поддерживаемых ОС и инструкциями по установке.
Хост — это лишь половина дела: защита всего контейнерного стека с помощью TotalCloud
Контейнеризированный Cloud Agent защищает уровень под вашими рабочими нагрузками. Он не заглядывает внутрь запущенных поверх контейнеров и не предназначен для этого. Эта задача принадлежит Qualys TotalCloud, и оба решения разработаны как взаимодополняющие половины единого ответа на вопрос, который рано или поздно задает себе любая команда платформы: насколько защищены наши контейнерные рабочие нагрузки от начала и до конца?
Риски контейнеров не сосредоточены на каком-то одном уровне. Они охватывают облачную учетную запись, в которой работает кластер, операционные системы узлов, плоскость управления Kubernetes и ее конфигурацию, образы в ваших реестрах, контейнеры, работающие в производственной среде, а также удостоверения и сетевые пути, которые все это связывают. Защита любого из этих уровней изолированно оставляет вас с неполным представлением и ложным чувством безопасности. Решение TotalCloud создано для того, чтобы защищать их все на единой платформе с единой оценкой рисков.
Безопасность контейнеров: от реестра до среды выполнения
Датчик безопасности контейнеров TotalCloud подхватывает работу там, где ее останавливает агент хоста. Развертываемый в виде легковесного контейнера вместе с вашими рабочими нагрузками, он обнаруживает и инвентаризирует каждый образ, контейнер и кластер в вашей среде, выполняя их оценку на каждом этапе жизненного цикла:
- Сборка и реестр: образы сканируются на предмет уязвимостей ОС и уровня приложений, а также встроенных секретов по мере их попадания в реестры или прохождения через конвейеры CI/CD (непрерывной интеграции и непрерывной доставки), поэтому критическая уязвимость (CVE) в базовом слое обнаруживается до развертывания, а политики допуска могут полностью заблокировать ее планирование.
- Работающие контейнеры: контейнеры в продакшене непрерывно оцениваются по той же базе знаний (KnowledgeBase) с обнаружением отклонений (drift detection), что позволяет выявлять контейнеры, которые больше не соответствуют образу, из которого они были запущены.
- Безопасность конфигураций Kubernetes: кластеры, пространства имен, рабочие нагрузки и ролевой контроль доступа (RBAC) оцениваются на соответствие стандартам CIS Kubernetes Benchmarks и передовым практикам для выявления подов с избыточными привилегиями, незащищенных дашбордов, отсутствующих сетевых политик и других неправильных конфигураций плоскости управления.
- Защита в среде выполнения: поведенческий мониторинг работающих контейнеров обнаруживает и блокирует вредоносную активность, такую как неожиданное выполнение процессов, подделка файлов и аномальные сетевые подключения, поэтому эксплойт, пропущенный на более ранних этапах, будет пойман с поличным.
TotalCloud KCS также имеет сертификат сканера уязвимостей Red Hat (Red Hat Vulnerability Scanner Certification), что расширяет возможности обнаружения до Red Hat OpenShift, RHEL и CoreOS.
Хотите узнать, как TotalCloud защищает контейнеры от реестра до среды выполнения?
Облачная безопасность, идентификация и инфраструктура как код
Кластеры не работают в вакууме. Решение TotalCloud для управления безопасностью облачной среды (CSPM) непрерывно оценивает учетные записи AWS, Azure и Google Cloud, в которых развернуты ваши кластеры, охватывая неправильно настроенные хранилища, избыточные роли управления доступом и идентификацией (IAM), незащищенные службы и сотни других элементов контроля, сопоставленных с CIS и нормативными стандартами. Сканирование инфраструктуры как кода применяет те же проверки к манифестам Terraform, CloudFormation и Kubernetes в ваших репозиториях, благодаря чему ошибки конфигурации устраняются еще на этапе запроса на пулреквест, а не в рабочей среде. В совокупности они замыкают цикл защиты вокруг самого кластера.
Единая картина рисков с оценкой TruRisk
Платформой, а не просто набором инструментов, это решение делает то, что каждое обнаружение — от хост-агента, датчика контейнеров и оценки облачной среды — нормализуется, соотносится и оценивается с помощью TruRisk в едином месте. Это меняет возможности обзора. Уязвимое ядро на узле Bottlerocket, критическая уязвимость (CVE) в базовом образе, избыточно привилегированный под, запущенный на этом узле, и публичный входящий трафик перед ним больше не являются четырьмя оповещениями в четырех консолях. Это единый вектор атаки с единой оценкой риска и четким ответом на вопрос о том, что нужно исправить в первую очередь. Та же корреляция позволяет уверенно отсеивать ложные тревоги: критическая CVE в образе, который никогда не запускается, на узле без внешнего доступа оценивается соответствующим образом.
И поскольку все это работает на базе Enterprise TruRisk Platform, риски контейнеров сосуществуют с остальной частью вашей поверхности атаки. Узел Kubernetes, заменившая его виртуальная машина, ноутбук разработчика, передавший образ, и владеющая ими всеми облачная учетная запись управляются, приоритизируются и отслеживаются одинаково, теми же командами и с использованием тех же рабочих процессов.
Устраните разрыв между хостом и облаком
Чистый образ, запущенный на уязвимом узле, по-прежнему представляет собой уязвимую рабочую нагрузку. Загрузите контейнеризированный агент для облака из Docker Hub уже сегодня и обеспечьте для своих узлов Kubernetes такой же уровень охвата управлением уязвимостями и аудитом политик, как и для остальной части вашей инфраструктуры. Затем обратитесь к своему представителю Qualys, чтобы распространить этот охват с хоста на каждый образ, контейнер, кластер и учетную запись облака, от которых зависят ваши рабочие нагрузки.
Обеспечьте для своих узлов Kubernetes такой же уровень охвата управлением уязвимостями и аудитом политик, как и для остальной части вашей инфраструктуры.
