Знакомясь с платформой контейнеризации Alauda Container Platform, наткнулись в её документации на раздел Security and Compliance, где есть замечательно оформленные по разделам политики безопасности для Kyverno. Для тех кто только начинает может быть хорошим стартом!

Продолжаем рассказывать про интересные доклады с Black Hat USA 2025. Сегодня затронем доклад Breaking Out of The AI Cage Pwning AI Providers with NVIDIA Vulnerabilities от Andres Riancho, Hillai Ben-Sasson и Ronen Shustin из WIZ.

Это доклад от исследователей, которые нашли CVE-2024-0132. В докладе они объясняют суть баги, показывают эксплойт, а затем приводят примеры инструментов и облачных провайдеров, которые были уязвимы к побегу из контейнера с помощью этой CVE.

Видео еще недоступно, но слайды можно посмотреть тут.

P.S – для тех кто еще не видел, вот тут можно прочитать наш разбор CVE-2024-0132.

В последней версии Docker Desktop под номером 4.44.3 была закрытая критическая уязвимость CVE-2025-9074, которая приводит к побегу из контейнера в Windows и Mac через SSRF! Linux версия не под угрозой =)

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

Уязвимость не затрагивает версию Linux, поскольку там используются именованные канала, а не TCP-сокет для взаимодействия с API Docker Engine.

Полные детали баги, POC и видео эксплуатации от авторов можно посмотреть тут.

Если вы используете образы от Bitnami – спешим сообщить, что у вас проблемы. Дело в том, что они решили перейти от свободно доступных образов bitnami к разделению на коммерчески поддерживаемые образы bitnamisecure и неподдерживаемые устаревшие образы bitnamilegacy.

Точные сроки неясны, поскольку в issue упоминается постепенное перемещение в legacy репозиторий, однако последствия начнут проявляться начиная с 28 августа 2025 года, поэтому очевидно, что компаниям, использующим эти образы, придется принять меры как можно быстрее.

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

SIG Multicluster (github, group) запустила опрос "User feedback Survey: Building Multi cluster Management and Monitoring tool" среди пользователей с опытом работы с мультикластерными системами для получения обратной связи для разработки инструментов управления и мониторинга мультикластерами. Если у вас есть желание повлиять на текущие и новые проекты, то сейчас как раз хороший момент. Среди проектов SIG Multicluster можно вспомнить:
- ClusterSet - для группировки кластеров (остальные проекты работают поверх этой абстракции)
- About API - для уникальной идентификации кластеров
- Multicluster Services API - для межкластерной публикации сервисов (об этом писали тут)
- Work API - для деплоя нагрузок на несколько кластеров
- ClusterProfile API - для упрощения обнаружения и управления кластерами

Вышла версия Kubernetes 1.34 под кодовым названием Of Wind & Will (O' WaW). Изменений предостаточно, но с точки зрения security мы бы хотели отметить несколько:

1) Built‑in Mutual TLS for Pods (Alpha). Pod теперь могут запрашивать краткосрочные сертификаты X.509 у Kubernetes API и использовать их для аутентификации по протоколу mTLS. Мейнтейнеры утверждают, что это обеспечит понятный и нативный подход к идентификации рабочих нагрузок внутри кластера без использования внешних инструментов или sidecar.

2) Fine‑Grained Anonymous API Endpoint Control (Stable). Вместо отключения анонимного доступа на уровне всего кластера теперь можно настроить его применение только к определённым путям (например, /healthz, /livez и /readyz). Это предотвращает overly permissive anonymous access, сохраняя при этом функциональность мониторинга и load balancers.

3) Short-Lived Pod-Scoped Tokens for ImagePull (Beta). Kubernetes теперь может использовать краткосрочные токены, автоматически генерируемые для каждого Pod, для доступа к private registry. Эти токены соответствуют требованиям OIDC и автоматически сменяются системой.

Со всеми обновлениями можно познакомиться прочитав заметку в официальном блоге Kubernetes.

То, что Gateway API заменит Ingress, это всего лишь вопрос времени. Не просто так же разрабатывали этого преемника)

И старые проекты также нужно будет мигрировать для получения всех преимуществ новой реализации. И тут поможет статья "How to easily migrate ingress to gateway API in Kubernetes" и код, упрощающий весь этот процесс.

В комментариях к посту можете рассказать запускаете ли вы уже новые проекты на Gateway API и переводите ли старые на него + какую реализацию выбрали для себя.

В Kubernetes есть проблема: встроенные Secret хранятся в etcd без надёжного шифрования и требуют особой осторожности при использовании.

Есть готовые популярные решения, вроде Vault, но автор статьи SecretForge — A Sidecar for Kubernetes Secrets решил пойти дальше и предлагает инструмент SecretForge — сайдкар, который сам преобразует секреты в удобный формат (.env или JSON) и обновляет их при изменениях. Это избавляет приложение от лишней логики и делает работу с секретами проще и безопаснее.

В статье есть также пример деплоя с использованием CSI Driver и SecretForge в одном Pod.

Наша команда Luntry совсем недавно выпустила собственную "КАРТУ БЕЗОПАСНОСТИ ДЛЯ КОНТЕЙНЕРНЫХ СРЕД"!

Она базируется на основе NIST SP 800-190, текущих реалиях Kubernetes и нашего многолетнего опыта.

На самом деле это логическое продолжении работы, что была представлена в докладе "Стандарт безопасности контейнеров NIST 800-190 в 2025 году" с конференции Deckhouse Conf 2025. Так что эту карту можно смотреть в связке с данным докладом. Конечно, есть определенные улучшения и доработки с того времени, но большая часть материала очень сильно пересекается.

Также эта карта лежит в основе нашей карточной игры, которая сейчас после пилота проходит корректировку механик и баланса...

P.S. Попозже карта будет доступна и в виде физического плаката формата A2 и получить ее можно где-нибудь у нас на стенде ;)

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

В Kubernetes v1.34 появилась бета-фича — файл .kuberc, который позволяет персонализировать kubectl. Можно задавать дефолтные параметры (например, чтобы kubectl apply всегда работал в server-side режиме или delete спрашивал подтверждение).

Более того — можно заводить алиасы: вместо длинной команды kubectl get pods -o wide --watch просто писать kubectl pods.
По сути, это как .bashrc, только для kubectl: те же дефолты и алиасы, но встроенные прямо в инструмент. Файл ищется в ~/.kube/kuberc, но путь можно переопределить.

Более подробно об этой фиче в можно почитать в заметке из официального блога Kubernetes тут.

KubernetesEnumerationTool это инструмент на PowerShell для анализа Kubernetes кластеров на различные проверки:

- Namespace Actions - позволяет получать пространства имен, в которых вы можете выполнять определенные действия
- Secrets Discovery - позволяет получать доступ к секретам Kubernetes в различных пространствах имен
- Release Information - позволяет определять информацию о релизах
- Image Updates - позволяет идентифицировать наличие более новых образов
- Node Exploitation - позволяет попадать на хост и получать с него информацию (фокусируется на Azure)
- Network Policy Check - позволяет проверять настройки сетевой политики Kubernetes
- Best Practice Validation - позволяет обеспечивать соблюдение подами лучших практик
- DoS Testing - позволяет проводить тест отказа в обслуживании Kubernetes

P.S. Есть идеи почему последнее время все больше инструментов для K8s появляется на PowerShell ? Хотя в будущих планах есть пункт "Rewriting in Go to enhance performance." =)

Очередная critical уязвимость с оценкой 10/10 по CVSS в Argo CD – Argo CD's Project API Token Exposes Repository Credentials.

Атакующий воспользовавшись токеном с доступами на проект, может узнать критичные данные, такие как креды для подключения к репозиториям. Для этого ему нужен токен с такими правами на проект:

p, proj:myProject:project-automation-role, applications, sync, myProject/*, allow
p, proj:myProject:project-automation-role, applications, action/argoproj.io/Rollout/*, myProject/*, allow
p, proj:myProject:project-automation-role, applications, get, myProject/*, allow

И один запрос в API:

curl -sH "Authorization: Bearer $ARGOCD_API_TOKEN" \
  "https://argocd.example.com/api/v1/projects/myProject/detailed"

Исправления доступны для версий Argo CD – 2.13.9, 2.14.16, 3.0.14, 3.1.2.

Самое время пропатчиться и проверить не закешировался ли где то токен - по дефолту его можно найти в ~/.config/argocd/config.

Сегодня мы вам рекомендуем ознакомиться со статьей "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 мы уже с вами насмотрелись за последнее время.