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

И так, что же может пойти нет?!
1) Допустим, пройдя все проверки, выкатывается образ и у него 0 уязвимостей (фантастика, но пускай).
2) Далее происходит обновление feed об уязвимостях и с его учетом у нас в том же самом образе, где минуту назад было 0, появились какие-то уязвимости (critical, high, medium, low)!
3) (Чисто как факт - в проде уже работает уязвимое приложение, через которое можно скомпрометировать систему)
4) ReplicaSets controller решает, что нужны еще Pod с тем самым образом. Это может быть по многим причинам: сработал HPA, какие-то Pods аварийное завершились по OOM, упала Node и утащила за собой эти Pods, Pods переезжают с Node на Node по какой-то причине, происходит обновление Secrets/ConfigMap/... и нужно рестартануть Pods, обновили сам YAML для Deployment и т.д. То есть опять запускается процесс выкатки приложение на том же образе ;)
5) Этот контроль видит этот образ с его critical, high, medium, low уязвимостями и блокирует деплоймент ...
6) Тут можете уже самим придумать как ваша система не справляется, деградирует, складывается как карточный домик. И соответственно бизнес и ИТ совсем не рады такому ... (Встанет вопрос кто принес ущерба больше CVE или контроль)

На бумаге существует множество красивых security подходов, НО которые совсем не учитывают operations специфику системы.

Помните, что задача ИБ не в том, чтобы сделать так чтобы во всех образах было 0 уязвимостей (это даже не реально), а в том чтобы обеспечить непрерывность работы бизнеса и не возможность атакующим реализовать бизнес угроз.

Создатели Policy Engine Kyverno решили составить конкуренцию не только OPA Gatekeeper (с этим они уже отлично справляются), но и OPA! А именно проверять не только ресурсы Kubernetes, но и в принципе любые JSON =)

В статье "Experimental Generic JSON Validation with Kyverno" они показывают, как этого можно сейчас добиться (все это пока очень экспериментально). Подробнее можно еще посмотреть выложенный проект json-validator. Так сам Kyverno по-прежнему должен запускаться внутри Kubernetes, но при этом доступен из вне, чтобы можно было к нему обратиться на прямую. Так же как и ранее это можно проворачивать в pipeline с помощью Kyverno CLI.

Как основной use case авторы заявляют, что так можно проверять конфигурации и настройки сервисов, что располагаются рядом с Kubernetes и связаны с ним.

На прошедшем Steelcon 2023 Rory McCune и Iain Smart провели свой 4-х часовой воркшоп – Container Security and Hacking with Docker and Kubernetes. Наверное, это один из самых больших сборников по безопасности контейнеров и Kubernetes. Воркшоп включает в себя следующие темы:

- Container Basics
- Docker Security
- Kubernetes Fundamentals
- Kubernetes Security
- Kubernetes Networking
- Kubernetes Distributions
- Container Secirty Problems/Challenges

К сожалению, инфраструктура, поднятая для воркшопа, больше не работает, но есть ссылка на презентацию. Однозначно рекомендуем материал для новичков и всех тех, кто хочет погрузиться в тему container security.

И продолжим тему обучений.

Недавно проводили обучение архитекторов (специально модифицированное под их задачи) одной из команд "Ростелеком-Солар" и они по результатам как нашего тренинга, так и вообще подготовки своих специалистов написали статью "Погружаемся в тему защиты контейнеризации, или как обучить тому, чему нигде не учат".

Приятно видеть такое публичное упоминание! К сожалению, большинство благодарностей от банков, платежных систем, экосистем, интернет сервисов, облачных провайдеров, онлайн кинотеатров, маркетплейсов носят закрытый характер ;)

В официальном блоге Kubernetes вышла занимательная статья "Confidential Kubernetes: Use Confidential Virtual Machines and Enclaves to improve your cluster security", посвящённая теме концепции Confidential Computing (CC). По сути, это защита от облачного/инфраструктурного уровня - более конкретнее от работников дата-центров, привилегированных облачных админов и атакующих имеющих доступ к инфраструктуре, где работает ваше приложение/контейнер/кластер.

Это базируется на идее Trusted Execution Environments (TEEs) и в данном случае могут служить технологии AMD SEV, Intel SGX и Intel TDX (работает с кодом и данными идет в специальном режиме куда никто по сути больше не имеет доступ). Учтите, что Intel выпиливает SGX и на смену ему идет TDX.

Понятно дело, что это еще все имеет раннюю степень адаптации, но направление очень интересное и за его развитием нужно следить!

P.S. В следующих постах рассмотрим конкретные примеры проектов.

Продолжим тему Confidential Computing (CC) в Kubernetes и остановимся на одном из основных проектов в этой теме.

Confidential Containers (CoCo) - это CNCF sandbox project, который позволяет изолировать Kubernetes pods внутри confidential virtual machines. Цель данного проекта установить стандарт для Confidential Computing (CC) на уровне Kubernetes pod. С точки зрения реализации сам проект представляет из себя kubernetes operator с рядом служебных сервисов ( guest-components, Key Broker Service, Attestation Service) и специальный runtimeClassName (под капотам там модифицированная kata), который нужно указать для Pod.

Всего есть 3 режима работы на базе:
1) VM-based TEEs на local hypervisor (на картинке)
2) VM-based TEEs на remote hypervisor
3) Process-based TEE

Про проект можно подробнее почитать в документации или из статьи "Confidential Containers in Kubernetes".

Наша исследовательская команда нашла довольно интересный репозиторий с исследованием "Container image with malware and crypto miner for testing". В нем автор решил проверить как различные сканеры образов могут обнаружить вредоносный код в образах контейнеров. Для этого он в легитимный образ залил (без обфускации и т.д.) солидную выборку хорошо известных malware, ransomware, crypto miner и т.д.

Что можно сказать про результаты? А то что даже те кто активно заявляют эту функциональность и вроде как даже на этом специализируются - сели в лужу (статический анализ мы уже обсуждали) ... И это еще на том что есть на VirusTotal и т.д. Хотя под это, конечно, можно достаточно просто подгонять результат ...

По своему опыту обхода антивирусов могу сказать, что когда я руководил исследовательским центром и к нам приходили наши пентестеры и просили помочь им обойти серьезные корпоративные антивирусы и EDR для запуска Mimikatz и подобного, то это занимало от нескольких часов до 2-3 дней. В контейнерных окружениях это сделать еще проще, тем более когда атакующий сам готовит весь образ ;)

Еще разница в том, что если на пользовательских тачках много ресурсов и они могут простаивать, то на Nodes в Kubernetes отдавать под это немалые вычислительные ресурсы это большая роскошь ...

P.S. Как-то мы уже делали даже опрос по данной теме.
P.S.S. NetworkPolicy - must have!

Некоторое время назад, изучая замечательную документацию GKE, наткнулись на интересный пункт "Restrict the ability for workloads to self-modify" в разделе "Harden your cluster's security".

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

В качестве защитных мер от подобного предлагается:
1) Не давать рабочим нагрузкам права на модификацию себя.
2) Если пункт 1 невозможен, то ограничить то, что может меняться. На пример, содержимое поля serviceAccountName.

Пункт 2 можно реализовать с помощью PolicyEngine. В GKE используется OPA Gatekeeper и они приводят пример такой политики на нем - NoUpdateServiceAccount (хотя это можно сделать и на Kyverno). Рекомендуем взять такую политику на вооружение или хотя бы просто ее изучить. В этой политике есть прекрасный пример того, как можно обрабатывать запросы на основе определённых пользователей или групп и добавлять их в исключения (чаще всего это делают сразу на целый Namespace).

Также хочется порекомендовать такую хорошую практику как запуск системных рабочих нагрузок на отдельных Nodes и не мешать их с обычными бизнес-сервисами ;)

Abusing Amazon VPC CNI plugin for Kubernetes – довольно интересная статья, из которой вы узнаете, что встроенный CNI плагин в Amazon не такой уж и безопасный.

Рассматривая возможности атаки на Amazon EKS, авторы статьи исследовали плагин Amazon VPC CNI для Kubernetes и выявили способы злоупотребления этим плагином для манипулирования сетями в своих интересах. Это позволяет злоумышленнику, закрепившемуся в кластере EKS, создавать и потенциально эксплуатировать сервисы в других VPC, не связанных с кластером.

В качестве возможных remedations отмечаются:

- IAM Roles for ServiceAccounts
- Blocking instance metadata service (IMDS)
- AWS IAM policy hardening

На этой неделе – 4-5 августа наша команда Luntry будет принимать участие в конференции Ural Digital Weekend 2023 в Перми. Мы выступим с докладом “Создание Network Policy в Kubernetes: ключевые аспекты и рекомендации для разработчиков”, и вместе с тем затронем вопросы того, почему разработчикам необходимо понимать и уметь в Network Policy в Kubernetes.

Купить билет можно тут, а указав наш промокод LUNTRY894, вы получите скидку 10% на всё.

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

Это же наблюдает и сообщество Kubernetes, которое уже создало для решения данной задачи Multicluster Special Interest Group. За их успехами можно наблюдать тут (пример одной из новых инициатив Cluster Inventory API).

В рамках KEP-1645: Multi-Cluster Services API они работают над Multicluster Services API (MCS API) (на картинке). Это должно позволить упросить общение микросервисов из разных кластеров. Если вам интересны реализации, то их можно посмотреть тут.

GUAC: Graph for Understanding Artifact Composition – интересная тулза, которая поможет вам определить и красиво отобразить взаимотношения между зависимостями в приложении.

На вход инструмент может принимать следующие форматы данных:

- CycloneDX
- Dead Simple Signing Envelope
- Deps.dev API
- In-toto ITE6
- OpenSSF Scorecard
- OSV
- SLSA
- SPDX

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

Концептуально, GUAC, представляет слой "Aggregation and synthesis" в логической модели software supply chain transparency. Вместе с тем, инструмент также закрывает proactive, preventive & reactive вопросы безопасности.

Наши хорошие товарищи 24–25 августа в Москве организовывают конференцию OFFZONE 2023. От нашей команды Luntry в секции AppSec выступит Сергей Канибор с докладом "Kubernetes Pentest All-in-one: The Ultimate Toolkit".

Суть доклада следующая: Когда вы проводите пентест Kubernetes кластера, несомненно вы используете различные инструменты, чтобы автоматизировать и ускорить свою работу. Но что делать, если вы находитесь в защищенном, после харденинга окружении?! В докладе мы представим наш специальный образ, которой позволит обойти разные контроли безопасности и успешно провести свои действия (обход сигнатурных движков и т.д.)

При этом мы хотим разыграть 1 проходку на конференцию! В комментариях к данному посту напишите случай из вашей (или не вашей практики), когда приходилось обходить какие-то security контроли связанные с контейнерами или Kubernetes =)

Наиболее интересный случай по нашему мнению получит проходку. Варианты принимаем до Пн (7.08).

Статья "GameOver(lay): Easy-to-exploit local privilege escalation vulnerabilities in Ubuntu Linux affect 40% of Ubuntu cloud workloads" рассказывает о двух уязвимостях CVE-2023-2640, CVE-2023-32629 в модуле OverlayFS в ОС `Ubuntu.

Наше внимание это привлекло по следующим причинам:
1) Ubuntu можно часто встретить в контейнерных окружениях.
2) OverlayFS часто используется контейнерами
3) Для эксплуатации нужны манипуляции с user namespace и это очень популярно в рамках того же kCTF (часто доступно в контейнерах)
4) Эти уязвимости это реинкарнации CVE-2021-3493 из 2020. Из-за того у Ubuntu была своя доп. логика.
5) Сверх стабильный эксплоит, так как нет никаких манипуляций с памятью.

Получается так что user namespace создавали во благо, но сейчас он часто используется совсем в противоположную сторону. Думаю что он заслуживает особого внимания и возможно на следующем БЕКОН мы покроем эту тему ;)

P.S. Вы не поверите. но работа над программой следующего БЕКОН уже идет.

На нашем канале и в наших докладах мы с командой не раз уже поднимали тему, что исправление уязвимостей в сторонних библиотеках (а современные микросервисы на 60-80% состоят из сторонних библиотек) это не простая задача как ее многие описывают (нужно только просканировать и поднять версию зависимости до нужной и все). И тут наткнулись на интересный молодой проект, который призван как помочь в этом не легком деле, так и просто пояснить какие вообще есть сложности (на примерах, того, когда они сами полезны).

Seal Security Patches — это централизованный репозитарий самодостаточных исправлений безопасности для open source библиотек. Вот такие сценарии рассматриваются, когда разработчику может быть обновиться на последнюю версию библиотеки невозможно, очень долго или не практично:
- Ломающие изменение или deprecated фичи в новой версии библиотеки
- Уязвима транзитивная зависимость
- Уязвима не поддерживаемая библиотека
- Legacy код
- Mission-critical приложение
- Уязвим сторонний Container/VM образ
- Large Language Models (LLM) код

Очень хорошие кейсы и точно все команды разработки с этим сталкивались (ну кроме последнего конечно =) ). И тут еще перечислены только технические аспекты данной проблемы, а прибавьте к этому разные процессные и сроки обновления у многих улетаю в совсем не приличное сроки. Сейчас в проекте уже доступен ряд патчей для разных npm (29), rpm (8), pypi (7) библиотек - можно зайти и посмотреть, как это организовано и применяется.

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

P.S. Мне это также напомнило решение ребят из 0patch, но только там для бинарных приложений.

Сегодня в 14:30 по Мск можно online посмотреть выступление "Создание Network Policy в Kubernetes: ключевые аспекты и рекомендации для разработчиков" от нашего коллеги Сергея Канибора (Luntry, Security Researcher) с конференции Ural Digital Weekend 2023.

Ссылка на трансляцию.

Container security fundamentals part 5: AppArmor and SELinux – пятая статья из цикла статей [1,2,3,4] про безопасность контейнеров от Rory McCune.

Автор рассказывает как можно использовать такие механизмы как AppArmor и SELinux в контейнерном окружении. Сама по себе статья небольшая и в ней отражены только основные моменты по работе с этими механизмами.

Если вы хотите более глубже погрузиться в AppArmor в контексте Kubernetes, то рекомендуем к изучению доклад от нашей команды с БЕКОНа – AppArmor и Kubernetes: настройка проактивной защиты для безопасности приложений (видео, слайды).

P.S. В качестве домашнего задания: ответьте на вопрос, чем в Kubernetes механизм AppArmor лучше чем любой другой навесной prevention механизм для контейнеров (включая тех что написаны на eBPF)?

P.S.S. На самом деле благодаря этому моменту мы и реализовали автоматическую генерацию AppArmor в нашем Luntry.

Сегодня запускаем еще один конкурс и на этот раз с нашими друзьями из DevOops!

Ребята продумывают крутой стикер пак для своей конференции и хотят чтобы он нравился абсолютно всем! И в этом можно и нужно поучаствовать. Предлагайте свои варианты стикеров на тему DevOps, DevSecOps, контейнеров, Kubernetes! Самые прикольные стикеры будут включены в стикер пак и раздаваться на мероприятии. За лучший стикер приз билет на конференцию (есть и приятный сюрприз и для всех участников)!

Варианты стикеров принимаются до 15 августа! Варианты прикрепляйте к комментариям к данному посту.

Наша команда Luntry также примет активное участие в программной части конференции и в ее круглых столах!

P.S. Сегодня последний день чтобы поучаствовать в конкурсе за билет на конференцию OFFZONE!

"Fun with privileged container breakout" и "The Route to Root: Container Escape Using Kernel Exploitation" это две хорошие статьи, посвящённый одной теме - побегу из привилегированного контейнера (или при наличии CAP_SYS_MODULE) с помощью подгрузки своего модуля ядра. Про такой же сценарий наша команда Luntry рассказывали пару лет назад в докладе “Container escapes: Kubernetes edition”.

Метод, конечно, шумный, требует серьезные привилегии, но при этом стабильный и имеет большое покрытие при использовании. Как минимум знать и помнить о нем нужно)

Kubefuzz – фаззер для Kubernetes Admission controller chains. Будет полезен для тестирования и выявления неожиданного поведения, там где конфигурация Admission controllers довольно сложная.

Сами правила для генерации и мутации, описываются в отдельном ресурсе – Constraint. Всё это работает по принципу белого списка. Может работать в трех режимах: Generation – для генерации данных, Mutation – для их мутации, и Fuzzing – по сути комбинация первых двух режимов.

Что интересно – сама тулза была представлена на недавно прошедшей конференции Troopers23. Ознакомиться со слайдами можно тут.

Когда наша команда проводит аудит безопасности Kubernetes в более продвинутых компаниях сейчас для всех их политик (для Policy Engine) они как правило пишут и ряд тестовых ресурсов для проверки как с положительным результатом, так и с отрицательным.

В рамках KubeCon + CloudNativeCon Europe 2022 был представлен доклад "Komrade: an Open-Source Security Chaos Engineering (SCE) Tool for K8s" (слайды, видео), а с ним и выложен инструмент Kirvis.

Те, кто был на моем тренинге, знают, что за темой Security Chaos Engineerin я активно наблюдаю и люблю обсудить) И тут как раз на эту тему попался доклад!

Изучая данные слайды, было очень приятно видеть те же самые мысли, идеи, что мы активно освещаем как в наших выступлениях (с 2021), так и фичах нашего решения. На пример:
1) "Our systems have evolved beyond our human ability to mentally model their behavior"
2) "Software ONLY Increases in Complexity"
3) "Our systems have become more complex and messy than we remember"
4) "Cyber Security is Context Dependent"
5) "How do I know if my Security Really Works???"
6) "Understand your system and its security gaps before an adversary does"
7) "Hope is Not an Effective Strategy"

В этом есть много объяснений почему мы решили делать security observability и упор на поведенческий анализ.

Kirvis (после публикации ни разу не обновленный) по своей сути меняет настройки в небезопасное состояние, а потом возвращает в исходное. Ваши инструменты ИБ должны это конечно обнаружить! Еще там упоминается такой инструмент по этой теме как ChaoSlingr (тоже заброшен) (слайды о нем и с ними мы также рекомендуем ознакомиться).

Как по мне, к данному подходу нужен высокий уровень зрелости как в ИТ, так и в ИБ и он есть совсем у малого числа компаний и поэтому время этого направления еще не пришло.