k8s (in)security

Идея «сгенерируй мне least-privilege конфиг по тому, что реально делает приложение» стара как seccomp-профили, но каждый год обретает новое воплощение. Свежее — «KubeGuard: LLM-Assisted Kubernetes Hardening via Configuration Files and Runtime Logs Analysis» из Ben-Gurion University: манифесты плюс рантайм-телеметрия скармливаются LLM через цепочки промптов, на выходе рекомендации по Role, NetworkPolicy и Deployment. Источники ровно те, что у вас и так есть (ну или должны быть):
- Kubernetes audit logs — какие verbs реально дергали, отсюда RBAC
- Hubble (Cilium) — реальные потоки трафика, отсюда NetworkPolicy
- SPADE + CLARION — provenance по процессам в контейнерах, отсюда securityContext (штука research-grade, но в проде ее роль ровно так же закроют Tetragon, Falco или Tracee)

Два режима: Resource Creation (собрать с нуля) и Resource Refinement (ужать существующий overly permissive). Кода в открытом доступе нет, зато промпты авторы выложили в приложениях.

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

О реальном использовании в своей инфраструктуре такого проекта как Firecracker на наших просторах мало кто говорит (да и мало кто использует). НО наши хорошие друзья, которые активно занимаются AI и fuzzing, в одном из своих постов рассказали как и зачем (механика snapshot/restore) в общем можно делать свои собственные для этой легковесной VMM.

А если у вас есть опыт использования Firecracker и Kata containers, то делитесь своим опытом в комментариях.

А если вы вообще не знаете что это такое, то рекомендуем ознакомиться с нашим докладом "Кубик Runtime в конструкторе Kubernetes для безопасности" ;)

containerPort в манифесте — это документация, а не контроль. Kubernetes его не проверяет: контейнер может слушать порты, которых в YAML нет, и наоборот. Ровно на этом разрыве между декларацией и реальностью построена работа «Inside Job: Defending Kubernetes Clusters Against Network Misconfigurations».

Они прогнали 287 публичных Helm-чартов от Bitnami, Banzai Cloud, CNCF, Prometheus Community через связку статического анализа YAML и рантайм-наблюдения в живом кластере. Нашли 634 проблемы у 90% приложений:
- 241 — нет никаких NetworkPolicy
- 188 — порт открыт, но не задекларирован (привет, админские и debug-интерфейсы)
- 67 — порт задекларирован, но не открыт: приходит кто-то другой и занимает его
- 35 — контейнер слушает эфемерный порт, который меняется при каждом старте (и никакая политика по портам его не покроет)
- 52 — коллизии лейблов, когда чужой Pod попадает под селектор вашего Service, а трафик уезжает не туда

Список самых грязных чартов бьет по узнаваемости: kube-prometheus-stack, kube-prometheus, clickhouse, istio-operator, grafana-tempo, zookeeper, jaeger, metallb, node-exporter. То есть ровно то, что стоит у половины читателей канала, причем зачастую в системных неймспейсах. У всей десятки лидеров нет NetworkPolicy и есть незадекларированные порты, 9 из 10 сидят в hostNetwork (а на него, напомним, NetworkPolicy и не действует), 4 из 10 слушают эфемерные порты.

Отдельно они сравнили себя с 11 инструментами — Checkov, KubeLinter, kube-score, kubesec, kubeaudit, Kubescape, Trivy, NeuVector, StackRox и т.д. Статические не видят рассинхрон декларации и реальности в принципе, потому что смотрят только в YAML, а рантайм- и платформенные решения его просто не ищут. И самое неприятное: коллизии лейблов сами разработчики оценили как наиболее критичную находку — это готовый MITM внутри кластера.

В официальном блоге Kubernetes вышел пост с обзором основных изменений, которые войдут в Kubernetes 1.37. Если смотреть исключительно на security часть релиза, то есть несколько интересных нововведений.

Во-первых, статические Pod'ы больше не смогут ссылаться на Secrets и ConfigMaps — в Kubernetes исправили баг, который позволял им получать доступ к API-ресурсам. Также SELinuxMount включат по умолчанию для поддерживаемых CSI-драйверов, что ускоряет работу с томами, но может привести к проблемам у приложений, которые совместно используют один volume с разными SELinux-контекстами.

kubelet в user namespace переходит в Beta. Это позволяет запускать kubelet без root-привилегий на хосте, сохраняя root только внутри namespace, и тем самым уменьшает потенциальный impact от компрометации kubelet.

Работа с container registry у многих до сих пор сводится к docker pull / docker push, а значит к запущенному демону, docker.sock в раннере и лишним привилегиям там, где они совсем не нужны.

regclient — это Go-библиотека и три CLI для работы с OCI-совместимыми реестрами без container runtime и без привилегированного доступа к хосту:
- regctl — инспекция, копирование и ретегирование с сохранением digest, работа с OCI Artifacts, referrers и мультиплатформенными индексами, плюс regctl image mod (аннотации, timestamps, смена базового образа и алгоритма digest)
- regsync — зеркалирование по YAML-конфигу: по расписанию, разово или только отчётом об устаревших образах, с поддержкой OCI Layout для переноса через air-gap
- regbot — скриптование политик на Lua: обход репозиториев, удаление лишних тегов и манифестов, с оглядкой на rate limits

Самое интересное здесь — поддержка referrers и digest tags: именно в них живут подписи cosign и аттестации с SBOM. Если тянуть образы во внутренний реестр инструментом, который про них не знает, то образ доедет, а доказательства его происхождения — нет, и вся выстроенная supply chain security тихо превращается в тыкву. И да, regctl image mod с regbot одинаково удобны как для наведения порядка в реестре, так и для того, чтобы незаметно в нём что-то поправить — права на запись в registry стоит раздавать так же скупо, как и в кластер ;)

В известном решении по безопасности Tetragon закрыли «Unauthenticated Tetragon gRPC admin API accessible from hostNetwork pods» - CVE-2026-65960 (CVSS 8.8). Суть простая: агент поднимает свой административный gRPC API по TCP на localhost:54321 и без какой-либо аутентификации. Таким образом любой злоумышленник на Node или Pod с hostNetwork: true живёт в сетевом namespace узла — значит этот localhost и его тоже.

Что из такого пода может атакующий:
- добавлять, удалять и перенастраивать TracingPolicy
- менять debug-настройки
- в целом крутить поведение агента вплоть до container escape и повышения привилегий

Починили в v1.7.0 - уязвимы абсолютно все версии до этой!

Отдельно обратите внимание на механику: атакующему здесь не нужно ничего эксплуатировать в первую очередь — ему нужно выключить наблюдение. Снёс TracingPolicy — и дальше работает вслепую для SOC, который как раз на Tetragon и завязан. Средства защиты сами являются частью attack surface и требуют харденинга не меньше, чем прикладные нагрузки, а hostNetwork: true в очередной раз стоит читать как «почти привилегированный под» =)

Дефолты — это не константа, а свойство конкретной версии. Меняются они между минорными релизами, а иногда и между патчами, так что любой ваш снимок «как оно настроено из коробки» имеет срок годности.

Показательный случай — CVE-2025-46599 в K3s. В ветке 1.32 конфигурацию kubelet перевели с устаревших CLI-флагов на структуру v1beta1.KubeletConfiguration с генерацией YAML drop-in. А у поля ReadOnlyPort в апстримной go-структуре стоит omitempty — и значение 0 просто выпало при маршалинге. kubelet подставил свой дефолт и поднял 10255: неаутентифицированный доступ к /pods со со спецификациями Pod’ов, включая потенциально чувствительные значения в env, аргументах запуска и других полях; в отдельных конфигурациях это могло приводить к раскрытию токенов и credentials. Разбор — в issue #12164, починили только в 1.32.4-rc1+k3s1, то есть проблема присутствовала в нескольких последовательных релизах ветки 1.32.

А теперь самое интересное. Всё это время CIS self-assessment guide в пункте 4.2.4 писал ровно обратное: «By default, K3s sets the --read-only-port to 0». И сама проверка сформулирована так: Expected Result: '--read-only-port' is equal to '0' OR '--read-only-port' is not present. После рефакторинга флага в командной строке kubelet не стало — то есть автоматический аудит по этому пункту честно рапортовал PASS, пока порт слушал. Один и тот же коммит и открыл дыру, и ослепил проверку.

Вывод простой и невесёлый: все всегда стоит перепроверять и подвергать сомнению =)