Совсем недавно в рамках SANS Blue Team Summit 2021 был представлен доклад "DeTT&CT(ing) Kubernetes ATT&CK(s) with Audit Logs" и сейчас доступны как слайды, так видео выступления.

По мне данный материал более наглядно (с примерами и привязками к техникам из MITRE ATT&CK) дополняет работы "Detection Engineering for Kubernetes clusters" и "Threat Hunting with Kubernetes Audit Logs", о которых я писал ранее.

В конце, автор еще немного показывает, как со всеми этими логами можно работать в Splunk.

Очень простенький сайт для расчета uptime и downtime с соответствующим SLA. Позволяет перевести магию девяток в конкретные временные интервалы в месяцах, днях, часах и т.д.

У кого как вообще обстоят дела с этим ?)

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

Уже несколько дней все security сообщество только и обсуждает Log4Shell уязвимость в библиотеке log4j.

Давайте с вами тоже на это посмотрим, но:
1) в контексте Kubernetes
2) с использованием технологии eBPF
3) с применением классного инструмента Pixie

Все это есть в статье "Did I get owned by Log4Shell?" ;)

Ну а так по мне используйте NetworkPolicy + AppArmor в Kubernetes и подобные 0day вам будут не страшны!

Проект Kubernetes Security Profiles Operator не стоит на месте и активно развивается. Что очень сильно меня радует, так как это мой самый любимый Kubernetes operator [1,2] в теме security и самый мощный в данной области по моему мнению. В ближайшем, будущем он может быть знатным killer'ом коммерческих решений. Так как даст возможность делать detection и prevention стандартными средствами Linux и Kubernetes. При этом сами политики/профили и их связи с workloads имеют отражение как в отдельных Custom Resources, так и связях с нативными ресурсами, что позволяет Dev, Ops и Sec командам всем вместе видеть реальную, текущую картину того, как ограничено в работе приложение в YAML файлах - Security as Code.

И так в данный operator недавно добавили помимо поддержки seccomp еще и отдельные Custom Resources для AppArmor и SeLinux профилей! Там еще не все завершено (текущее состояние отражено на скриншоте), но с какими темпами сейчас там идет работы я уверен, что скоро все доведут до ума!

KubeArmor еще один проект, который двигает направление Security as Code, как и Kubernetes Security Profiles Operator.

Авторы данного проекта позиционируют его как Cloud-native Runtime Security Enforcement System. Под капотом у проекта LSM хуки и для обработки системных вызовов используется известный проект Tracee, который для своей работы использует eBPF.

Так проект позволяет в YAML ресурсах определять политики того, что может и не может делать контейнер (с процессами, файлами и сетью) в Kubernetes.

Проект пока очень молодой и на тестах показал себя сыроватым, но очень амбициозным! Так я очень жду, когда они добавят поддержку LSM eBPF (KRSI). Так это еще один потенциальный killer для коммерческих security решений в области detection и prevention.

P.S. Напоминает проект bpfbox.

Продолжим тему Runtime Security в Kubernetes и сегодня хотелось бы привлечь ваше внимание к интересному PR для проекта falcosidekick, который является по сути прослойкой между Falco и другими система для оповещения.

И так речь пойдет о "WIP: Adds policy report output support for falcosidekick #256" и означает поддержу ресурсов из wgpolicyk8s.io/v1alpha2: ClusterPolicyReport и PolicyReport, над которыми работает Policy Working Group (об этом я писал ранее).

Таким образом еще один проект двигается в направлении Seurity as Code! Все в одной системе, все связано и прозрачно для всех ;)

Ну и пятницу закончим темой что не давала многим покоя всю эту неделю.

Грамотно используйте все встроенные возможности Kubernetes и Linux и будет вам счастье!

Повторю в сотый раз - стройте безопасность микросервисных приложений в Kubernetes от себя, а не от потенциальных возможностей атакующих - в такой игре вы всегда на шаг позади. Понимание себя дает вам возможность быть готовым и защищенным и к 0day уязвимостям.

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

Опубликовано видео моего выступления "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, то вам это может быть очень полезным для повышения уровня изоляции.

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