Стал доступен отчет security audit для проекта CNI Cilium. Помимо списка найденных проблем и баг (22 всего) для широкой аудитории определенно будет интересно и полезно ознакомиться составленными для данного проекта:
- Cilium architecture
- Threat actor enumeration (на скриншоте)
- Threat surface enumeration

К сожалению, аудиторы совсем не уделили внимание вот этому странному моменту с identity о котором я писал ранее.

Часто людей, которые работают с Kubernetes по-шутке называют YAML-программистами.

Сегодня делюсь довольно простой, но очень полезной подборкой трюков и фишек при работе с YAML в Kubernetes.

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

- Online YAML linter
- YAMLLint
- VS Code YAML extension
- yq

Наткнулся тут на любопытную заметку "Restricting cluster admin permissions", где ребята показали как они с помощью политики Policy Engine Kyverno ограничивают права высоко привилегированного пользователя с Cluster Role cluster-admin (и не только, в политике вообще есть раздел subjects). Напомню что штатными средствами Kubernetes отбирать права нельзя.

На этой волне я вспомнил свою идею, про приманку (honeytoken) в виде заманчивого/привилегированного SA token, который может получить злоумышленник, а мы его поймать и не дать сделать ничего критичного с помощью этого SA token =)

Если вы не очень понимаете о чем я, то рекомендую посмотреть мой доклад "Безопасность Kubernetes: Фаза Deception".

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

В статье 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 выключены и требуют доп. настройки, ну а также очень глупые сигнатуры, которые мы невольно сразу смогли обойти (честно говоря в этом месте написать что-то толковое очень тяжело...). Но раскрывать всех карт не будем и может расскажем это в рамках какого-нибудь доклада ;)

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