В статье Process monitoring: How you can detect malicious behavior in your containers отражены главные мысли по поводу runtime защиты в Kubernetes.

Автор также рассказывает почему традиционные системы мониторинга, типа EDR или AV не применимы в Kubernetes. Единственный правильный способ отслеживать работу приложений в Кубере – собирать информацию на всех уровнях, начиная с инфраструктуры и заканчивая самим приложением, работающим в контейнере. Используя при этом такие механизмы как eBPF, ptrace, kprobes.

Далее описываются основные техники и способы выстраивания такого рода мониторинга:

- Kubernetes Audit Log
- Сбор логов с инфрастуктуры
- Отслеживание и блокировка syscalls, а также изменений файловой системы контейнера
- Использование NetworkPolicy
- Приостановка контейнера (DFIR)

Рассматривая тенденцию ухода от sidecar proxy в Service Mesh, я уже писал, что полностью отказать от них и все перенести в eBPF нельзя. И вот есть прекрасная картинка иллюстрирующая это. С левой стороны, то что можно и уже перенесли в eBPF, а справа что нельзя. Особое внимание заслуживает раздел Security.

Вы знали, что с помощью инструкции COPY в Dockerfile можно копировать любые файлы из интересующего нас образа? Потенциально это позволяет излекать чувствительные файлы без авторизации из любого образа.

Так например из образа madhuakula/hacker-container копируется директория /root/pwnchart в образ alpine по пути /pwnchart.

Импакт может быть довольно существенный, но я надеюсь никто не хранит чувствительные данные внутри контейнера :)

Отличный специалист Rory McCune начал очередной цикл статей (думаю все помнят его цикл статей про PCI DSS в Kubernetes) "Container security fundamentals: Exploring containers as processes".

Он доступно, наглядно и с примерами показывает как можно работать с контейнерами теме же инструментами, что вы привыкли работать и с обычными Linux процессами. При этом обращает внимание на то как это затрагивает security, как со стороны защищающегося, так и атакующего. Маленький спойлер: доступ на Node (container escape и т.д.) открывает атакующему аттракцион невиданной щедрости)

Это должно отлично зайти абсолютным новичкам в данной теме. Следите за данным циклом!

Тут хорошие ребята запустили исследование состояния DevOps в РФ 2023. Сcылка на сам опросник ТУТ. Если вам несложно и есть чем поделиться с сообществом, то будет здорово если вы поучаствуете в этом исследовании и внесете свой вклад в развитие нашей индустрии ;)

P.S. Результаты предыдущего исследования за 2021 год можно посмотреть тут.

В продолжение вчерашнего поста, хочется поделиться ещё одним ресерчем. 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 можно посмотреть тут.