5 февраля 2024
Статья 2 KCS. Архитектура, лицензирование и обзор функциональных возможностей
Цикл "Kaspersky Container Security (KCS)"
Введение
Приветствуем читателей в статье, посвященной обзору решения по защите контейнерных сред – Kaspersky Container Security..
В первой части мы с вами познакомимся с теоретической составляющей: рассмотрим архитектуру, варианты лицензирования, функциональные возможности. Далее перейдем к практике, осуществляя установку и настройку продукта. Надеемся, что в этой статье вы найдете много полезной и интересной информации!
Решение Kaspersky Container Security учитывает особенности сред контейнеризации, обеспечивая защиту на этапах сборки, хранения, запуска и эксплуатации.
В первой части мы с вами познакомимся с теоретической составляющей: рассмотрим архитектуру, варианты лицензирования, функциональные возможности. Далее перейдем к практике, осуществляя установку и настройку продукта. Надеемся, что в этой статье вы найдете много полезной и интересной информации!
Решение Kaspersky Container Security учитывает особенности сред контейнеризации, обеспечивая защиту на этапах сборки, хранения, запуска и эксплуатации.
Архитектура решения
- Сервер KCS: предоставляет консоль управления, координирует работу других компонентов, обеспечивает интеграцию с SIEM-системами, реестрами образов и CI-инструментами;
- KCS Сканер: устанавливается в кластер с серверными компонентами оркестратора. Проверяет репозиторий на актуальность и безопасность образов, а на этапе сборки контейнера проверяет образ в рамках CI-процесса;
- KCS Агент устанавливается в кластер как обособленный контейнер. Осуществляет контроль запуска контейнеров из доверенных образов, а также проверку узлов кластера на соответствие политикам безопасности
При использовании закрытого контура необходимо дополнительно развернуть компонент «Сервер обновлений». Он обеспечивает обновление баз данных уязвимостей и угроз. Если развертывание решения проводилось в открытом контуре, базы обновляются через интернет.
Преимущества продукта
- Интеграция в процесс безопасной разработки. Решение встраивается в CI/CD- процессы в виде этапа pipeline;
- Продукт, удовлетворяющий требованиям регуляторов и закрывающий основные риски, характерные для контейнерных сред;
- Централизованный мониторинг и инвентаризация ресурсов компонентов контейнерой инфраструктуры. В дополнение к этому продукт предоставляет возможность выполнять мониторинг ресурсов кластеров K8s. Все это позволяет составить целостную картину происходящий в инфраструктуре процессов;
- Поддержка отечественного ПО. Решение внесено в реестр отечественного ПО. Продукт поддерживает сканирование образов на базе Astra Linux и RedOS
Лицензирование
На текущий момент продукт лицензируется двумя уровнями:
- Standard: базовая защита образов контейнеров, интеграция с CI/CD-платформами и SIEM-системами;
- Advanced: помимо защиты образов, включает в себя защиту контейнеров в рантайме, проверки на соответствие требованиям регуляторов, а также улучшенный мониторинг;
Практическая часть
В этой главе мы опишем по шагам и покажем установку Kaspersky Container Security, получим доступ к веб-интерфейсу и подгрузим лицензию, развернем KCS-агентов и проведем небольшой траблшутинг.
Требования:
Helm-чарт
При запросе пилотного проекта Лаборатория Касперского предоставляет URL Helm-репозитория и данные для авторизации: логин и пароль. Эти данные соответственно внесены в переменные CHART_URL, CHART_USERNAME и CHART_PASSWORD на нашей машине администратора. Выполним helm registry login:
helm registry login —username $CHART_USERNAME —password $CHART_PASSWORD $CHART_URL
Требования:
- Развернутый Kubernetes или OpenShift кластер(-ы)
- Наличие доступа до кластера с помощью kube-config файла
- Наличие Helm и kubectl на рабочей станции администратора
- Доступ в интернет для загрузки helm-чарта KCS и образов контейнеров решения
- Установленный Ingress Controller (на нашем стенде используем Nginx)
- Определенный StorageClass для динамического создания PV (в примере – local-path)
Helm-чарт
При запросе пилотного проекта Лаборатория Касперского предоставляет URL Helm-репозитория и данные для авторизации: логин и пароль. Эти данные соответственно внесены в переменные CHART_URL, CHART_USERNAME и CHART_PASSWORD на нашей машине администратора. Выполним helm registry login:
helm registry login —username $CHART_USERNAME —password $CHART_PASSWORD $CHART_URL
Теперь загрузим чарт на нашу машину админа:
helm pull oci://$CHART_URL/charts/kcs —version $CHART_VERSION (здесь CHART_VERSION=1.1.0 – версия чарта)
Скачиваем архив чарта, распакуем его и перейдем в папку kcs
helm pull oci://$CHART_URL/charts/kcs —version $CHART_VERSION (здесь CHART_VERSION=1.1.0 – версия чарта)
Скачиваем архив чарта, распакуем его и перейдем в папку kcs
В этой папке содержатся:
- Changelog: что поменялось в данной версии;
- Chart.yaml: метаданные по helm-чарту;
- Папка certs со скриптами для генерации сертификатов Ingress и шифрования трафика между компонентами KCS;
- Папка templates с шаблонами ресурсов KCS;
- Файл values. yaml: самый важный файл, в котором мы и будем задавать все параметры инсталляции
Для упрощения мы не будем шифровать ни Ingress, ни внутренний трафик KCS, поэтому генерирование сертификатов мы пропускаем
values.yaml и развертка подов KCS в целевом кластере
Перейдем в файл values. yaml и рассмотрим необходимые поля, которые необходимо указать, чтобы KCS успешно запустился
В поле default. domain указываем FQDN нашей веб-консоли решения, в нашем случае — kcs.lab.local
values.yaml и развертка подов KCS в целевом кластере
Перейдем в файл values. yaml и рассмотрим необходимые поля, которые необходимо указать, чтобы KCS успешно запустился
В поле default. domain указываем FQDN нашей веб-консоли решения, в нашем случае — kcs.lab.local
Блок default.storageClass указывает на SC, который KCS будет использовать по умолчанию для PostgreSQL и NATS, если для них они явно не указаны
default.serviceAcoount – название сервисного аккаунта KCS
default.serviceAcoount – название сервисного аккаунта KCS
Блок default.ingress задает базовые настройки Ingress-ресурса:
default.ingress.create – создавать (true) или нет (false) Ingress
default.ingress.class – класс установленного Ingress Controller
default.ingress.create – создавать (true) или нет (false) Ingress
default.ingress.class – класс установленного Ingress Controller
В блоке pullSecret.kcs-pullsecret нам необходимо указать логин, пароль, которые мы использовали для доступа к Helm-репозиторию, и (по желанию) адрес электронной почты. По умолчанию в файле указан адрес реестра ЛК для загрузки образов решения, если контур закрытый – указывайте ссылку на внутренний реестр
Указываем false для TLS_INTERNAL и TLS_INGRESS, чтобы отключить шифрование
В файле values. yaml есть еще много параметров, которые можно кастомизировать под свои нужды и инфраструктуру.
Мы их описывать не будем, чтобы не перегружать статью, вот лишь несколько примеров:
Сейчас же перейдем к установке KCS с помощью Helm. В папке kcs выполняем команду:
helm install kcs kcs/kcs —namespace kcs —create-namespace —values values. yaml
При успешной установке получаем следующий вывод
Мы их описывать не будем, чтобы не перегружать статью, вот лишь несколько примеров:
- Использование внешней СУБД PostgreSQL (по умолчанию KCS поставляется со встроенной pgsql);
- Шифрование Ingress и Internal трафика с возможностью подгрузки собственных сертификатов;
- Изменение системных требований к ресурсам (для тестовых стендов. Мы, как и Лаборатория Касперского, не рекомендуем менять системные ресурсы. Во всяком случае, устанавливать их ниже рекомендуемых)
Сейчас же перейдем к установке KCS с помощью Helm. В папке kcs выполняем команду:
helm install kcs kcs/kcs —namespace kcs —create-namespace —values values. yaml
При успешной установке получаем следующий вывод
Ждем 2-3 минуты, когда все поды запустятся. Проверим с помощью kubectl – если нет проблем, поды должны быть в статусе Running
PS: пара заметок по траблшутингу.
а) Если у вас kcs-ih в статусе Pending, то проверьте вывод kubectl describe pod kcs-ih-<RS-tag>-<Pod-tag>, самая частая причина – ни один узел не удовлетворяет CPU и/или Memory запросам;
б) Если же в статусе Pending под kcs-postgres, то проверьте корректность указанного StorageClass в values.yaml и доступность PV и PVC (они должны быть в статусе Bound)
а) Если у вас kcs-ih в статусе Pending, то проверьте вывод kubectl describe pod kcs-ih-<RS-tag>-<Pod-tag>, самая частая причина – ни один узел не удовлетворяет CPU и/или Memory запросам;
б) Если же в статусе Pending под kcs-postgres, то проверьте корректность указанного StorageClass в values.yaml и доступность PV и PVC (они должны быть в статусе Bound)
Получаем доступ к веб-консоли администратора и подгружаем лицензию
Если у вас нет в локальном DNS записи для FQDN веб-консоли, то можно для теста прописать соответствующую запись в файл hosts на локальной машине
Перейдем в браузере на http://kcs.lab.local, открывается страница аутентификации и EULA
Если у вас нет в локальном DNS записи для FQDN веб-консоли, то можно для теста прописать соответствующую запись в файл hosts на локальной машине
Перейдем в браузере на http://kcs.lab.local, открывается страница аутентификации и EULA
Принимаем соглашение и аутентифицируемся, стандартные логин и пароль - admin/admin
После чего нужно сменить пароль, все требования указаны в окне
Добро пожаловать в Kaspersky Container Security!
Перейдем во вкладку Licensing и нажмем кнопку «Add license key»
- Если контур открыт и у KCS есть доступ в интернет, то вводим код активации
- Если контур закрыт, то подгружаем файл c ключом
Применяем код активации:
Лицензия активирована. Здесь же можно посмотреть:
Перейдем в Components->Agents и кликнем на «Add Agent group»
- Кто и для кого выпустил лицензию
- Сколько дней осталось до истечения
- Количество активных нод и их лимит
- Количество просканированных уникальных образов и их лими
- Какая функциональность доступна для данной лицензии
Перейдем в Components->Agents и кликнем на «Add Agent group»
Здесь мы заполняем следующие поля:
- Group name: имя группы агентов;
- (опционально) Description: описание;
- Agent type: пока что доступен только один вариант «Kubernetes Agent»;
- OS type: также только один вариант «Linux»;
- Orchestrator: тип используемого оркестратора: Kubernetes или OpenShift;
- Registry URL, username и password: данные для доступа к репозиторию образов, предоставляются Лабораторией Касперского;
- Namespace: в какой NS устанавливаем агентов, у нас – kcs;
- Deployment token: либо оставляем поле пустым (тогда токен сгенерируется автоматически), либо указываем свой в plain-text формате без кодировки Base64
У нас сгенерируется yaml манифест для установки агентов в кластер. Скачиваем его и загружаем на машину администратора
Применяем манифест с помощью kubectl:
kubectl apply –f <agent-group-name>.yaml
kubectl apply –f <agent-group-name>.yaml
И дожидаемся, что поды kube-agent и node-agent-* перешли в статус Running
Спустя пару минут в веб-консоли KCS во вкладке Agents должны отобразиться наши агенты
Немного траблшутинга. Если прошло 15 минут, а агенты в консоли управления не появились, то идем смотреть логи. У нас FQDN kcs.lab.local не записан в локальном DNS (а тестовый поднимать – поленились:)), и агенты просто не знали, куда им отправлять heartbeat запросы
Как решать? Идем править ConfigMap coredns
kubectl edit configmap coredns –n kube-system
Прописываем в Corefile блок hosts и явно указываем адрес для нашего FQDN (в нашем случае – адрес внешнего балансировщика) и директиву fallthrough
kubectl edit configmap coredns –n kube-system
Прописываем в Corefile блок hosts и явно указываем адрес для нашего FQDN (в нашем случае – адрес внешнего балансировщика) и директиву fallthrough
Если нет опечаток, то kubectl выведет, что coredns исправлен
Теперь для heartbeat-ов код ответа 200
Краткое описание возможностей Kaspersky Container Security
В данной обзорной статье мы не будем углубляться в описание всех возможностей решения, а лишь укажем, за что отвечает каждый пункт в меню веб-консоли.
Inventory:
Components:
Compliance:
Policies:
Также возможно создавать пользователей и настраивать RBAC, доступна интеграция по LDAP и аудит событий KCS.
В данной обзорной статье мы не будем углубляться в описание всех возможностей решения, а лишь укажем, за что отвечает каждый пункт в меню веб-консоли.
Inventory:
- Assets — визуализация целевых кластеров и их ресурсов, описание неймспейсов и подов и найденные в них уязвимости. Здесь же показана база проверенных репозиториев;
- CI/CD — результаты сканирования CI/CD-пайплайнов
Components:
- Agents — группы агентов и их конфигурация, а также служебная информация (имя, статус, тип и так далее) каждого конкретного агента;
- Scanners — развернутые сканеры, их статус (free/busy) и задачи, которые выполняет/выполнил/планирует выполнить каждый сканер
Compliance:
- CIS Kubernetes benchmarks — проверка кластера на соответствие рекомендациям CIS
Policies:
- Scanner policy: что мы хотим сканировать и по каким базам сигнатур проверять. Здесь же можем указать кастомные чувствительные данные;
- Assurance policies: здесь мы описываем, какие образы мы считаем опасными и что нам с ними делать на этапе CI;
- Response policies: политика реагирования на определенный триггер (найдена critical уязвимость, образ помечен как non-compliant и прочее). Доступны интеграции с почтой и телеграм-ботом;
- Runtime policies: политики для ограничения прав для запущенных контейнеров и предотвращения запуска контейнеров из незарегистрированных и/или non-compliant образов. Можно создавать критерии для обхода политик;
- Risk acceptance: таблица образов, для которых мы приняли риски
Также возможно создавать пользователей и настраивать RBAC, доступна интеграция по LDAP и аудит событий KCS.
Итоги и планы
Kaspersky Container Security создавался как решение, которое не требует сложной настройки — для тестовой среды, не считая ввода данных для доступа к реестру, решение ставится «из коробки».
Для production среды предусмотрены возможности кастомизации, чтобы подогнать решение под развернутую инфраструктуру, а не инфраструктуру — под решение. Установка в кластер в виде подов позволяет не затрагивать выстроенные бизнес-процессы и не нарушать логику работающего приложения. А понятный интерфейс и выбор из множества настроек политик позволит усилить безопасность контейнерной инфраструктуры в дополнение к имеющимся средствам защиты конечных точек, NGFW, WAF и так далее.
На этом мы завершаем краткий обзор решения Kaspersky Container Security. Более подробно все аспекты решения мы рассмотрим в следующих материалах.
Авторы: Нестеренко Влада и Разумов Кирилл, Инженеры TS Solution
Kaspersky Container Security создавался как решение, которое не требует сложной настройки — для тестовой среды, не считая ввода данных для доступа к реестру, решение ставится «из коробки».
Для production среды предусмотрены возможности кастомизации, чтобы подогнать решение под развернутую инфраструктуру, а не инфраструктуру — под решение. Установка в кластер в виде подов позволяет не затрагивать выстроенные бизнес-процессы и не нарушать логику работающего приложения. А понятный интерфейс и выбор из множества настроек политик позволит усилить безопасность контейнерной инфраструктуры в дополнение к имеющимся средствам защиты конечных точек, NGFW, WAF и так далее.
На этом мы завершаем краткий обзор решения Kaspersky Container Security. Более подробно все аспекты решения мы рассмотрим в следующих материалах.
Авторы: Нестеренко Влада и Разумов Кирилл, Инженеры TS Solution