В продолжение вчерашнего поста, хочется поделиться ещё одним ресерчем. Kubernetes in the wild report 2023 – довольно интересное исследование по использованию Kubernetes в компаниях в production среде.

Вот ключевые моменты из этого репорта:

- Kubernetes moved to the cloud in 2022
- Kubernetes infrastructure models differ between cloud and on-premises
- Kubernetes is emerging as the “operating system” of the cloud
- The strongest Kubernetes growth areas are security, databases, and CI/CD technologies
- Open-source software drives a vibrant Kubernetes ecosystem
- Java, Go, and Node.js are the top 3 programming languages for Kubernetes application workloads

На ближайшем DevOpsConf 2023 в Москве наш коллега Станислав Проснеков в рамках доклада "Локальная инфраструктура для разработки K8s-native ПО" расскажет, как у нас устроена разработка и тестирование нашего продукта Luntry по защите Kubernetes. Во главе угла тут стоит наша другая внутренняя разработка (она и главный герой презентации – пару слов о ней я уже писал тут), которая в несколько кликов для разработчиков и тестировщиков позволяет за несколько минут создать один из 1050 вариантов (и эта цифра продолжает расти) возможных конфигураций Kubernetes инфраструктур!

Это не только удобно при отладки тех или иных кейсов клиентов, к инфраструктурам которых у нас нет доступа, но и для R&D когда мы проверяем разные трюки, фичи и наши гипотезы по защите и атаке Kubernetes инфраструктур. В общем в полной степени развязывает нам руки =)

Я уже неоднократно писал, что Kubernetes Audit Log является важной частью безопасность k8s. НО при активации этого механизма возрастает нагрузка на Kubernetes API Server и как-то надо вообще справляться с целым тайфуном сообщений от этой подсистемы. Конечно, разумным планом является оптимизаций того что логировать, а что нет. И одним из хороших вариантов оптимизации является вырезание событий/действий завязанных на системные субъекты (производимые ими). Идея в том чтобы вырезать доверенных роботов (и молиться чтобы Skynet оставался только в кино), которые в основном и шумят в логах.

В аттаче к этому посту вы можете видеть пример такой оптимизации. УЧТИТЕ что тут только пример оптимизации, тоесть это только часть политики, а не полная версия. Все это приводиться в качестве примера и ее нужно еще модифицировать с учетом вашего окружения!

Если у вас есть свои трюки и советы по оптимизации Kubernetes Audit Log, то предлагайте в комментариях ;)

Месяц назад, на прошедшем CloudNativeSecurityCon North Amreica 2023, анонсировали новый сертификат от The Linux Foundation – Kubernetes and Cloud Security Associate (KCSA). Возможность пройти сертификацию появится в Q3 2023 года.

Экзамен включает в себя проверку следующих знаний:

- Developing security policies and procedures and helping ensure compliance with industry standards and regulations
- Identifying and assessing security risks and vulnerabilities and helping implement controls to mitigate those risks
- Assisting in incident response and forensic investigations, as well as testing and monitoring security systems 
- Educating and training employees on security best practices

В конечном итоге мы имеем пять сертификаций, посвященных Kubernetes от The Linux Foundation : CKA, CKS, CKAD, KCNA, KCSA.

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

Поэтому решили обратиться к сообществу и посмотреть насколько круто с фантазией у вас =) Было бы здорово придумать название для конференции, а мы уже какие-нибудь подарки со своей стороны подарили!

В общем, как по вашему должна называться российская специализированная техническая конференция по безопасности контейнеров и контейнерных сред?

Варианты пишите пожалуйста в комментарии к данному посту до 10 марта.

Заранее всем спасибо!

Сегодня пятница, а значит что выходные уже совсем близко! И если вы давно планировали, но постоянно откладывали почитать исходных код Kubernetes, то тут как раз для вас появился отличный цикл статей про Kubernetes API Server. Можно сказать разбор всей внутрянки/исходников сердца Kubernetes! Пока выложено 3 части:
1) Welcome to Kubernetes API Server Adventures
2) K8s ASA: The Storage Interface
3) K8s ASA: Watching and Caching

Это настоящие лонгриды ведущие по исходному коду и комментирующие все по определённому аспекту Kubernetes API Server. Обязательно для тех кто не только просто хочет пользоваться k8s, но и понимать как он работает.

2023-ий год продолжает радовать отчетами о security audit open-source cloud native проектов. На этот раз containerd прошёл audit fuzzing.

В ходе тестирования было написано 28 фаззеров, покрывающих следующий функционал:

- containerd’s CRI endpoints
- Metadata image handling
- Image importing
- Archive diffing
- Content store processing
- Stream decompression
- Filters parsing

По результатам аудита были обнаружены всего четыре уникальные некритичные проблемы. Это свидетельствует о хорошо написанной и поддерживаемой кодовой базе проекта containerd. Три из них были в самом containerd, а одна – в сторонней зависимости. Найденной проблеме был присвоен CVE-2023-25153.

С полными результатами аудита можно ознакомиться тут.

Один из постоянных читателей данного канала написал и поделился своей заметкой под названием "Certified Kubernetes Security Specialist — мой опыт сдачи экзамена". Не сложно догадаться что там он делиться своим свежим опытом (февраль этого года) получения сертификата CKS.

Думаю для тех кто думал о таком это полезно + есть возможность какие-то моменты если что уточнить у автора в комментариях =)

P.S. Если вы пишите, создаете что-то по теме безопасности контейнеров, безопасности Kubernetes - присылайте!

И тут я понял что еще не все темы по безопасности контейнеров осветил на канале .... Хотя думаю что это что-то про это будет =)


Спасибо читателю каналу за наводку)

P.S. Опечатка или крутой маркетинговый ход?)

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

- gtfobins
- pwnkit
- dirty pipe
- +w docker.sock

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

12-14 марта буду на DevOpsConf 2023 в Москве. Как всегда буду рад лично познакомится и пообщаться на тему безопасности контейнеров и Kubernetes! Найти меня будет очень просто по вот этой худи ;)

Не перестаю удивляться правилам Falco ... По крайней мере тем что идут из коробки (ПОМНИ 1,2,3). И вообще редко доводилось встречать чтобы их кто-то полноценно проверял (представляете их еще и проверять надо!!!) и тюнил под себя - обычно максимум сокращают набор этих правил, чтобы он ел меньше ресурсов)

И так, мы тут нашей R&D командой в рамках внутреннего исследования (подготовки для K8s pentest и параллельно улучшения собственной runtime защиты) взяли скачали последнюю версию Falco c последним набором правил. И на системе с ним запустили наш Luntry, уязвимый контейнер и в нем через ряд команд запустили нашего вчерашнего героя traitor - ничего не меняя в нем!

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

Очень сильно удивившись этому - мы полезли смотреть почему же так?! Оказалось что в последней версии из 76 правил около 20 выключены и требуют доп. настройки, ну а также очень глупые сигнатуры, которые мы невольно сразу смогли обойти (честно говоря в этом месте написать что-то толковое очень тяжело...). Но раскрывать всех карт не будем и может расскажем это в рамках какого-нибудь доклада ;)

В общем, классика проблем сигнатурных подходов в полный рост.

Пару дней назад, в блоге Kubernetes вышла статья – Forensic container analysis, которая по сути является продолжением статьи Forensic container checkpointing in Kubernetes, о которой мы писали ранее. В ней автор детально показывает как с помощью таких инструментов как checkpointctl, tar, crit и gdb, работать с checkpoint.

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

- bind.mounts – содержит информацию о всех смонтированных директориях и файлах
- checkpoint/ – сам checkpoint, созданный CRIU
- config.dump и spec.dump – содержат необходимые метаданные для восстановления контейнера
- dump.log – содержит логи CRIU, записанные при создании checkpoint
- stats-dump – статистика дампа
- rootfs-diff.tar – файловая система контейнера

Данная статья будет полезна как forensic специалистам, так и тем кто хочет глубже погрузиться в тему контейнерного DFIR.

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

В основном, инструменты, которые помогают это сделать используют хак с редактированием LD_PRELOAD библиотеки, при этом быстро и легко обнаруживаются. Команда Sysdig TRT заметила новый приём злоумышленников для избежания детекта сетевого взаимодействия.

Злоумышленники используют тулзу graphtcp, которая отличается от аналогичных инструментов тем, что позволяет перенаправлять трафик только от определённого процесса, маршрутизируя его через локальный прокси и используя при этом системные вызовы fork() и ptrace().

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

Вышла статья "Container security fundamentals part 2: Isolation & namespaces" из цикла о котором я писал ранее. Опять же тут про базу - без которой никуда ... И на этот раз она посвящена всем имеющимся на текущий момент Namespaces и какую они роль играют в вопросе изоляции.

21 марта в Москве в онлайн и офлайн форматах пройдет VK Kubernetes Conf!

Как обычно среди докладов там будем много интересного как про сам Kubernetes, так и про его безопасность.

Я там также поучаствую в рамках кругло стола, где мы пообсуждаем «Тренды в разработке и безопасности». Скорее всего зароним там темы eBPF и WebAssembly как альтернативу docker контейнерам.

Ссылка на регистрацию тут.

P.S. Мое выступление с VK Kubernetes Conf 2021 можно посмотреть тут.

Top 10 most used policies for Kyverno – подборка самых популярных и часто используемых политик Kyverno. Несмотря на то, что Kyverno является маленьким кусочком в большом пазле (фреймворке) под названием Kubernetes, и в зависимости от окружения политики могут быть разными, вот некоторые из наиболее распространненных политик, которые часто используются в коммьюнити:

– Resource limits
– Namespace isolation
– Security context
– Image policies
– Network policies
– Labeling
– Pod affinity/anti-affinity
– Secrets management
– RBAC policies
– Compliance

Если вы хотели подробней узнать о Kubernetes SeriviceAccount Token, то эта статья для вас. В ней рассматриваются следующие аспекты:

– ServiceAccountToken это всего лишь JWT
– ServiceAccount Token Process Flow – как токен назначается и монтируется внутрь Pod
– Headers, Content и Signature – из чего состоит токен

Важно отметить, что начиная с версии Kubernetes 1.24 токены для Service Account не генерируются автоматически. Для их создания нужно использовать TokenRequest API.

О том, что может делать атакующий с правами на создание TokenRequest мы рассказывали ранее.

P.S. Всем хороших выходных!

Всю прошлую неделю гремел кейс Dero Cryptojacking связанный с Kubernetes [1]. Как по мне там чего-то такого особо интересного нет - много где можно с этим ознакомиться...

НО извлечь урок и понять (еще раз) угрозу анонимного доступа (anonymous access к Kubernetes API) (через который атака и прошла) можно. Именно этому и посвящена статья "Let's talk about anonymous access to Kubernetes". А именно:
1) Принцип работы и назначение
2) Отключение данного доступа

Несколько дней назад было опубликовано три уязвимости в CNI Cilium:

1. Cilium-agent container can access the host via `hostPath` mount – если у атакующего существует возможность изменять используемые images в Workloads, подменив image в cilium-agent, он может получить доступ к директории /opt/cni/bin на Node через hostPath.

2. Cilium eBPF filters may be temporarily removed during agent restart – во время рестарта агента Cilium есть небольшой промежуток времени, когда eBPF функционал недоступен. В этот момент злоумышленник, например, обойти Network Policy.

3. Potential network policy bypass when routing IPv6 traffic – при определенных условиях Cilium может ошибочно присвоить source IP-адрес кластеру, идентифицируя внешний трафик как исходящий от хоста, на котором работает Cilium. Как следствие, это может привести к обходу Network Policy.

Уязвимости затграгивают разные версии, необходимые патчи уже выпущены. Самое время обновиться.

Наконец-то мои руки дошли до новых сетевых фишек/реализациях в Kubernetes, а если быть более конкретным то до двух проектов: Cilium Service Mesh и Istio Ambient Mesh. При этом хотелось с ними познакомиться параллельно, чтобы можно было производить сравнение их фич и подходов.

Начнем прям с очень верхнеуровнево сравнения:
- L4 в первом реализуется на eBPF, второй в компоненте ztunnel (есть также планы переноса в eBPF) - все катиться как DaemonSet
- L7 в первом реализуется в envoy из того-же DaemonSet, второй при необходимости может создать Waypoint proxy (под капотом envoy) на service account или на namespace

Видим что sidecar пропали. Но разработчики Istio говорят что sidecar-реализация продолжит развиваться и поддерживаться и совместима (насколько я понял) с новой реализацией - тоесть одновременно можно как использовать sidecar, так и нет.