Замечательная исследовательская заметка "Fun with Kubernetes Authorization Auditing - multiple authz plugins" от Rory McCune. Рассказ о том как гибкость Kubernetes может добавить ряд сложностей и в данном моменте тут про авторизацию. Я думаю многие в курсе что в стандартном кластере обычно у вас сразу два обработчика авторизации это RBAC и Node. Но можно и больше и мнение каждого будет учитываться.

Идея статьи сводится к тому что если вы используете свою кастомную авторизацию, то встроенные механизмы k8s, на примере, kubectl auth can-i могут работать некорректно. Но могу честно сказать по нашему многолетнему опыту аудитов командой Luntry такого мы еще не встречали ...

В статье содержится код проекта, демонстрирующий как вы еще можете написать и добавить свой собственный Authz Webhook с логикой. И на память приходит реализация ReBAC, о которой мы писали ранее.

Также тут несколько раз повторяется о том что admission control всегда имеет последнее слово и при желании может отменить, то что разрешила авторизация. На пример, ограничить в правах Cluster Admin ;)

Nimbus – инструмент, который авторы позиционируют как систему автоматизации безопасности на основе намерений.

Главная его цель максимально разделить намерения безопасности от их фактической реализации, благодаря использованию Policy Engine, Network Policy и других механизмов в Kubernetes. Так, например пользователь может задать ресурс в виде высокоуровневой абстракции "Не допускать privilege escalation" или "Запретить общаться по DNS со всеми, кроме Kube-DNS", а nimbus преобразует его в конкретную политику и применит к необходимому Pod.

В данный момент тулза имеет три адаптера и может генерировать соответствующие политики для KubeArmor, Kyverno и Native Network Policy.

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

Container Image Layers and Container Image Scanning Explained – неплохая статья для новичков и тех, кто хочет разобраться с тем как устроены слои в docker image, а также как работают сканеры образов.

Если говорить верхнеуровнево, то как правило, такие сканеры работают примерно по одному и тому же принципу:

1) Выкачивают образы из registry
2) Анализируют каждый слой образа – извлекают tar-файлы и проверяют наличие пакетов по заранее известным путям
3) Объединяют результаты анализа
4) Сканируют найденные пакеты на уязвимости

Если вам захотелось посмотреть как выглядит ваш ETCD внутри, то инструмент ETCD Keeper может с этим помочь.

По сути это небольшой web ETCD client с возможностью просматривать, добавлять, обновлять или удалять ноды, а также сами ключи и их значения. Есть поддержка как v2 так и v3 версии.

Cегодня хотим подсветить вам очень интересный доклад - "How to get Slim with SOCI and Star(g)s: Minifying Containers with Lazy Image Loading in ContainerD". Из него вы узнаете про:
- минификацию образов, которой занимается проект mint
- что такое ленивая загрузка образов на базе SOCI и Stargs.

Всем, хороших выходных!

Чуть больше 1 месяца (точнее 39 дней) осталось до нашей второй конференции БеКон 2024!

Недавно на Хабре опубликовали небольшой анонс с обзором прошлогодней - если еще не решили идти или нет, то рекомендуем ознакомиться ;)

В этом году доклады покроют такие темы как:
- Management/organization
- Cluster security
- Image security
- Network security
- Secret management
- Multitenancy

Замечательное сравнение "Benchmark results of Kubernetes network plugins (CNI) over 40Gbit/s network [2024]"!

Условия:
- Kubernetes 1.26
- Ubuntu 22.04
- CNI с версиями на январь 2024

Подопытные (в скобках текущая доступная версия, чтобы сравнить насколько за это время CNI обновился):
- Antrea v1.15.0 (v2.0.0)
Варианты: Default / No encapsulation / IPsec / Wireguard
- Calico v3.27.2 (v3.27.3)
Варианты: Default / eBPF / Wireguard / eBPF+Wireguard / VPP / VPP IPsec / VPP Wireguard
- Canal v3.27.2 (v3.27.3) (Это CNI flannel с NetworkPolicy от Calico)
Варианты: Default
- Cilium v1.15.2 (v1.15.4)
Варианты: Default / with Hubble / No hubble / No kubeproxy / IPsec / Wireguard
- Kube-OVN v1.12.8 (v1.12.13)
Варианты: Default
- Kube-router v2.1.0 (v2.1.1)
Варианты: Default / All features

Нас часто спрашивают что рекомендуем мы. У нас нет какого-то любимчика, главное чтобы команда клиента могла с этим CNI работать и была поддержка NetworkPolicy. У нас даже в Luntry одновременно есть автоматическая генерация NetworkPolicy во всех форматах: Native, Calico, Cilium (для полноты не хватает Antrea, но пока не встречали у клиентов).

Недавно прошла замечательная конференция Container Plumbing Days 2024 (сайт, расписание/cлайды, видео) с которой уже доступны все материалы! Думаем что это замечательное время препровождения на этих выходных, предвкушая приближающийся БеКон 2024 ;)

Отдельно мы отметим такие доклады как:
- "Confidential Containers with the Crun-Krun Container Runtime"
- "Kata Containers: Security and Containers Without Compromise"
- "Usernetes Gen2: Kubernetes in Rootless Docker, with Multiple Nodes"
- "Hot Fix: Securing the Vulnerable Images with Copa"
- "CDI: The Future of Specialized Hardware in Containers"

С большим удивлением для себя узнаем, что очень много людей, что занимается приложениями в контейнерах, Kubernetes, облаках не слышали о 12 факторах. Статья "The Twelve-Factor App: Best Practices for Cloud-Native Applications" позволяет закрыть данный пробел.

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

Очень хочется обратить ваше внимание на один из докладов с нашей конференции БеКон 2024. Речь идет про доклад "Почему защитой k8s должно заниматься целое подразделение?" от Артема Мерец.

Почему именно на него? За прошлый год к нам порядка 4-5 раз обращались разные компании с просьбой помочь обосновать наличие выделенного департамента/отдела/... , который целенаправленно специализируется на безопасности Kubernetes кластеров и нагрузки в нем. Сейчас у многих картина выглядит печально и за это отвечает, где AppSec, где DevOps, где DevSecOps, где Infrastructure team и т.д. и это помимо других задач и направлений. В итоге, и фокуса, и ответственных, и результата значительного нет …

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

Матрица MITRE ATT&CK получила обновление v15.1 (она обновляется два раза в год). И если матрицы, вроде Windows или Mobile получили существенные изменения, то про Container Matrix такого сказать нельзя.

Из изменений можно отметить добавление новой саб-техники Container Service, а также обновление техники Deploy Container. В саб-технике Container Service не добавили по факту ничего нового, а в технике Deploy Container просто расширили описание (мы проверили и сравнили с прошлой версией).

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

Отдельно ваше внимание хочется обратить на группу докладов про Service Mesh. Это "Строим заборы между сервисами" и "Все ли Service Mesh одинаковы полезны для ИБ?" соответственно от Андрея Бойцева и Максима Чудновского.

В первом, речь пойдет про Authorization Policy от Istio и то, как с этим работать и к чему нужно готовиться. Знаем многие хотят L7 политики, но боятся и не знают как к этому подступиться - тут будет представлен реальный опыт.

Во втором докладчик нас погрузит в ближайшее будущее/настоящее и покажет, как Service Mesh в sidecar-less реализации (Cilium Service Mesh, Istio Ambient Mesh) помогут в вопросах ИБ с точки зрения шифрования, взаимной аутентификации и авторизационных политик. В общем, посмотрим, как это устроено под капотом и где мы получим это бесплатно, а где нет.

Напомним, что все доклады программы БеКон — это приглашенные доклады - мы целенаправленно идем к конкретным людям и просим от них конкретный материал. Все это с учетом нашего опыта и наблюдений по отрасли и запросов рынка и компаний. Так что за всей программой стоит строгая концепция, которая призвана помочь вам применить это все в работе.

Времени, как и билетов на конференцию осталось уже не много – спешите! Билеты можно взять тут.

Коротенькая, но очень полезная статья с говорящим названием "Policy Enforcement in Kubernetes: Restricting kubectl exec with Gatekeeper".

Из нее вы узнаете:
1) почему стоит контролировать не только операции CREATE и UPDATE, но и CONNECT над ресурсами.
2) как можно гибко контролировать и ограничивать то что пользователь хочет выполнить в kubectl exec. Например, разрешить все кроме интерактивных сессий или сделать whitelist команд.

P.S. В качестве домашнего задания можете сделать тоже самое и на Kyverno ;)

Сегодня мы хотим запустить конкурс!

Приз: Проходки на конференцию БеКон 2024

Задание: Напишите какие костыли вы, ваши коллеги, ваши друзья делали/видели в компаниях для обеспечения ИБ в Kubernetes кластерах или в процессе безопасной разработки контейнерных приложений (DevSecOps).

Условия: 3 cамые интересные на наш взгляд истории, описанные в комментарии к данному посту до 15 мая получат приз ;)

P.S. Уже работаем над стикер паком для конференции! Будет такой же классный и будет выдан всем участникам.

В Calico нашли новую CVE-2024-33522 – она аффектит как Open Source версии (v3.27.2 и ниже), Calico Enterprise (v3.19.0-1, v3.18.1, v3.17.3 и ниже), и Calico Cloud (v19.2.0 и ниже). Сценарий эксплуатации довольно редкий – злоумышленник должен попасть на ноду (и при этом не быть root). Проблема возникает из-за некорректной установки SUID бита в сочетании с возможностью контролировать входной бинарный файл для установки CNI Calico, что позволяет злоумышленнику запустить произвольный бинарь с повышенными привилегиями.

Интересно, что в Calico находят примерно один баг в год, тогда как в Cilium довольно активное security сообщество (только за 2024-ый год было найдено 5 CVE). Связано ли это в целом с более активным и масштабным коммьюнити Cilium думайте сами 😉

15 мая в 12:00 в рамках активности КОД ИБ под названием БЕЗОПАСНАЯ СРЕДА пройдет вебинар "С чем безопаснику стоит есть Kubernetes и почему это отличается от всего с чем вы работали раньше?".

Наша команда Luntry примет участие вмести с крутыми специалистами и нашими хорошими друзьями из Тинькофф, Wildberries и Okko.

Зарегистрироваться можно тут.

В процессе, подготовки нового исследования, копаясь на сайте проекта gVisor, который является sandbox runtime, была найдена интересная/хайповая формулировка.

В новых реалиях мы будем защищаться не только от не доверенного, стороннего кода, но и от сгенерированного машиной кода с помощью Large Language Model (LLM).

В контейнерных окружениях с этим будет попроще, но вот с чисто Windows и Linux окружениями ....

P.S. Напоминаем, что идет конкурс и есть возможность выиграть билет на БеКон 2024!

26 мая (воскресенье) в 12:00 в зале Фобос в секции в SECURE DEVELOPMENT в рамках Positive Hack Days Fest 2 наша команда представит доклад "Кубик Runtime в конструкторе Kubernetes для безопасности".

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

Но решит ли это все проблемы и не добавит ли новых?

В рамках доклада рассмотрит такие инструменты/механизмы как Sandbox, microVM, WASM, Sandbox API, Confidential Containers в мире Kubernetes.

netfetch – проект, по заявлению автора, направленный на демистификацию Network Policy в Kubernetes.

Инструмент проходится по всем нейсмпейсам и проверяет есть ли внутри них Network Policy (Native и Cilium), затем проверяет к каким Pods они привязаны. Тем самым вычисляет unprotected workloads – те, которые не находятся под влиянием Network Policy.

Также из интересного, netfetch умеет предлагать (генерацией это назвать сложно) сетевые политики для тех самых unprotected workloads. Для этого тулза анализирует YAML-манифесты Pods и основываясь на этой информации формирует NetworkPolicy. Всё это работает как через CLI так и через веб-дашборду.

На первый взгляд, инструмент кажется довольно интересным. Но когда начинаешь разбираться в правильности предложенной политики, всплывает кучу нюансов – учитываются ли ClusterWide политики? а если приложение общается с БД за пределами кластера? И другие прочие моменты..

В МГТУ им. Н.Э. Баумана по инициативе кафедры ИУ10 «Защита информации» состоится уникальный цикл лекций по фундаментальным информационным технологиям, их развитию в России и в мире "Школа фундаментальных технологий разработки безопасного ПО".

Наша команда Luntry проведет лекцию на тему «Безопасность инфраструктур под управлением оркестратора Kubernetes» состоится 27 мая в 13:30.

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

Обязательно зайдите и ознакомьтесь со всеми лекциями (их всего 12 штук) и они покрывают широкий спектр тем: операционные системы, система управления базами данных, виртуализация и контейнеризация, интерпретаторы, разработка безопасного программного обеспечения, композиционный и компонентный анализ!

Зарегистрироваться и ознакомиться с подробной программой и спикерами можно на сайте и в телеграм-боте.

P.S. Все лекцию должны будут доступны в записи для всех желающих.

Сегодня хочется привлечь ваше внимание к докладу "Латаем огрехи в образах приложений с помощью Kubernetes", который наша команда Luntry готовит к БеКон 2024. Данный доклад явно будет сильно отличаться от всех на конференции (и тех что мы делали до этого), так как мы изначально задумывали его как шуточный, немного юморной, не серьезный что ли.

История начинается с того что к вам/нам попадает готовый образ без каких-либо исходных данных (исходники, dockerfile - забудьте у нас их нет) и при этом он плох настолько на сколько это вообще можно придумать:
1) Много лишнего в базовом слое: Шумные отчеты об уязвимостях в базовом слое, setuid/setgid файлы, большой Attack Surface, возможности для LotL-атак
2) Чувствительная информация в слоях образа
3) Разные не закрытые CVE в самом приложении, рядом лежат майнеры и т.д.
4) Dockerfile противоречит всем лучшим практикам CIS.

В общем выдуманная ситуация (или нет?!) ...

И в таких условиях мы начинаем из этого делать конфетку. И такую, что многие позавидуют даже при наличии всех исходных данных)

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

Основная идея показать какие возможности и гибкость дают контейнеры и Kubernetes при харденинге и обеспечении ИБ.