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

И сегодня хотелось бы подвести итоги 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, чтобы можно было быстро оценить картину на текущий момент.

Если перед вами (как и перед одним из читателей канала) стоит задача переехать с PodSecurityPolicy (PSP) на PolicyEngine, то сегодняшний пост определенно для вас и вам не стоит напоминать, что PSP уходит в прошлое в 1.25 (а его замена PodSecurity Admission Controller вам не близка).

И так ситуация: вы в компании используете PSP и вам надо перебраться с минимальными усилиями на PolicyEngine. Как быть? Делать ли все вручную?!

На помощь спешит проект PodSecurityPolicy Migrator!

Он поддерживает (в разной степени) перевод PSP в политики для:
- Gatekeeper
- Kyverno
- Kubewarden
- k-rail

Помимо CLI реализации проекта, есть и online версия, с которой можно поиграться прямо сейчас.

Также не забывайте, что авторы большинства PolicyEngines уже у себя в репозиториях [1,2,3] сделали базовые политики на базе PSP и вы можете туда также смотреть ;)


P.S. Большое спасибо всем читателям, что делятся своими находками при решение свои задач и проблем!

В официальном блоге Kubernetes появилась запись "Securing Admission Controllers". И посвящена она как нетрудно догадаться безопасности такого важно для Kubernetes механизма как Admission Controllers. На нем базируется, по сути, Kubernetes operators и те же PolicyEngines.

И данная запись на самом деле приурочена к выходу whitepaper под названием "Kubernetes Admission Control Threat Model" от SIG Security. В документе вы найдете:
- Attack Tree - дерево атак, связывающее начальные условия, угрозы, защиты и возможные последствия
- Threat Model - всего выделили 16 угроз.
- Mitigations - 8 штук

Особое внимание обратите на угрозы с ID: 4,6,11,17. При их реализации атакующий сможет:
1) Запустить workload, который по идее уязвимым Admission Controller был бы запрещен
2) Получить доступ к чувствительной информации, с которой работает Admission Controller

Хардкорная блоговая запись "CVE-2022-0185 - Winning a $31337 Bounty after Pwning Ubuntu and Escaping Google's KCTF Containers" еще один прекрасный пример (на ряду с CVE-2021-22555) побега из контейнера через kernel уязвимость хоста в рамках kCTF. Код эксплоита.

Основные моменты:
- Уязвимость позволяет в Kubernetes совершить побег из Pod на Host.
- Уязвимость появилась с 5.1-rc1 в марте 2019.
- Для атаки атакующий должен иметь доступ к контейнеру с CAP_SYS_ADMIN privileges (что само по себе считай побег) или к команде unshare(CLONE_NEWNS|CLONE_NEWUSER), которая даст CAP_SYS_ADMIN privileges в новом user namespace
- SeccompDefault в значении RuntimeDefault благодаря блокировке unshare способен замитигейтить данную багу (и все это только с 1.22)

Как и в прошлый раз я рекомендую: используйте AppArmor/SeLinux/seccomp профили для приложений, а также всегда имейте возможность смотреть что происходит внутри ваших контейнеров - прокачивайте observability.

Статьи по теме от вендоров [1,2].

Одним из самых популярных вопросов на всех форумах по Kubernetes это: "А кто, как ставит Kubernetes?"

Не знаю кто как, но так точно hard way =)

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

Чем опасен доступ к nodes/proxy в RBAC?

Именно на этот вопрос исследователи дают ответ в заметке "Node/Proxy in Kubernetes RBAC".

По итогу:
- Возможность работы с Pods на Node напрямую через Kublet API в обход Kubernetes API
- Право GET позволяет читать, например, получить список Pods на Node
- Право CREATE позволяет читать, например, выполнить команду в Pods
- Доступ к портам, что закрыты firewalls
- Обход средств контроля безопасности, таких как Kubernetes Audit Log и Admission controls

Отдельно стоит еще посмотреть на заметку "Detecting direct access to the Kubelet". По итогу, понять какой именно пользователь обращался к node proxy в Audit log нельзя, но можно увидеть, что кто-то обращался к nodes/proxy sub-resource по записям в логе о TokenReviews и SubjectAccessReviews ресурсах от kubelet.

Заодно ребята еще проверили багу 2019 года с “Abusing Kubernetes API server proxying” и убедились что она работает до сих пор.

P.S. Также не забывайте про "*" ;)

secureCodeBox это kubernetes-based модульный toolchain от проекта OWASP на базе множества open source сканеров для continuous security scans. Это какая-то мечта любого DevSecOps специалиста!

Смотрите сами:
- Поддержка более 15 сканеров: Amass, Git Repo Scanner, Gitleaks, Kubehunter, Kubeaudit, Nikto, Nmap, Nuclei, Semgrep, Trivy, ZAP и другие.
- Встраивание в CI/CD pipeline или Kubernetes окружение
- Наличие собственного Dashboard, интеграции с DefectDojo и Kibana (ELK Stack) или кастомная интеграция
- Управление и контроль через его Custom Resources: Scan, ScheduledScan, ScanType, ParseDefinition, ScanCompletionHook, CascadingRule (еще один шажок в направлении Security-as-Code)

Сам еще этого монстра не тестировал, но выглядит как минимум впечатляюще. Пример использования тут. Если кто уже опробовал его в деле - пишите в комментариях ;)

Статья "Hardening Kaniko build process with Linux capabilities" о повышения уровня безопасности процесса сборки при использовании Kaniko. Вопрос сборки образов внутри Kubernetes/containers мы уже как-то поднимали и обсуждали момент с преимуществами такого подхода. Но это статья не о простом использовании Kaniko, а о том, как можно улучшить, обезопасить процесс.

Ситуация с Kaniko следующая - его контейнер запускается от пользователя root. Можно, конечно, предположить, что ему для работы нужны далеко не все capabilitys =)

План: забираем все capabilitys и явно добавляем только нужные!

Автор в своих изысканиях с Kaniko пришел к такому результату: CHOWN, SETUID, SETGID, FOWNER, DAC_OVERRIDE.

Как вы понимаете такой подход работает и для других приложений ;)

Повсюду говорят о важности безопасности supply chain, но реализовать это не просто ведь состоит это не из одного какого-то действия, а из целой цепочки и ряда разнообразных типов инструментов. И тут руки опускают и включается режим ожидания “комбайна”, который сделает все сам через одну красную кнопку ...

Но если вы не ждун и руки чешутся все это реализовать здесь и сейчас, то статья "Improve supply chain security with GitHub actions, Cosign, Kyverno and other open source tools" как раз для вас как ориентир.

Тут вам и генерация, и проверка checksum, SBOM, подписи образа с помощью Docker Content Trust (DCT), Cosign, Syft, Kyverno, а также сканирование на уязвимости с помощью Trivy и все через GitHub actions!

Отдельно выделю раздел "Further improvement or study" о том, как еще можно улучшить данную цепочку.