В статье Breaking Boundaries - Kubernetes Namespaces and multi-tenancy рассмотрены острые углы K8S RBAC и разница между тем, как мы воспринимаем границы безопасности, и тем, какими они являются на самом деле.

Если у вас были сомнения насчет некоторых моментов в RBAC, то эта статья поможет понять, на что стоит обратить внимание.

Автор статьи рассказывает:

- почему namespaces — это не та граница безопасности, которой их считают;
- как wildcard-разрешения в RBAC превращаются в компрометацию всего кластера;
- странные взаимодействия RBAC и namespace-объектов;
- техники перечисления ресурсов даже без каких-либо прав.

В конце рабочий недели мы хотим поделиться очень крутой MindMap под названием "EDRmetry Linux Matrix - Comprehensive Hands-On Attack TTPs Catalog for Red and Blue Teams". Конечно, там не обошлось без Docker c Kubernetes:
- EDR-T6216 - Docker BOTB Break out the Box
- EDR-T6215 - Docker Host Escape with Proc injection
- EDR-T6147 - Docker Host Escape with socket
- EDR-T6300 - K8S - Run a privileged pod
- EDR-T6301 - K8S - Writable hostPath mount
- EDR-T6304 - K8S - Kubeconfig file
- EDR-T6303 - K8S - CronJob
- EDR-T6305 - K8S - Malicious Admission Controller
- EDR-T6306 - K8S - Static pods
- EDR-T6299 - K8S - Dump etcd database
- EDR-T6298 - K8S - Steal Pod Service Account Token
- EDR-T6302 - K8S - Sidecar injection

Список касаемо K8s, конечно, очень скудный ... Но хоть что-то.

Atlas - инструмент с открытым исходным кодом, который предназначен для анализа сети, визуализации и мониторинга Docker контейнеров.

В общем, будет полезно тем кто хочет хоть как-то понять что твориться с Docker контейнерами у них в сети.

Live demo можно посмотреть тут.

P.S. А какие вы еще знаете/используете инструменты для инвентаризации Docker системе у себя в инфраструктуре ?

Сегодня мы вас познакомим с идеей Software Bill of Behavior (SBoB) и инструментом, который позволяет ее реализовать - bobctl с помощью eBPF.

Все это было представлено в рамках доклада "Meet BOB: the supply chain provided “bill of behaviour” for anomaly-based runtime security" на Cloud Native Summit Munich 2025 (больше докладов тут).

Смысл тут как у SBOM, только для поведения, происходящего во время работы:
- Используемых capabilities
- Сетевая активность
- Файловая активность
- Запуск исполняемых файлов
- Используемых syscalls

Такая легитимная модель поведения приложения, при отхождения от которой можно фиксировать аномалии, атаки, вредоносную активностью и т.д.

О таких моделях поведения мы писали ранее - Cloud native workload fingerprints. У нас в Luntry такое тоже представлено, но с оглядкой на наше виденье и опыт. Еще 5 лет назад примерно это же мы и хотели сделать, но многое из этого разбивается о суровую реальность и становиться не применимо в реальных ситуациях =)

P.S. Так некоторые клиенты с заказной разработкой уже запрашивают модели поведения с исполнителей для сдаваемых проектов ;)

Совершенно простенький, даже можно сказать образовательный проект на eBPF под названием rootisnaked, который позволяет через хук commit_creds фиксировать повышение привилегий до root.

Недавно задумывался, что меня больше всего удручает в вопросах безопасности Kubernetes.

И понял, что это люди. Люди, которые в 2025 году, пытаются натянуть сову на глобус и подойти к вопросу безопасности контейнеров и Kubernetes также как и к безопасности условного Active Directory. Тоесть без понимания темы и слепым следованием регламентам 20-летней давности.

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

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

Согласны или нет? Или может у вас есть какая-то своя боль?

Сегодня мы поделимся с вами одним инсайдом =)

В начале или середине 2026 года можно будет практически забыть про политики от PolicyEngine Kyverno и OPA Gatekeeper! Про кастомные реализации политик, даже говорить не будем — это странная дичь, которая уже и сегодня смотрится очень странно и является просто гигантским vendor lock.

И так почему же будет именно так и именно тогда:
0) PolicyEngine Kyverno и OPA Gatekeeper уже завозят к себе поддержку Validating Admission Policy
1) Validating Admission Policy уже в stable с 1.30
2) Mutating Admission Policy в beta с 1.34 (фичи из beta переходят в stable в 99%), и в alpha с 1.30
3) Минимальная поддерживаемая версия Kubernetes сообществом на текущий момент уже 1.31, тоесть Validating Admission Policy уже присутствует если вы вовремя обновляетесь
4) Облачные провайдеры, предоставляющие Managed Kubernetes уже потихоньку выводят из оборота 1.30, но там как мы знаем уже есть Validating Admission Policy
5) Также общение с разработчиками отечественных платформ на базе Kubernetes показало, что где-то в начале следующего года их все сертифицированные версии уже будут как минимум старше 1.30 (а не сертифицированные версии перешагнут эту версию еще раньше)
6) Validating Admission Policy очень круто с интегрированы с Kubernetes Audit Log! Об этом расскажем на одном из следующих наших вебинаров

Поэтому чтобы не делать одну работу дважды - начинайте смотреть в эту сторону ;)

P.S. Почему практически, а не полностью?! Пока еще есть ряд сценариев, которые они выполнить не могут ;)

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

Начнем эту неделю со статьи "Using the Kyverno Admission Controller to Enforce Minimal Base Images".

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

Это достигается, тем что:
1) При сборке образа можно установить соответствующее значение аннотации org.opencontainers.image.base.name
2) При проверке в политике можно извлечь эту аннотацию и сравнить с перечнем разрешенных значений

P.S. Напоминаем, что уже завтра в 11:00 состоится вебинар "БЕЗОПАСНОСТЬ КОНТЕЙНЕРОВ И KUBERNETES для DevSecOps специалистов"

Сегодня вернемся к теме одного из наших прошлых постов про, то как Validating Admission Policy (VAP) летит на смену Policy Engine в лице самых популярных решений (можно сказать стандартов де-факто индустрии) Kyverno и OPA Gatekeeper.

НО как мы писали тогда есть еще ряд сценариев, который VAP не способен закрыть (естественно рассматриваем только область валидации, не мутации и не генерация).

И так, это сценарии, завязанные на информацию, находящуюся за пределами YAML, который сейчас попадает на валидацию в Kubernetes API Server. Напомним, что VAP прямо встроен в Kubernetes API Server и никаких webhook не использует для своей работы. Таким образом сразу можно подсветить 4 сценария:
1) Проверка подписи образа — это отдельный файл в registry (или другой системе)
2) Проверка какой-либо аттестации — это отдельный файл в registry (или другой системе)
3) Проверка на базе обращения в другую систему/ресурс — это информация во внешней системе
4) Background сканирование — это YAMLs, которые уже находятся в etcd

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

P.S. В комментариях можете еще накидать ограничений с которыми вы уже столкнулись.

Если у вас в голове периодически мелькает мысль написать свой безопасный, надежный, масштабируемый registry с обилием своих крутых фич, то не надо делать ничего с 0! Уже есть для этого целая база!

Проект Distribution от CNCF как раз для этого и существует. Он в очень простой манере в соответствии с OCI Distribution Specification реализует:
- pack
- ship
- store
- deliver

По сути это основная либа для: Docker Hub, GitHub Container Registry, GitLab Container Registry, DigitalOcean Container Registry, CNCF Harbor Project и VMware Harbor Registry.

WIZ, AWS, Google Cloud и Microsoft объединились чтобы создать Zeroday Cloud – некий аналог Pwn2Own в рамках Cloud Native окружения.

У исследователей есть 60 дней чтобы найти и зарепортить уязвимости. Организаторы ждут от ресерчеров прежде всего High и Critical уязвимости с возможностью чтения файлов хоста или выполнения произвольного кода на хосте.

Результаты будут представлены в лайве на Black Hat Europe 10-11 декабря. Призовой фонд составляет 4.5 миллиона долларов. Выплаты в этом ивенте существенно выше, по сравнению с существующим расценками в багбаунти для этих продуктов.

В скоуп попали:

- Kubernetes
- Docker
- Containerd
- Grafana
- GitLab CE
- NVIDIA Container Toolkit
- PostgreSQL

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

P.S – наверняка конец 4-ого квартала принесет нам кучу 0-day.

С 2022 года мы на канале периодически пишем и рассказываем про разработку новых сетевых политик: AdminNetworkPolicy и BaselineAdminNetworkPolicy (1,2,3,4).

Подробнее о них можно узнать с сайта Network Policy API Working Group. При этом судя по записям митингов этой рабочей группы (кто-нибудь кроме нас это смотрит?) есть намеки что они презентуют выход этого API в статус beta в рамках KubeCon + CloudNativeCon North America 2025 10-13 ноября в Атланте.

Что касается не спецификации, а реализации, то сейчас ситуация следующая:

В Calico:
- AdminNetworkPolicy с верcии 3.29
- BaselineAdminNetworkPolicy с версии 3.30

В Antrea:
- AdminNetworkPolicy с верcии 1.13
- BaselineAdminNetworkPolicy с версии 1.13

В Cilium пока безрезультатно - обсуждение идет тут.

В одном из недавних постов на канале мы подсвечивали, то как Validating Admission Policy (VAP) летит на смену Policy Engine в лице самых популярных решений. Сегодня хотим продолжить эту тему статьей "Kyverno vs Kubernetes Policies: How Kyverno Complements and Completes Kubernetes Policy Types".

В статье автор приводит реально отсутствующий важный функционал VAP, но который присутствует в Kyverno – начиная от сканирования background ресурсов и заканчивая использованием Kyverno не только в Kubernetes, а вообще для любых объектов/ресурсов/файлов.

На данный момент можно сказать, что лучший подход –не выбор между Kyverno и VAP, а их совместное использование.

Совсем недавно нам на глаза попался любопытный проект (пускай даже и не особо развивающийся) под названием x11docker.

Данный проект призван решить любопытную задача - безопасный запуск GUI приложений в Docker и Podman контейнерах.

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

А как мы и говорили уже неоднократно так или иначе контейнеры придут на защиту не только серверных приложений, но и пользовательских (1,2).

Мировое сообщество Kubernetes Security обращается ко всем, кто интересуется безопасностью Kubernetes. Всё дело в том, что планируется обновить OWASP Kubernetes Top 10 в ближайшее время и сейчас они проводят опрос для сбора идей и отзывов.

В опроснике есть два новых пункта, которых нет в текущей версии:

1) Overly exposed Kubernetes Components - This looks at the risks of having Kubernetes components directly attached to the Internet, where they could be attacked.

2) Cluster-to-Cloud Lateral Movement - The risk that attackers might be able to leverage Kubernetes cluster access to expand to other cloud systems.

Опрос включает в себя ряд вариантов, которые могут быть включены в OWASP Kubernetes Top 10, и идея заключается в том, чтобы оценить их от 1 (не должно быть в Top 10) до 5 (обязательно должно быть в Top 10).

С момента, когда мы рассказывали о Security Profiles Operator в прошлый раз, прошло уже довольно много времени и в нём много что изменилось.

Так в последней версии 0.10.0 была добавлена JSON audit logging feature, позволяющая полностью отслеживать происходящее внутри контейнеров. Конечно же всё с помощью eBPF. Всё пишется в отдельный лог файл, где каждая строка содержит информацию о событии: временную метку, имя исполняемого файла, аргументы командной строки, идентификаторы пользователя и группы, а также системные вызовы.

Более подробно с новой фичей можно ознакомиться прочитав статью Auditing user activity in pods and nodes with the Security-Profiles-Operator.

Сегодня хотим рассказать про проект kps-zeroexposure – некую безопасную настройку вокруг kube-prometheus-stack. Сами авторы так объясняют зачем этот проект:

- Targets for etcd, scheduler, controller-manager, and kube-proxy are DOWN.
- The corresponding Kubernetes Services have ClusterIP: None or do not exist.
- Metrics are not reachable unless insecure flags or hostNetwork hacks are used.
- Changing the Kubernetes static pod manifests to bind to 0.0.0.0 is discouraged.

В этом году возвращается легендарная ZeroNights!

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

P.S. Ваш покорный слуга стоял у истоков данной конференции и занимался ей 10 лет и с трепетом ждем возвращения)

P.S.S. Забавный факт - в далеком 2021 наша команда Luntry выступала на ZeroNights (это последняя конфа на текущий момент) с темой "Container escapes: Kubernetes edition" и можно сказать, что практически с нее начался наш публичный путь выступлений на тему безопасности контейнеров!

Сегодня хотим поделиться IAMhounddog — инструмент для визуализации связей IAM-ролей, политик и ресурсов в AWS. Он помогает выявлять «вторичные» пути эскалации привилегий, когда низкопривилегированный аккаунт цепочками операций получает доступ к административным ресурсам.

Инструмент экспортирует данные в формат, совместимый с BloodHound, что упрощает анализ attack path. Для работы требуется минимум прав — например, роль типа SecurityAudit или ReadOnlyAccess.

Очень крутые ребята позвали нас поучаствовать в создании образовательного курса "Linux Incident Response & Security", который представляет из себя практический курс по выявлению, анализу и реагированию на киберугрозы в GNU/Linux-системах.

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

Для нас этот опыт новый, но точно можем сказать не последний ;)
Сейчас мы много работаем над различными проектами в обучающей сфере.

В конце сентября вышла обновленная версия CIS Kubernetes Benchmark – 1.12. В документе представлены нормативные рекомендации по созданию безопасной конфигурации для Kubernetes версий 1.32 – 1.34.

Если сравнивать с предыдущей версией бенчмарка, то изменений не так много. А именно – в проверках, связанных с использованием стойких криптографических примитивах, в Control и Data Plane компонентах, были убран ряд некриптостойких шифров.

В остальном, это такой же CIS Kubernetes Benchmark, как и в предыдущих версиях. Ждать чего-то нового можно будет, только если это "новое" завезут в Kubernetes.