k8s (in)security

В чате Kubernetes один из читателей задался вопросом – “Если выставить privileged: true в securityContext, то capabilities: drop: [ALL] теряет всякий смысл?”. Нам стал интересен результат и мы решили это проверить:

Сначала проверим capabilities у privileged контейнера:

root@ubuntu:/run# capsh --print
Current: =ep
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search, …(всего около 40, для удобства восприятия список сокращен)

Потом при выставленном capabilities: drop: [ALL]:

root@ubuntu:/run# capsh --print
Current:
Bounding set =

И в последний раз privileged + capabilities: drop: [ALL]:

root@ubuntu:/run# capsh --print
Current: =ep
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search, …

Никакой разницы между первым и третьим пунктом нет. Становится ясно, что privileged имеет более высокий приоритет над capabilities.

Совсем недавно зарелизилась новая версия trivy – v0.41.0. Новвоведений не так много, но всё-таки они есть:

1) Добавили поддержку VEX – можно фильтровать найденные уязвимости в форматах CycloneDX и OpenVEX
2) Теперь trivy умеет генерировать SBOM для образов виртуальных машин в форматах CycloneDX и SPDX
3) Вложенные пути в JAR-файлах стали отображаться корректно
4) Trivy может обнаруживать лицензии у файлов с кастомным уровнем доверия
5) Добавили поддержку SPDX 2.3
6) Теперь можно генерировать custom compliance reports

Не стоит забывать, что сканеры уязвимостей не являются silver bullet – об этом мы не раз упоминали в своих постах [1,2]. Ну и сам trivy не является идеальным инструментом для работы с уязвимостями – если вы захотите скормить ему SBOM от других тулзов, скорее всего он ничего не найдет.

Стало доступно видео моего выступления "Классификация и систематизация средств безопасности для Kubernetes" с мероприятия CyberCamp MeetUp. DevSecOps.

В рамках данного доклада я постарался показать и объяснить специалистам ИБ, которые ранее защитой Kubernetes не занимались, какие есть механизмы и средства безопасности для него, попутно проводя параллели с классическими средствами ИБ. Доклад нацелен на специалистов только начинающих погружаться в данную тему.

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

Недавно на глаза попалась занимательная заметка "A Follow-up to the Exploit-DB and 0day.today Comparison" (продолжение "A Comparison of Exploit-DB and 0day.today") с очень интересными результатами. Основной лейтмотив данного материала это CVE и имеющихся для них эксплоитов. Как вы, наверное, уже догадались нам тут это все интересно в контексте сканирования образов на известные уязвимости, результаты которых чаще всего идут потом как задачи для разработчиков для обновления сторонних зависимостей. Что разработчики делать, конечно, не очень любят ...

Как по мне основной вывод можно описать следующей цитатой: "Consider that Exploit-DB contains exploits for nearly 25,000 CVE, but only 500 of those have been exploited in the wild. 500 CVE is only 2% of the CVE in the database."

Пару моментов от меня:
1) 2% — это очень мало. Вспомните сколько задача вы поставили своим разработчикам для обновлений в сравнении с этим.
2) 2% — не значит, что под другие уязвимости нельзя самостоятельно написать эксплоиты и использовать таргетировано.
3) Угнаться за всеми обновлениями, фиксами, базами знаний невозможно лучше использовать возможности Kubernetes для построения ZeroTrust обороны.

Сегодня публикуем последний доклад (хотя еще возможны и сюрпризы в программе) нашей программы БЕКОН:

- "Концепция Cluster API или как разворачивать безопасные кластера", Дмитрий Путилин (VK)

Описание: С учетом развития Kubernetes и его инструментов развертывания за последние 8 лет, вопрос безопасности и соответствия рекомендациям CIS Benchmark для конфигурации K8S кластеров становится все более актуальным. В докладе автор поделиться опытом использования связки Policy Engine и ресурсов Kubernetes для обеспечения безопасности при развертывании кластеров с помощью Cluster-API и аналогичных решений.

Ознакомиться с полной программой и купить билеты можно тут.

Совсем недавно компания ControlPlane представила довольно интересный отчёт: Argo CD End User Threat Model – Security Considerations for Hardening Declarative GitOps CD on Kubernetes.

Всего в отчёте около 20 findings, рассматривается как внешний так и внутренний нарушитель. Все угрозы разбиты по категориям, для каждой определены риски, приоритетность и рекомендации с mitigations. Отдельно выделю крутые Attack Tree, построенные по моделям нарушителя.

С полным отчетом можно ознакомиться по ссылке тут.

С конференции KubeCon + CloudNativeCon Europe 2023 стали доступны:
- Слайды (зайдите в описание интересующего вас доклада)
- Видео

Там море всего крутого! Обязательно, самое интересное рассмотрим на нашем канале.

Наша конференция БЕКОН, конечно, в масштабах с данным мероприятием тягаться не может, но вот по актуальности тем у нас есть ряд интересных пересечений - так что у нас будет все самое актуальное по индустрии!

Metarget – это инструмент, позволяющий разворачивать уязвимые инфраструктуры в одну команду.

Развертывание инфраструктуры занимает довольно много времени и часто это становится проблемой при тестировании PoC. Конечно, есть такие проекты как Vulhub или VulApps, но они всё-такие заточены на уязвимые веб-приложения, которые нужно обернуть в контейнер для удобного использования.

Вообщем, если вам нужна уязвимая версия docker или Kubernetes, то эта тулза musthave. Вот что она предлагает:

- уязвимости в docker
- уязвимости в ядре
- уязвимости в containerd
- уязвимости в runc
- уязвимости и мисконфиги в kubernetes

Самое то, чтобы тренировать и отрабатывать навыки для пентестов.

Еще одна прекрасно проиллюстрированная статья "Kubernetes: Network Policies" от того же автора, о котором мы недавно уже писали. В этот раз тема про нативную NetworkPolicy. И если вы визуал, как абсолютное большинство людей на этом шарике, то вам такое объяснение принципов работы данного ресурсы точно зайдет.

Также не забываем про классные репозиторий Kubernetes Network Policy Recipes с его анимированными схемами политик!

Про кастомные политики рекомендую посмотреть наше (команды Luntry) выступление "NetworkPolicy — родной межсетевой экран Kubernetes" ;)

Давненько не выступал в Санкт-Петербурге и завтра это исправлю. А конкретнее в 15:00 на Код ИБ с докладом "Контейнеры и Kubernetes: не боимся, а используем и защищаем". Разберемся, что такое и зачем нужны контейнеры и Kubernetes, а также рассмотрим их с точки зрения ИБ и отношения российских регуляторов.

Исследователи из Aqua Nautilus обнаружили, что как минимум 5 компаний из списка Fortune 500 имеют критичные мисконфиги в registries и artifact repositories, содержащих более 250 миллионов артефактов и 65000 образов. Эти данные включают в себя различные ключи, токены, креды, секреты и приватные эндпоинты.

Очевидно, что registries являются важной частью цепочки поставок в облаке, и что организации не уделяют им достаточного внимания. Если злоумышленники получают доступ к ним, они могут отравить и потенциально использовать весь SDLC.

Причины такого достаточно тривиальные:

- открытый доступ в интернет
- уязвимые версии компонентов
- слабые пароли
- разрешенный анонимный доступ

Если говорить о том, как снизить риски:

- использование VPN или firewall
- использование SSO, MFA, и надежных паролей
- регулярное обновление ключей, кредов и секретов
- следование приницпу наименьших привилегий
- регулярное сканирование sensitive data

В заключение, небольшой cheatsheet с mitigations.

Хорошо проиллюстрированная статья "Kubernetes: Security Contexts", объясняющая назначение, специфику и отличия Pod Security Context и Security Context.

В официальной документации этому вопросу посвящен раздел "Configure a Security Context for a Pod or Container".

В продолжение темы предыдущего поста , статья – “Fun with container images - Bypassing vulnerability scanners”. В ней автор рассказывает об очень простой, но не менее крутой технике для обхода ВСЕХ vulnerability scanners для образов.

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

PoC очень простой, всё что он делает это принимает на вход tar-архив с образом, распаковывает его и запускает бинарь из извлеченного архива. Тут есть несколько важных моментов:

- Так как конечный образ будет основан на scratch, то сам бинарь должен быть статически скомпилирован
- Бинарь можно дополнительно упаковать, например upx
- На вход программа принимает tar архив, который можно получить с помощью команды docker extract
- В финальном Dockerfile нужно использовать ENTRYPOINT, а не CMD, поскольку мы хотим иметь возможность передавать аргумент в docker run и передавать его в main в качестве второго аргумента

Доклад "Malicious Compliance: Reflections on Trusting Container Image Scanners" с последнего KubeCon EU 2023 Amsterdam.

На картинке к посту вы видите, с чего докладчики начнут свой доклад и чем его закончат. Поясню: просканят образ разными сканерами образов (Trivy, Grype, Docker Scan, Docker Scout) и затем, производя ряд манипуляций, получая в конце концов 0 найденных уязвимостей!!!

НО если вы думаете, что вас там научат чему-то хорошему (как круто патчить уязвимости, харденить образы и т.д.), то вы глубоко ошибаетесь! ВАС НАУЧАТ ПЛОХОМУ!

Докладчики покажут и научат как обмануть сканеры уязвимостей =)
Тоесть разработчики - берите себе на заметку как проходить все compliance ;)

P.S. Я неоднократно уже на канале и на своих докладах говорил, что строить безопасность вокруг сканеров уязвимостей образов это проигрышная история ...

Стал доступен "Kubernetes 1.24 Security Audit"!

Прошлый подобный отчет для Kubernetes датируется 2019 годом и был для версии 1.13.

Основные результаты нового отчета:
- A number of concerns with the administrative experience as it relates to restricting user or network permissions. These may result in administrator confusion or a lack of clarity around the permissions available to a specific component.
- Flaws in inter-component authentication which allow a suitably positioned malicious user to escalate permissions to cluster-admin.
- Weaknesses in logging and auditing which could be abused by an attacker post-compromise to aid in maintaining persistence or stealth once in control of a cluster.
- Flaws in user input sanitisation which allow a restricted form of authentication bypass by modifying the request made to the etcd datastore.

Очень круто, что к K8s есть такое пристальное внимание со стороны ИБ.

Публикуем еще один доклад из программы нашей конференции БЕКОН:

- "NetworkPolicy для системных и инфраструктурных компонент", Александр Кожемякин, (VK)

В рамках доклада рассмотрим создание и организацию сетевых ограничений на такие компоненты как DNS, Metrics, Logs, GitLab runners и другие компоненты, как на L3-L4 так и L7 уровнях.

Билетов остается все меньше - приобрести их можно тут.

На первый взгляд довольно интересная статья с громким названием – Generate Kyverno Admission Controller Policies with KubeArmor рассказывающая о том, как с помощью KubeArmor можно генерировать политики для Kyverno. Для того чтобы всё заработало нужно:

- установить KubeArmor
- установить PolicyEngine (пока что поддерживается только Kyverno)
- установить Discovery Engine
- выполнить команду karmor recommend -p KyvernoPolicy

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

P.S. – небольшой видео-туториал

Просто великолепная картинка про устройство Low-level container runtime (помним что есть еще и High-level runtime) в Kubernetes с его пошаговым созданием классического контейнера!

Картинка взята с проекта youki, который является как раз Low-level runtime написанном на Rust.

P.S. Также не забываем про этот замечательный материал про runc.

В этот четверг в 14:30 я выступлю на CyberCamp MeetUp: DevSecOps (online, нужна регистрация) с докладом "Классификация и систематизация средств безопасности для Kubernetes".

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

Вышла третья статья [1,2] из серии Container security fundamentals, на этот раз автор затронул тему Capabilities. Из статьи вы узнаете:

- Что такое и зачем нужны capabilities
- Как минизмизировать их для контейнеров
- Как узнать какие capabilities есть в контейнере

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

P.S. – ещё одна статья от этого же автора про использование capabilities со стороны атакующего.