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

В статье 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.