Сегодня мы вам рекомендуем ознакомиться со статьей "Hot-Patching Pods in Kubernetes 1.33: What Breaks, What Works, and How We’re Making It Usable".

Как несложно догадаться материал посвящён InPlacePodVerticalScaling feature gate, о которой мы писали еще в рамках "KEP-1287: In-place Update of Pod Resources" в 2022 году, и которая появилась в статусе alpha в версии 1.27. А в 1.33 уже включенной по умолчанию. Также стоит в рамках этого ознакомиться со статьей из официального блога "Kubernetes v1.33: In-Place Pod Resize Graduated to Beta".

Из статьи вы узнаете:
- Без заранее установленных requests и limits у вас ничего не выйдет
- Создание патча не гарантирует его применение - проверяйте .status.containers[].resources
- Стоит не забывать про добавление resources.resizePolicy
- В RBAC нужно право PATCH на /resize subresource
- Где можно получить с новой фичи преимущества
- Как это все живет с HPA и VPA

Всем, привет!

30 сентября в 11:00 наша команда Luntry проведет вебинар «Безопасность контейнеров и Kubernetes для DevSecOps специалистов».

Это продолжение серии вебинаров о безопасности контейнеров и Kubernetes для:
- CISO
- Cпециалистов SOC
- Cпециалистов анализа качества

Здесь мы как обычно рассмотрим основные задачи и проблематику для специалистов данного направления. Посмотрим OpenSource и его возможности. На пример, поговорим почему Trivy и решения на его базе, не лучший выбор для системного подхода к безопасности в рамках компании. И, конечно, представим наше виденье на правильный подход к организации безопасности образов и покажем нашу новую фичу Image Security Gate.

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

P.S. Для каких категорий специалистов вы бы еще хотели послушать подобные вебинары?

Если хотели узнать подробнее про Clilum Host Network Policy, то статья Securing the Node: A Primer on Cilium’s Host Firewall как раз для вас.

Мы привыкли к тому, что Network Policy в Kubernetes защищают только Pods, а трафик самой Node остается без контроля. Cilium решает эту проблему с помощью Host Firewall — механизма на базе eBPF, который расширяет сетевые политики до уровня хоста.

Из статьи вы узнаете:

- Почему Node — «слепое пятно» в безопасности Kubernetes
- Как работает Host Firewall и label reserved:host
- Зачем нужен Audit Mode перед включением строгих правил
- Как применять политики через CiliumClusterwideNetworkPolicy
- Чем это помогает в защите SSH, kubelet и API-сервера

На недавно прошедшей конференции Container Plumbing Days 2025 в Амсетрдаме был представлен доклад "Skiff - OCI image analysis utility".

Skiff это анализатор OCI образов.

Основное назначение :
- Image Optimization - выявление больших файлов и ненужных слоев для уменьшения размера образа
- Layer Debugging - понимание того, какой вклад каждый слой вносит в конечный образ

В нем на сегодняшний день есть несколько команд:
- skiff layers - выводит размер каждого слоя в образе (не в сжатом виде по diff ID)
- skiff top - выводит список файлов по размеру
- skiff diff - позволяет сравнивать две версии образа контейнера
- skiff mount - позволяет исследовать файловую систему образа контейнера без необходимости локальной его распаковки (work in progress)
- skiff sunburst (TBD) - для визуализации образа контейнера и его содержимого (work in progress)

В общем, помощник когда вам docker history или inspect недостаточно.

Сегодня рекомендуем ознакомиться со статьей «Kubernetes v1.34: Use An Init Container To Define App Environment Variables».

В ней представлена новая фича EnvFiles, которая позволяет задавать переменные окружения через файл, сформированный в initContainer. Такой файл сохраняется в emptyDir, доступном только во время инициализации, а основной контейнер затем просто читает переменные через fileKeyRef, не требуя монтирования всего тома.

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

CK-X Simulator - web-based симулятор экзаменов для Kubernetes. Инструмент спокойно разворачивается на локальной системе и позволяет пройти экзамены по: CKAD, CKA, CKS. При этом есть подсказки, контроль времени, автоматическая проверка результатов.

Сегодня в 11:45 на конференции DevOops 2025 наша команда в лице Сергея Канибора представит доклад "Аудит безопасности Kubernetes-кластера без Kubernetes-кластера".

В рамках доклада раскроем, что далеко не многие знают, как ломать Kubernetes, а тем более — как ломать Kubernetes, когда его и вовсе еще не существует. Поделимся опытом проведения аудитов кластеров еще на стадии их проектирования, когда на руках есть только Cluster API-манифесты будущих Kubernetes. Расскажем, какие типы недостатков можно обнаружить на этой стадии, а какие нет. Разбавим все это интересными моментами и автоматизацией процесса.

CVE-2025-9708 в Kubernetes клиенте на C#!

Сама уязвимость заключается в неправильной проверке сертификата в кастомном CA режиме, которая может привести к атакам типа MitM (Man-in-the-Middle).

Уязвимость получила средний уровень критичности - 6.8 и CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N.

Проблеме подвержены все версии до 17.0.13.

P.S. Есть кто C# с кубами использует?

P.S.S. Хотя проектов на PowrShell мы уже с вами насмотрелись за последнее время.

В статье 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, а их совместное использование.