tgindex

k8s (in)security

описание

Канал о (не)безопасности Kubernetes + микросервисных, контейнеризированных приложений. Ведет команда www.luntry.ru #ZST99 Вопросы, идеи, предложения => @Qu3b3c https://knd.gov.ru/license?id=673ddbc21039886b1d03b7ce&registryType=bloggersPermission

← к каналу@k8security
12 976
подписчиков
Охват к подписчикам
27,4%
ERR
Реакции к просмотрам
0,62%
472 на 22 постов
Пересылки к просмотрам
1,48%
1 130
Постов в день
0,7
всего 24

Где отзываются чаще

доля реакций к просмотрам
  • 07:00На конференции Black Hat USA 2026 вышел доклад Beyond Seccomp: Breaking and Rebuilding Syscall Filtering for Microservices о том, где современные механизмы фильтрации syscall'ов дают слабину. Авторы выделяют три проблемы: stateless-фильтрация Seccomp не учитывает последовательность вызовов, eBPF-энфорсмент может реагировать слишком поздно, а загрузка политик через Kubernetes Operator создаёт окно между стартом контейнера и применением защиты. Особенно интересно, что авторы не просто показывают атаки, а предлагают архитектуру следующего поколения: stateful-фильтрацию через eBPF, inline-блокировку через LSM-BPF и атомарную установку политик до запуска контейнера. В результате получается защита, которая учитывает контекст syscall'ов и не оставляет временных окон для обхода. Слайды доклада уже доступны по ссылке. И да, этот доклад очень сильно пересекается с нашим секретным докладом с БеКон 2026 — но кто знает, тот знает.1,08%
  • 6 авг.🔝 Вспоминаем, как это было на БеКон 2026! 🔥 Конференция осталась позади, но самый сок теперь доступен онлайн. Все доклады, драйв, инсайты и презентации от топ-экспертов рынка (Luntry, Т-Банк, Альфа-Банк, Ozon, АСТРА и др.) уже ждут вас на сайте. Пересматривайте лучшие моменты, скачивайте слайды и внедряйте лучшие практики в своих проектах. 👇 Забирайте материалы прямо сейчас: 📺 Записи докладов тут 📂 Презентации тут Ставьте ❤️ и делитесь постом с коллегами, которым это будет полезно! 🚀1,08%
  • 17 авг.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 внутри кластера.1,00%
  • 27 июл.В CRI-O обнаружили новую уязвимость CVE-2026-15809, которая оказалась обходом исправления четырехлетней давности для CVE-2022-4318. Из-за ошибки в реализации защита никогда не работала так, как предполагалось: код искал строку `\n` вместо реального символа перевода строки. Злоумышленник, способный задать переменные окружения контейнера, может внедрить перевод строки в переменную HOME и тем самым добавить произвольные записи в /etc/passwd. Это открывает путь к повышению привилегий внутри контейнера и показывает, насколько опасными могут быть ошибки в механизмах, отвечающих за создание контейнеров. Особенно примечательно, что проблема существовала с декабря 2022 года, несмотря на наличие официального исправления.0,86%
  • 5 авг.В известном решении по безопасности 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 в очередной раз стоит читать как «почти привилегированный под» =)0,82%
  • 10 авг.Очередная LPE уязвимость в Linux — SCTPhantom (CVE-2026-64564), связанная с use-after-free в реализации SCTP. Проблема появилась ещё в ядрах 2.6.25 и связана с некорректной обработкой ASCONF-сообщений, которая приводит к повторному использованию уже освобождённого sctp_transport. Самое интересное здесь — возможность превратить уязвимость в container escape. Исследователям удалось построить цепочку эксплуатации, которая позволяет процессу из контейнера повысить привилегии через ядро и выйти за пределы контейнерной изоляции, получив контроль над хостом. Для Kubernetes это особенно неприятный сценарий: контейнерная изоляция в конечном итоге опирается на ядро хоста, и kernel-level UAF способен превратить компрометацию контейнера в компрометацию всей ноды. Исправление уже отправлено upstream.0,75%
  • 12 авг.В официальном блоге Kubernetes вышел пост с обзором основных изменений, которые войдут в Kubernetes 1.37. Если смотреть исключительно на security часть релиза, то есть несколько интересных нововведений. Во-первых, статические Pod'ы больше не смогут ссылаться на Secrets и ConfigMaps — в Kubernetes исправили баг, который позволял им получать доступ к API-ресурсам. Также SELinuxMount включат по умолчанию для поддерживаемых CSI-драйверов, что ускоряет работу с томами, но может привести к проблемам у приложений, которые совместно используют один volume с разными SELinux-контекстами. kubelet в user namespace переходит в Beta. Это позволяет запускать kubelet без root-привилегий на хосте, сохраняя root только внутри namespace, и тем самым уменьшает потенциальный impact от компрометации kubelet.0,74%
  • 7 авг.Работа с 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 стоит раздавать так же скупо, как и в кластер ;)0,74%
  • 6 авг.User Namespaces — одна из самых значимых функций безопасности Kubernetes последних лет, но её работа гораздо сложнее, чем может показаться на первый взгляд. В статье User Namespaces in Kubernetes, Part III: The Implementation подробно разбирается, как kubelet, CRI и OCI Runtime совместно создают отдельные user namespace для каждого Pod и управляют UID/GID. Автор также объясняет, как Kubernetes резервирует диапазоны идентификаторов, хранит их состояние и предотвращает конфликты между Pod'ами. Отдельное внимание уделено интеграции с idmapped mounts, благодаря которой User Namespaces работают с томами без изменения владельцев файлов. Это отличный материал для тех, кто хочет разобраться не только в использовании User Namespaces, но и понять, какие изменения потребовались внутри Kubernetes для реализации этой функции и почему она так долго находилась в разработке.0,74%
  • 11 авг.Недавно прошла конференция KubeCon + CloudNativeCon Japan 2026 (расписание со слайдами, видеозаписи) и мы выделили с нее следующие доклады связанные с безопасностью: - Vulnerability Response for Large Open Source Projects - Sandbox for Agentic Application With Cloud Native Stack - Identities and Authentication for Your Agents With Keycloak - User Namespaces in Production: Enabling Root in Containers With RWX - Detecting Compromised CI With eBPF and Cilium Tetragon - Kairos: Immutable OS and Lifecycle Management for Kubernetes Fleets - Lima in 5 Minutes: From Containers To AI Sandboxing - SBOMit: Making SBOMs Accurate With Attestations - Scalable Security and Compliance in the Age of AI - Runtime Security at Scale With EBPF: Hybrid Detection and Root Cause Analysis in CloudNative Systems - Container Forensics for Kubernetes: Building an Evidence Pipeline With Open Source Tools - AuthZEN in Practice: Standardizing Authorization for Cloud Native Platforms and Agents - Behind the CNCF IAM Whitepaper: AuthN & AuthZ in Cloud Native Systems0,72%
  • 23 июл.3 года назад мы уже писали про бесплатную open-source платформу, которая помогает готовится к экзаменам CKA, CKAD и CKS или просто освоить Kubernetes. И есть отличная новость - проект живой и развивается. На пример, его команда недавно добавила курс по Istio и лабы к нему! Это будет максимально полезно если готовитесь (или просто смотрите в сторону) к Istio Certified Associate (ICA).0,69%
  • 13 авг.Когда говорят про sandbox в Linux, обычно вспоминают gVisor, Kata Containers или seccomp-профили. А есть куда более скромный инструмент, который при этом крутится на миллионах десктопов, — bubblewrap. Это тот самый движок песочницы, на котором работает Flatpak, и живёт он в организации containers рядом с Podman и Buildah. Ключевая идея: это container tool для непривилегированного пользователя — никакого демона и root, всё на unprivileged user namespaces. Что даёт: - mount namespace с пустым tmpfs в качестве /, куда руками пробрасываются только нужные куски ФС - user/IPC/PID/network/UTS namespaces - seccomp-фильтры - монтирование ro и nodev по умолчанию - PR_SET_NO_NEW_PRIVS, отрубающий эскалацию через setuid-бинари Но самое интересное — то, что честно написано в README: сам по себе bubblewrap не даёт ничего, уровень защиты полностью определяется аргументами, которые ему передал вызывающий. Пробросили внутрь сокет D-Bus — и песочницы фактически нет. Ничего не напоминает? Ровно та же история, что и с SecurityContext в Kubernetes: примитивы ядра у всех одни и те же, а итоговая защищённость зависит от того, кто и как их сконфигурировал. И показательный момент напоследок: оба CVE за всю историю проекта — и CVE-2020-5291, и свежий CVE-2026-41163 — про один и тот же setuid-режим, который нужен ровно там, где unprivileged user namespaces в ядре запрещены. В версии 0.11.2 завезли опцию сборки вообще без setuid и объявили, что дальше поддержку уберут совсем. Тренд читается однозначно: ставка делается на unprivileged user namespaces как на базовый примитив изоляции.0,68%