Неприятная история случилась с Kong Ingress Controller в конце прошлого года – в прод попал образ, содержащий в себе майнер XMRig. Таймлайн происходящего был таков:

1) 28 августа 2024 года разработчики из Kong исправляют свои пайплайны меняя pull_request на pull_request_target
2) 25 ноября 2024 года они получают анонимный отчет от исследователя безопасности о том, что их репозиторий подвержен атаке Pwn request. После этого мейнтейнеры провели ротацию всех секретов в репозитории и вернули триггерное событие обратно на pull_request. Но только для главной ветки. Так что старые неиспользуемые ветки продолжили использовать pull_request_target, а значит были уязвимы.
3) Спустя почти два месяца, а именно 23 декабря 2024 года атакующие начали разведку – они получили доступ к секретам, в том числе к персональному токену доступа GitHub, проэксплуатировав уязвимость в одном из репозиториев.
4) Примерно через 22 часа – 24 декабря злоумышленники перешли на основной репозиторий с полученным на предудыщем шаге access token. Они запушили образ docker.io/kong/kubernetes-ingress-controller на Dockerhub с тегом 3.4.
5) 29 декабря 2024 года 4 пользователя отметили в issue на GitHub, что запуск Kong Ingress Controller приводит к аномально высокой нагрузке на ЦП.
6) 2 января 2025 мейнтейнеры подтвердили, что образ был скомпрометирован, а вунтри него содержался XMRig.

Более подробно о всей ситуации можно почитать в блоге KIC тут. Также было опубликовано YARA правило для обнаружения таких нагрузок.

Замечательная статья "Runtime Security and the Role of eBPF/BPF-LSM", которая достаточно понятно объясняет как работает настоящий prevention (предотвращение) в Linux с помощью eBPF.

В качестве подопытных рассматриваются Falco, Tetragon и KubeArmor - все с разными подходами к реализации. Первые два не дают никакого предотвращения, а только реагирование. Falco из user space отправляет kill сигнал, а tetragon из kernel space отправляет bpf_send_signal(). Это характерно не только им, но и всем реализациям, которые опираются не на Linux Security Modules (LSM). И если вам рассказывают/заявляют обратное, то вам попросту врут.

У нас в Luntry есть функциональность для обнаружения, реагирование со сбором артефактов, предотвращения на базе AppArmor (он опирается на LSM) и уже на подходе собственная реализация предотвращения на базе eBPF-LSM.

Более детально мы сравнивали различные security runtime-решения в вебинаре "Runtime Security: на вкус и цвет все фломастеры разные".

Проект Notary (еще один проект, помимо Cosign, для подписи и верификации артефактов) прошел второй security audit.

Аудиторы из Quarks Lab в своем отчете отразили 11 findings, 2 из которых уже присвоили CVE:

CVE-2024-56138: Time stamp signature generation lacks certificate revocation check
CVE-2024-51491: Process crash during CRL-based revocation check on OS using separate mount point for temp Directory

Краткую выжимку всех находок можно почитать в блоге Quarks Lab тут, а полный отчет в репозитории Notary тут.

13 февраля на ТБ Форуме пройдет доклад Анатолия Карпенко, инженера по автоматизации Luntry, на тему “Основы анализа СЗИ в контейнерном исполнении с помощью Luntry”.

За достаточно небольшой временной интервал мы с вами пройдем путь от полного неведения о попавшем нам в руки для анализа СЗИ в контейнерном исполнении, до полного понимания, что это за средство, как оно устроено и насколько все хорошо у него с безопасностью.

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

Благодаря посту выше мы вышли на статью "The (Anti-)EDR Compendium" и решили сами обдумать действительно насколько это схоже с тем, что можно наблюдать в контейнерном мире, в Kubernetes при работе runtime security решений агентской природы (то, что ставится на Node и мониторит происходящее там).

Основные моменты, которые хотелось бы подсветить:
1) Чем больше детектирующей логики на агенте/сенсоре, тем больше влияние на производительность и вообще возможность обработать большой поток сообщений (упираемся в лимиты и дропы). В контейнерном Мире все ухудшается тем, что там в большинстве своем высоконагруженные приложения и они генерируют большое количество событий, не под стать пользовательской машине. На пример мы встречали кейсы, где порождалось по 100тыщ процессов в секунду (и это явно не предел, а с сетевыми может быть и еще хуже ситуация)! И чем больше там правил, тем больше времени и ресурсов надо чтобы это разобрать.

2) Сложные анализы на агенте/сенсоре — это всегда большие оверхеды. В разделе "Performance Impact" рассматривается ситуация сканирование памяти и файлом антивирусным движком. Как я думаю вы уже догадались это дорого! И это очень плохо влияет на систему контейнеризации (привет overlayfs) и об этом и говорит документация docker. Иначе это приведет к сбоям в работе контейнерных приложений.

Есть еще много общего и это мы рассматривали в вебинаре "Runtime Security: на вкус и цвет все фломастеры разные".

Напоминаем, что идет прием заявок на доклады на конференцию БеКон 2025!

Если мы на предыдущие конференции только приглашали докладчиков из наших клиентов, друзей и партнеров, на конкретные темы, то сейчас появляется возможность предложить свою тему самостоятельно ;)

Требования к заявке:
- Продолжительность доклада — не более 25 минут
- Тема по безопасности контейнеров и Kubernetes
- Выступление рассчитано на технических специалистов
- Доклад актуален и основан на личном опыте
- Доклад ранее нигде не был представлен
- Доклад глубоко раскрывает тему и имеет практическое применение

Заявки принимаются до 31 марта! Сама конференция будет в начале июня.

Занимательный материал "Migrating from Istio to Linkerd". Ранее подобного не встречал, а при этом последние наверное полгода - год вопросы про Linkerd от друзей и клиентов мы получаем. Так что эта статья будет как раз в тему. При этом там и про механизмы безопасности не забыли в разделе "Migrating authorization policy".

А как у вас отношение к Linkerd?)

Вышла очередная статья из цикла Kubernetes security fundamentals от Rory McCune, на этот раз про Networking.

В начале автор рассказывает про так называемые Network trust zones, а потом представляет CNI, сетевые политики и способы управления ими.

В конце, автор приводит манифест для поднятия демо-стенда.

В одном из своих прошлых постов мы уже упоминали доклад "Commencement into Real Kubernetes Security" от Jay Beale и Mark Manning с конференции ShmooCon 2025 и там делали акцент на релизе инструмента Seccomp-Diff. А сегодня хочется сделать акцент на самом докладе, потому что он просто великолепный и мысли авторов во многих моментах совпадают с нашими (которые мы рассказываем в наших выступлениях). Приятно что у мировых звезд индустрии такой же взгляд ;)

И так:
- Видео выступления
- Слайды выступления
- Демо из выступления (Взлом CIS соответствующего кластера без CVE - для многих это идеал)

И в шапке поста несколько шедевральных слайдов, там таких много, поэтому презентация MUST SEE! На самом деле прям хочется сделать отдельный стрим с разбором данной преза - настолько там много всего хорошего)

Инженеры из Cilium опубликовали книгу Kubernetes Network Policies Done the Right Way.

Из этой книги вы узнаете:

- Что такое NetworkPolicy, какова их роль в обеспечении безопасности workloads, и как преодолеть проблемы с их внедрением
- Про разные подходы к использованию сетевых политик, управление ими, и их конфигурацию
- Про принятие принципа Zero Trust, использование Hubble для повышение observability

Экземпляр книги прикладываем во вложении к посту.

В блоге исследовательской команды Aqua Security вышел пост с громким названием "OPA Gatekeeper Bypass Reveals Risks in Kubernetes Policy Engines"! А по факту просто некорректно написанная политика... И такую некорректную политику можно написать и во всех других PolicyEngine. Помимо этого мы на нашем канале уже об этом писали 3 года назад - вот оригинальный пост.

Вывод тут простой - внимательнее читайте наши посты и будете в курсе самых интересных кейсов раньше других ;)

В прошлом году, в одном из постов, мы рассказывали про инструмент k8spider и его возможности. Его автор совсем недавно выпустил статью "Spider in the Pod - How to Penetrate Kubernetes with Low or No Privileges", в которой рассказал как можно пентестить Kubernetes когда привилегий совсем нет или их очень мало.

Автор разбирает несколько кейсов для получения первоначального доступа: Java Heapdump to Cluster Initial Access, Gain Cluster Admin via Weave Scope Internal Unauthenticated Service, Leakage of sensitive information via mutating webhook и Attacking persistent Database backend with NFS/CSI storage. Крайне рекомендуем ознакомиться со всеми более детальней!

В своем повествании автор возвращается к k8spider, а точнее улучшениям которые были внесены в последней версии. Теперь k8spider умеет парсить метрики kube-state-metrics и по ним восстанавливать информацию по доступным ресурсам и их конфигурации.

25 февраля в 11:00 мы проведем вебинар «Безопасность контейнеров и Kubernetes для CISO».

Вебинар будет интересен также C-level, тимлидам и руководителям информационной безопасности, которые работают с контейнерными средами или планируют их внедрение. Мы расскажем о ключевых аспектах безопасности контейнеров и Kubernetes, поделимся практическим опытом и ответим на ваши вопросы.

Команда Luntry уже более 5 лет помогает компаниям из разных секторов (банки, ритейл, финансы и др.) обеспечивать безопасность контейнерных инфраструктур. Мы работали с кластерами различного размера и уровня зрелости, поэтому можем поделиться релевантным опытом как для новичков, так и для экспертов в области контейнеризации.

В рамках вебинара рассмотрим:
- Как и почему контейнеризация завоевывает инфраструктуры
- Что такое контейнеры и Kubernetes
- Как смотреть на защиту контейнерных сред
- Как совместно с ИТ это все использовать на благо, а не во вред
- Почему защита Kubernetes это не то же самое, что и защита Windows/Linux/Mac сред
- Какие подводные камни есть при защите контейнерных сред

Регистрация по ссылке.

Есть такое предчувствие, что такие механизмы как AppArmor и Seccomp получат вторую жизнь и все благодаря контейнерам =)

Проект Kubernetes-AppArmor-Profiles еще одно подтверждение этому. В нем собраны AppArmor и Seccomp профили для популярных образов приложений: grafana, ingress-nginx, memcached, nginx, postgresql, prometheus, redis, tomcat, traefik.

P.S. Ну и не зря же мы в наш Luntry пару лет назад добавляли генератор AppArmor профилей в конце концов ;)

В декабре прошлого года ресерчеры из Unit 42 выпустили новое исследование – "Dirty DAG: New Vulnerabilities in Azure Data Factory’s Apache Airflow Integration".

На первый взгляд ничего общего с Kubernetes тут нет, но как раз благодаря ряду критичных мисконфигов в инстансе Apache Airlfow, запущенного под управлением K8s исследователи смогли продвинуться дальше.

Получив реверс-шелл (ввиду отсутствия Network Policy), благодаря DAG, ресерчеры оказались внутри контейнера, использующего Service Account с правами Сluster-Admin. Далее они без особого труда прочитали секреты и сбежали на Node.

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

Мы наконец-то сделали официальный telegram канал для нашего решения Luntry, где будет публиковаться информация как о самом решении, так и наших активностях, новостях. Ну и хорошим техническим материалом канал не будет обделен. Там уже сейчас можно ознакомиться со статьей про инцидент SolarWinds в контейнерном Мире.

Подписывайтесь!

12 февраля команда Luntry едет в Екатеринбург на Квартирник по безопасной разработке – встреча сообщества, на которой мы обсудим важность DevSecOps в 2025 году, обменяемся опытом и идеями в обстановке дружеского квартирника.

В 18:20 будет доклад Сергея Канибора, R&D Luntry (и автора данного канала), на тему “Безопасность ML кластеров Kubernetes”.

Мероприятие проходит онлайн и оффлайн, начало в 16:00. Зарегистрироваться на квартирник можно по ссылке – количество мест ограничено!

P.S. Приходите пообщаться лично)

8 февраля проходил Red Team Village Overflow с множеством различных воркшопов, тему Kubernetes Security также не обделили вниманием.

На протяжении почти двух часов Graham Helton (Red Team Security Engineer, Google) в своем воркшопе Breaching Bare Metal Kubernetes Clusters рассматривает несколько сценариев атак, которые могут быть использованы для полной компрометации кластера Kubernetes:

- Namespace isolation
- Pod breakout
- RBAC abuse
- Steal Secrets

После каждой атаки автор рассмотрел средства контроля, которые могут остановить или смягчить каждую атаку, какие инструменты следует иметь в своем арсенале при проведении аудита Kubernetes, а также последствия (и заблуждения) Kubernetes для безопасности.

Со слайдами и лабами из воркшопа можно ознакомиться в репозитории автора. Запись стрима доступна на YouTube.

Изначально мы просто планировали сделать просто про релиз фреймворка безопасности контейнеров JCSF. А потом подумали а почему бы не пригласить коллег и вместе рассмотреть и обсудить их фреймворк в рамках отдельного стрима ?!

Так что завтра в 11:00 проведем эфир и там поговорим о фреймворке и вообще про безопасность Kubernetes.

Если у вас уже есть вопросы по теме, то оставляйте их в комментариях к данному посту - постараемся все это задать/уточнить/обсудить.

Регистрация тут.

Мы видим как у наших клиентов и друзей все больше появляется самописных kubernetes операторов (про сторонние даже говорить нечего - их очень много уже в любой инфраструктуре). Тут важно понимать какие с ними могут быть проблемы. И как раз для этого может пригодиться работа "An Empirical Study on Kubernetes Operator Bugs", где рассматривается 210 ошибок с 36 операторов. Это все хорошо классифицировано и систематизировано, что позволяет поучиться на ошибках других и не допускать подобного в своих проектах.

Cегодня хотим обратить ваше внимание на информационное сообщение ФСТЭК России от 13 января 2025 г. N 240/24/38. Оно посвящено повышению безопасности средств защиты информации, в состав которых разработчики включают средства контейнеризации или образы контейнеров.

На нашей памяти это второе упоминание контейнеров/образов/микросервисов ФСТЭКом после публикации 118 приказа. Очень здорово, что регулятор все больше внимание удаляет данной теме!

И как раз в тему этого будет наш воркшоп “Основы анализа СЗИ в контейнерном исполнении с помощью Luntry” в рамках ТБФорум.