Недавно задумывался, что меня больше всего удручает в вопросах безопасности 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.

На нашем сайте в разделе Исследований стали доступны видео и слайды выступления "Ретроспектива уязвимостей Kubernetes" с конференции Kubernetes Community Day.

В докладе мы рассмотрели следующие темы:

- K8s CVE feed, как он появился, как наполняется и как выглядит;
- Скоуп, какие таргеты в него входят и что может появится в итоговом фиде. Багбаунти программа Кубера и её особенности;
- Статистика по всем CVE за все время – колчество CVE по годам, по компонентам и распределение уязвимостей по критичности;
- Unpatchable уязвимости в Kubernetes.

Проект Blixt — это Kubernetes-балансировщик 4 уровня (и мог быть хорош!), использующий kube-rs в Control Plane и eBPF с aya для Data Plane. Сегодня репозиторий архивирован и больше не развивается — он остаётся скорее экспериментальной площадкой.

Несмотря на закрытие, в нём можно найти интересные идеи и наработки по интеграции eBPF в Kubernetes. Он был первым официальным проектом Kubernetes на Rust, хотя проекты такого рода не получили широкого распространения.

Если вам интересны эксперименты с eBPF и архитектура сетей в Kubernetes — стоит заглянуть в код.

Видео докладов с конференции DEF CON 33 Cloud Village стали доступны, с ними можно ознакомиться в трех плейлистах – день первый, второй и третий.

Cloud Security:

Auths Gone Wild: When ‘Authenticated’ Means Anyone
- Wiz’s Danielle A. & Yaara Shriki

No IP, No Problem: Exfiltrating Data Behind Google’s Identity Aware Proxy
- Mitiga’s Ariel Kalman

Building the Cross-Cloud Kill Chain: A DE's Playbook for AWS, Azure & GCP Detections
- Meta’s Gowthamaraj Rajendran

whoAMI: Discovering and exploiting a large-scale AMI name confusion attack
- Datadog’s Seth Art

Weaponizing SSM: Practical Exploits and Hardening Techniques for AWS
- Clavis Security’s Rodrigo Montoro

Kubernetes:

Command and KubeCTL: Kubernetes Security for Pentesters and Defenders
- Chainguard’s Mark Manning

Spotter - Universal Kubernetes Security Engine
- Madhu Akula

Quickstart for a Breach! When Official Installations Expose Your K8 and Your Cloud
- Microsoft’s Michael Katchinskiy & Yossi Weizman

Don't trust Rufus, he's a mole - introducing KIEMPossible
- Palo Alto Networks Alto’s Golan Myers

В статье Enterprise Secret Management in MLOps: Kubernetes Security at Scale показано, как в MLOps на Kubernetes организовать безопасное управление секретами: использовать Sealed Secrets для шифрования, централизовать генерацию и ротацию секретов инфраструктурной командой и обеспечить автономность приложений через стандарты.

Основная идея: не плодить секреты для каждой службы, а поддерживать консолидированный секрет “ml-platform” с единым именованием для всех сред. Это позволяет хранить зашифрованные секреты в Git без риска, автоматизировать их доставку и избежать узких мест.