Опубликовано видео моего выступления "Kubernetes Resource Model (KRM): Everything-as-Code" с VK Kubernetes Conference, которая прошла 9 декабря 2021 года.

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

Доклад не про безопасность, но все это справедливо и для безопасности:
- Security as Code
- Policy as Code
- Compliance as Code

На мой взгляд только так можно достичь высокого уровня безопасности в условиях:
- частых и постоянных изменений микросервисов,
- разительной разницы в количестве между разработкой и ИБ,
- нескончаемых патчей 1day и 0day уязвимостей,
- набирающих обороты атак на supply chain.

Старые подходы являются реактивными, пришло время проактивных.

Один из читателей канала подсветил один очень интересный момент касательно Policy Engines и subresources. Этим бы я и хотел сегодня с вами поделиться ;)

Как вы знаете все в Kubernetes это YAML и все YAML проходят через mutating и validating admission controllers, на которых и базируются Policy Engines. Но есть и исключения в виде subresources:
- pods/exec
- pods/attach
- pods/log
- pods/portforward

На просторах сети можно встретить информацию, что их нельзя обработать как другие ресурсы. И я тоже так думал....

Но оказывается они идут через операцию CONNECT (не CREATE, UPDATE) в виде ресурса PodExecOptions, дочерним для Pod, и это можно обработать! Посмотрите:
1) Политика для Kyverno (для Gatekeeper должно тоже работать)
2) Статья "Using K8s Admission Controllers to Detect Container Drift at Runtime" с самописным admission controller (исходный код)

P.S. Ну и про корректный RBAC не забывайте!

P.S.S. Когда-то еще был DenyEscalatingExec ...

Вокруг моего любимого Security Profiles Operator все больше новостей и движухи!

Так за последнее время вышло:
1) Отдельное выступление "Enhancing Kubernetes with the Security Profiles Operator" с KubeCon EU 2021про него
2) Статья "What's new in Security Profiles Operator v0.4.0" в официальном блоге Kubernetes
3) Статья "Secure your Kubernetes deployments with eBPF" на портале Red Hat Developer

Если вы все еще задаетесь вопросом когда это вообще может пригодится, то посмотрите раздел User Stories из документации проекта и все точно станет на свои места =)

Если вы вдруг захотите самостоятельно разработать решение по аутентификации для компонентов вашей системы (workload identity), то не спешите все делать с нуля!

Уже в CNCF существует стандарт SPIFFE (Secure Production Identity Framework For Everyone). Там описывается 3 вещи:
1) SPIFFE ID - уникальный ID для аутентификации
2) SVID (SPIFFE Verifiable Identity Document) - проверяемое криптографическое представление для SPIFFE ID
3) Workload API - для работы с этим всем

Стандарт используется в Kubernetes, Docker, Istio, Consul, Dapr и многих других проектах.

При этом есть и референсная реализация данного стандарта в проекте SPIRE (SPIFFE Runtime Environment). Состоит из 2-х частей:
1) Server - является signing authority и реестром идентификаторов
2) Agents - часть workload для предоставления SPIFFE Workload API

И помните как и в любых реализация любых стандартов есть ошибки. Что и показал 3rd party security audit данного проекта (SPIRE).

Компания GitLab зарелиза забавный внутренний проект Package Hunter. Задача которого заключается в обнаружении вредоносных зависимостей в коде через динамический анализ. А именно под капотом у него находится Falco. В общем если во время работы Falco ничего не обнаружит по своим сигнатурам ничего криминального, то считается что вредоносных зависимостей в коде нет ... Так можно это все встроить прозрачно в свой CI.

Обойти такой метод проверки вредоносному коду ничего не стоит:
1) Запуститься только при определенных действиях (На пример, при соединении к приложению)
2) Запуститься через какое-то время или при наступлении какого-то времени

Но, конечно, что-то такое что работает тупо в лоб - данный инструмент может.

И снова один из читателей канала поделился интересным фактом из Kubernetes безопасности.

В CNI Cilium в заголовке пакетов добавляется информация об identity контейнера, что передает данные! При этом разработчик признают, что это security sensitive information и рекомендуют:
1) Либо шифровать весь трафик
2) Либо относится к своей сети как к доверенному окружению (Облака?!) (то есть некоторые модели нарушителя просто не рассматривать)

Это фигурирует только в документации от версии 0.8, а далее этот момент полностью пропал из документации ... Но на практике так все и продолжает работать (опросил ряд компаний)!

Я думаю, что наличие такой default капабилити у контейнеров как CAP_NET_RAW [1,2,3] - открывает атакующим множество интересных атак и это достойно отдельного исследования ;)

С наскоку забуриться в исходный код Cilium и найти эту часть там у меня не получились. Может кто уже копал в этом направлении или хочет к этому присоединиться?

P.S. Может и в правду сделать рубрику #читателипишут ?!

А сегодня поднимем тему шифрование трафика в кластере Kuberneres между Pods. Это может потребоваться как для соответствия каким-нибудь compliance, так и в условиях работы в недоверенном окружении. Я выделил 3 способа (если я что-то забыл пишите в комментариях):

1) На уровне CNI плагинов (Calico, Cilium) с помощью:
- IPSec
- Wireguard
2) На уровне Service Mesh (Istio, Linkerd) с помощью:
- mTLS
3) На уровне ваших приложений с помощью:
- SSL/TLS протоколов

Заметьте что от реализации к реализации в разных CNI есть поддержка разных фич Wireguard.

В этом году, проводя свои тренинги по безопасности Kubernetes, я был приятно удивлен встретить компании, у которых микросервисы, реализующие бизнес-задачи, выполнялись с описанием:

securityContext:
  capabilities:
  drop:
    - all

Это очень круто уменьшает attack surface для побега из контейнера через уязвимости ядра хостовой ОС (особенно с учетом того, что CAP_NET_RAW есть by default).

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

При этом мой хороший товарищ, автор великолепной Linux Kernel Defence Map подсказал замечательную статью проекта grsecurity под названием "False Boundaries and Arbitrary Code Execution" (заметка не свежая, но актуальная и по сей день). Где рассказывается о том, что capabilities в архитектурном плане скажем так не без греха, и в каком-то плане даже сломаны.

Это полезно знать как blue team, так и red team. Поэтому даже в условиях drop all стоит заботиться о том, что происходит в ваших контейнерах. Тоесть runtime security все равно остается важным элементов Kubernetes security.

Всех с наступающим Новым Годом!

И сегодня хотелось бы подвести итоги 2021 года и немного заглянуть в 2022:
1) Мы с командой наконец-то показали миру нашу разработку Лантри и будем дальше покорять Мир =)
2) Данный канал продолжает расти (> +1200) и надеюсь радовать вас интересным и качественным контентом. Если что-то не так, то всегда пишите ;)
3) Наконец-то удалось выступить на offline конференциях [1,2,3,4,5] и лично познакомиться с многими классными людьми из Kubernetes сообщества. Если ничего экстренного не произойдет, то в следующем году также выступлю на 2-3 мероприятиях (точно буду на HighLoad++)
4) Помимо offline активности у меня были и online выступления [1,2], online тренинги [1] и записи podcasts [1,2]. На следующий год уже точно запланировано несколько вещей в этом же направлении.
5) В этом году я также вернулся к своим корпоративным offline тренингам, побывал в море крутых компаний, поделился своими знаниями и посмотрел какие Kubernetes строят у себя лидеры ИТ. На следующий год тренинги уже расписаны по апрель!
6) Kubernetes радует своим развитием, появлением новых фич, улучшениями observability и security. Вообще Cloud Native сообщество очень продуктивно и не дает заскучать.

Всем большое спасибо, что читаете, комментируете, спрашиваете!

Всем хорошо встретить Новый Год, отдохнуть в праздники и не болеть!

Всем привет после затяжных праздников!
Начнём потихоньку ;)

Эксклюзивное видео моего доклада "Kubernetes: трансформация к SecDevSecOpsSec" с DevOpsConf 2021. Описание и слайды можете посмотреть на данной странице.

Помимо рассмотрения безопасности в Kubernetes, я затрагиваю тему DevSecOps и моего отношения к нему (спойлер: я не люблю данный термин). Я предпочитаю больше термин Continuous Security по аналогии с Continuous Integration и Continuous Delivery. За подробностями уже ныряйте в видео!

Всем продуктивного и успешного Нового Года!

P.S. До 30 января идет прием заявок на DevOpsConf 2022 - о чем бы вам было интересно там послушать от меня?

Важной частью концепции контейнеров является Linux namespaces (не путайте их с Kubernetes namespaces!)

И есть замечательный цикл статей что их подробно рассматривает (PID, NET, USER, MNT, UTS, IPC, CGROUP):
- Digging into Linux namespaces - part 1
- Digging into Linux namespaces - part 2

Отдельно отмечу раздел про USER namespaces, где описывается операция mapping UIDs и GIDs и связь с capabilities. От сюда вы узнаете почему даже с использование новой фичи Kubernetes 1.22 под названием Kubelet-in-UserNS (aka Rootless mode) все равно нужно грамотно управлять capabilities и убирать не нужные для вашего приложения, хотя с этой фичей картина куда лучше ;)

P.S. Capabilities тоже привязаны к USER namespace

Если вы или ваши разработчики до сих пор задаетесь вопросом чем плох доступ к Docker socket, то статья "Why is Exposing the Docker Socket a Really Bad Idea?" должна полностью снять все вопросы по этой теме.

На канале я не раз [1,2,3,4] уже писал о том, что часто в компаниях можно встретить как данный сокет или выкидывают вообще сеть в интернет или пробрасывают внутрь контейнера или Pod в Kubernetes (чаще всего для сборки образов).

Спойлер: доступ к Docker socket = root доступ на Host

В статье рассматривается почему так и как этого можно добиться. Очень полезно знать как атакующим, так и защищающимся!

Краткое содержание и основные моменты:
1) Как взаимодействовать с данным сокетом с помощью curl, socat если нету docker клиента под рукой
2) На базе матрицы MITRE ATT&CK для контейнеров рассматриваются все тактики от Initial Access до Impact с техниками из них
3) Не обходится без демонстрации побега из контейнера на хост через: маунт корня хоста в контейнер и Privileged + notify_on_release

В Kubernetes у вас могут быть и другие container runtime (совместимые с CRI), но суть та же и роль играет то от какого пользователя они работают (root, не root) и что там у вас с USER namespace ;)

Так на уровне Policy Engine вы может проверять что монтируется внутри ваших Pods.

Очень часто я для повышения безопасности в Kubernetes кластере рекомендую использовать Policy Engines. Но стоит помнить, что это всего лишь движки, которые производят проверки Kubernetes ресурсов с учетом политик, которые пишутся людьми.

Тут важно понимать, что при создании политик можно ошибиться или что-то не предусмотреть и в итоге это позволит обойти данную проверку. Я, периодически помогая компаниям проверить их политики для Policy Engines с учетом их специфики процессов и окружения, встречаю подобные проблемы.

На пример, в политике может быть прописан запрет на пробрасывание внутрь контейнера пути /var/run/docker.sock. А по факту в компании вообще используется /var/run/crio/crio.sock, да и обойти это можно через /,/var/,/var/run/,/var/run/crio/ ...

Поэтому привила для Policy Engines нужно писать, учитывая как Linux специфику, так и ваше конкретное окружение ;)

Всех с первой рабочей пятницей 2022 года =)

Забавная статья "K8s.io KinD inside a Sysbox Container" от авторов Sysbox. О данном проекте я уже говорил в рамках поста о том, что начало появляться много разных Container Runtime. В статье есть 2 основные части:
1) "Running KinD inside an Unprivileged Sysbox Container"
2) "Running KinD inside an Unprivileged Sysbox Pod" (через Kubernetes ресурс RuntimeClass)

Тоесть там рассказывают, как KinD запускать не на хосте или VM, а в Sysbox Container. Основное преимущество описывается данным абзацем: "However, by placing the KinD cluster inside a Sysbox container, you can significantly harden the isolation because the privileged containers are only privileged inside the Sysbox container. The Sysbox container itself is unprivileged (aka rootless) and provides strong isolation."

Опять же вся магия вокруг USER namespaces ;)

Если вам для тестирования нужно использовать KinD, то вам это может быть очень полезным для повышения уровня изоляции.

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

Запись моего выступления "Container escapes: Kubernetes edition" с секции Defensive Track конференции ZeroNights, что была 30 июня 2021.

В рамках данного доклада я рассматривал, как и что могут атакующие и что можно сделать, чтобы усложнить побег из Pod’а.

И небольшой инсайд: в этом году я также планирую представить новое исследование на тему Kubernetes на ZeroNights 2022. На текущий момент это скорее всего будет исследование с рабочим названием "NetworkPolicy: родной межсетевой экран Kubernetes". Посмотрим на то как и что могут NetworkPolicy и как они устроены в различных CNI и куда они развиваются.

Хороший пост "What an SBOM Can Do for You", который все раскладывает по полочкам о текущем состоянии Software Bill of Materials (SBOM), если вы о нем раньше не слышали. Основные разделы:
- What Is Exactly an SBOM?
- The Two SBOM Standards – речь о CycloneDX и SPDX
- The Ultimate Purpose(s) of the SBOM
- Locate and Describe a Software Component
- Automation
- Licensing
- Security
- Status of Tools and Cooperation - отдельно выделю инструменты bom и syft
- The Future: Your Tool Will Be SBOMin’ Soon - особенно круто будет когда SBOM станет частью того же образа контейнера и в любой момент можно понять и проверить содержимое.

О SBOM для Kubernetes я уже писал и всегда можно посмотреть его для последних версий. Также я очень жду, когда кто-нибудь возьмет и напишет Kubernetes operator для генерации SBOM (по аналогии со Starboard) и хранения результатов в Custom Resources (иначе придется это делать самому). Все это полезно будет и для observability и для troubleshooting .

Довольно интересный репозиторий CKS-Exercises на GitHub, который содержит в себе упражнения призванные помочь в подготовке к экзамену на Certified Kubernetes Security Specialist о появлении которого я писал ранее.

В принципе, если вы даже его и не планируете получать, то проглядеть все равно его стоит - среди затрагиваемых тем с примерами:
- Cluster setup
- Cluster Hardening
- System Hardening
- Minimise Microservice Vulnerabilities
- Supply Chain Security
- Monitoring, Logging and Runtime security

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

Недавно довелось поиграться со сканером Kubei, которой состоит из двух частей:
- Сканера уязвимостей в images на базе Grype
- Сканера плохих практик в dokerfiles по CIS Docker Benchmarks на базе Dockle

Главной особенностью данного сканера (как считают авторы) является то, что его не нужно встраивать в CI/CD и никак интегрировать с image registry (все это верно и для Starboard operator). Как он работает:
1) Запускается в Kubernetes
2) Смотрит какие Pods там работают и какие images они используют
3) Создает Jobs, которые порождают Pods, и там производит сканирование

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

НО мне не понравилось, что вот эти сканирующие Jobs он создает в чужих Namespaces, что при условии наличия LimitRange, ResourceQuota может сыграть злую шутку. Поэтому по прежнему лучшей реализацией я считаю Straboard operator - он все делает внутри своего Namespace.

PS Цикл про сканеры.

Один из читателей канала недавно опубликовал (и поделился ссылкой) на эксплоит для нашумевшей уязвимости CVE-2021-25741 в kubelet.

Атакующий должен иметь права на создание Pods. После успешной эксплуатации можно получить доступ к файловой системе Node из Pod с возможностью писать и читать.

Напомню уязвимые версии:
Уязвимые версии:
- v1.22.0 - v1.22.1
- v1.21.0 - v1.21.4
- v1.20.0 - v1.20.10
- <= v1.19.14

Так что для тех, кто еще не обновил свой Kubernetes это дополнительный стимул ;)

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

В белой-белой компании Luntry
Белый-белый хакер Дмитрий Евдокимов (@Qu3b3c)
Пишет прозрачно-белый observability для k8s
В таких условиях легко найти черный код... или не все так чисто?

Детективная история будет разворачиваться прямо у вас в ушах уже в эту cleaning-пятницу в 20:00 на подкасте в DevOps-курилке.
Шерлок Фиделина @fidelina_ru, Хомяк-Холмс @Asgoret и what's up?

Рекомендации: Чтобы следить за ходом расследования желательно подключаться с desktop машинки, так будет виднее)

При поддержке @k8security <—- Дмитрий Белый Евдокимов именно здесь обитает) @devops_ru @devops_jobs
——-

Проект sbom-operator поможет вам собрать все Software Bill of Materials (SBOM) для ваших images в Kubernetes кластере и результат положить в Git.

Очень новый проект, но и очень многообещающий. Под капом у данного Kubernetes оператора проект Syft и библиотека go-containeregistry, которая позволяет скачать нужный образ для анализа с различных реджистри. В официально поддерживаемых:
- ACR (Azure Container Registry)
- ECR (Amazon Elastic Container Registry)
- GAR (Google Artifact Registry)
- GCR (Google Container Registry)
- GHCR (GitHub Container Registry)
- DockerHub

В дальнейшем данную информацию можно использовать и для организации безопасности supply chain и для контроля развития ваших микросервисов (в какой версии какие зависимости каких версий использовались).

Лично мне еще не хватает возможности получения результата работы в виде отдельного Custom resource, ссылающегося по ownerReference на ту же ReplicaSet, чтобы можно было быстро оценить картину на текущий момент.