k8s (in)security

В начале новой недели с удовольствием поделимся с вами слайдами с выступления "ZeroTrust в Kubernetes:Не пустые слова" нашей команды Luntry с одного из последних мероприятий!

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

Всем хорошей недели!

Закончим эту неделю смешным постом от организаторов конференции "Стачка", где выступал наш коллега Андрей Ганюшкин с докладом про безопасность контейнеров)

Классно, креативно =)

Reflector - это Kubernetes operator, предназначенный для мониторинга изменений в ресурсах (Secrets и ConfigMaps) и отражения изменений на зеркальных ресурсах в том же или других namespaces.

Для того чтобы указать источник (откуда будут скопированы данные) нужно добавить аннотацию вида reflector.v1.k8s.emberstack.com/reflection-allowed: "true" и reflector.v1.k8s.emberstack.com/reflection-allowed-namespaces: "<list>" к ConfigMaps или Secrets

Если источник удален, то удаляются и автоматические зеркала. Также если отражение или автоматическое зеркалирование отключены или namespace автоматического зеркала больше не соответствует разрешенным namespace, автоматическое зеркало удаляется.

Оператор будет полезен как минимум при решении двух задач:

- Для обеспечения TLS в динамических окружениях проектов необходимо выписывать сертификат для ветки main каждого проекта и копировать Secret во все остальные неймспейсы этого проекта
- Уметь автоматически синхронизировать Secret из централизованного хранилища во все нужные Kubernetes-кластеры и выбранные внутри них неймспейсы.

Microsoft обновила "Threat matrix for storage services". Первая версия вышла 2 года назад и обновление получило много изменений и заслуживает внимания.

Недавно встретили такое требование в DevSecOps концепции одной компании, которое звучит примерно следующим образом: "Автоматический запрет развертывания образов с определенными CVE и секретами". И если про проблемы с первым мы уже не раз писали и рассказывали [данный пост и в вебинаре "Patch management не поможет, фиксики не спасут"], то второй момент это что-то новое, что мы ранее не встречали. Давайте разбираться - имеет ли это какой-то смысл.

Если в образ попал секрет и этот образ уже лежит в registry, то можно уже констатировать факт, что секрет утек. Ведь все сотрудники, что могут пулить образы могут забрать как весь образ так и его конкретный слой. А в последствии извлечь все необходимое. То есть организовать такой канал утечки данных (помните о registry staging). Контроль этого в моменте развертывания, это какой-то узкий кейс, не решающий основную проблему, и несущий угрозу только в том случае если в образ потом кто-то попадет из вне. Плюс все те же проблемы, что и с CVE, которые могут привести к падению системы.

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

Kubernetes может быть не только в контексте серверных приложений, но и безопасности рабочих мест пользователей!

Проект kVDI это Virtual Desktop Infrastructure запущенная на Kubernetes. Возможности:
- Контейнерезированный пользовательский "desktops" без требований к виртуализации
- Шифрование трафика между конечным пользователем и "desktop" контейнером
- Возможность персистентности пользовательских данных
- Поддержка воспроизведения аудио, микрофона
- Передача файлов с/на "desktop" сессию
- RBAC система для мапинга пользовательского доступа
- Поддержка MFA
- Использование локальной аутентификации, LDAP или OpenID
- UI для управления системой

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

P.S. И да, компании уже сейчас начали пилотировать такой подход у себя ;)

21 сентября на онлайн-конференции про IT-инфраструктуру для бизнеса Selectel Tech Day наша команда в лице Дмитрия Евдокимова представит доклад “ZeroTrust в Kubernetes: Не пустые слова”. Там рассмотрим насколько сложно или не сложно построить ZeroTrust в Kubernetes c примерами атак и защиты.

Регистрация на мероприятие бесплатная.

На прошедшей в августе конференции OFFZONE был доклад, который мы не могли оставить без внимания – Как скрыть свои действия, когда отслеживается каждый шаг (Иван Гаврилов, Innostage).

В своем докладе Иван рассмотрел сильные и слабые стороны технологии eBPF для задач безопасности, а также возможные методы сокрытия своих действий на примере существующих eBPF‑based-инструментов безопасности для Kubernetes – Tetragon и KubeArmor.

Как итог – автору удалось обойти обнаружение всех видов событий (процессы, файловые и сетевые) при определенных условиях:

- передача в качестве аргумента utf-8 символа
- запуск бинарника с большим путём
- запуск процесса с большим количеством аргументов

Также автор поделился инструментами, которые он написал для своего исследования. Их можно найти по ссылке тут. Кстати, слайды презентации можно найти здесь, а видео с выступления тут.

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

Встречайте MagicHappens Kubernetes Operator!

Его идея до безобразия просто и беспощадна: в CustomeResource (тоесть в YAML) в текстовом поле описываем человеческими словами какие Kubernetes ресурсы мы хотим получить и все. Далее это попадает OpenAI (под капотом еще есть проект Kopf) и результат уже в Kubernetes API.

Для полной завершенности проекта на наш взгляд еще не хватает распознавания речи, чтобы это CustomeResource не вбивать в ручную, а надиктовывать системе ;)

P.S. "Создай Deployment для образа registry.corp.ru полностью соответствующий требованиям Pod Security Standard и с установленным default seccomp profile" - как-то так джун DevOps будет работать в будущем!

P.S.S. Мидл DevOps результат полученный на предыдущем шаге отправит на проверку другой AI системе ;)

Вчера прошла онлайн конференция eBPF Summit 2023. Программа конференции достаточно обширная, но если говорить про security доклады, то это:

- Minifying Containers with SlimToolkit and eBPF Leveraging Tetragon's File System Activity Tracing
- Detecting and Preventing Stack Pivots in Linux Userland Programs Using eBPF
- How to use eBPF as a solution to Observe and optimize applications for endpoint security

Вместе с тем, на eBPF Summit 2023 проходит CTF. Если вы хотите порешать таски, можно поднять их локально у себя отсюда.

Сами доклады уже доступны, запись трансляции можно посмотреть здесь.

В нашем решении компонент сенсора (у нас собственная разработка, а не какой-то OpenSource проект) использует данную технологию и наша команда с большим интересом следит за данным мероприятием!

"Container security fundamentals part 6: seccomp" – шестая статья из цикла статей [1,2,3,4,5] про безопасность контейнеров от Rory McCune.

В ней рассматривается как с помощью seccomp фильтров (они кстати написаны на BPF) можно ограничить какие системные вызовы (syscalls) можно вызывать из контейнера, а какие нет. Тоесть этот механизм у нас больше не про изоляцию одних процессов на хосте от других, а про изоляцию контейнерных процессов от хоста. Это на пример поможет позволить не совершить легкий побег из контейнера! На скрине пример с unshare, о котором мы уже не однократно рассказывали.

Мы продолжаем активно развивать тему безопасности контейнеров и Kubernetes. И в этот раз 15-16 сентября в Ульяновске в рамках международной IT-конференция “Стачка” наш коллега Андрей Ганюшкин (да, наш коммерческий директор тоже разбирается в безопасности кубов) простым языком для широкой аудитории представит доклад: “Контейнеры и Kubernetes: не боимся, а используем и защищаем”. Он расскажет об отличии контейнеров от виртуальных машин, затронет тему оркестрации и объяснит, как “видят” контейнерные среды государственные регуляторы (PCI DSS, 118 приказ, ГОСТ 57580.1-2017) и, конечно, о специфике безопасности Kubernetes RBAC, NetworkPolicy и Kubernetes-ресурсов упомянуть не забудет.

У нас отличные новости для всех, кто готовится к экзаменам CKA, CKAD и CKS или просто хочет освоить Kubernetes. Подписчик нашего канала создал совершенно бесплатную open-source платформу, которая делает подготовку максимально удобной.

Возможности платформы:

- Создание всех необходимых ресурсов (VPC, subnets, EC2) автоматически.
- Настраивайте кластеры под различные сценарии в несколько кликов.
- Эквивалент killer.sh, но абсолютно бесплатно.
- Возможность легко добавлять свои собственные сценарии.
- Тесты для проверки правильности выполнения заданий.
- Контроль времени для максимально реалистичных мок-экзаменов.

На данный момент доступны сценарии:

- CKA mock экзамена
- CKS hands-on lab
- CKS mock экзамена

Ссылку на GitHub можно найти тут, а видео с примером запуска CKA mock экзамена тут.

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

Не давно к нам на глаза попался оператор namespace-configuration-operator, разработанный командой RedHat. Он позволяет: "create rules that will react to the creation of Users, Groups and Namespace and will create and enforce a set of resources." То есть упростить onboarding процесс для пользователей, групп или неймспейсов. Для этого в нем есть такие CustomResources как UserConfig, UserConfig, NamespaceConfig, которые описывают правила при совпадении с которыми автоматом появляются описанные в них ресурсы.

В документации есть 2 примера, для разных сценариев:
1) developer sandbox
2) team onboarding с поддержкой всего SDLC в multitentant окружении

Таким образом удобно автоматом накидывать определенные ограничения как ИБ, так и ИТ. Опытный читатель может заметить пересечение с проектом HNC и ему подобными, завязанными на мультитенантность.

Такой подход можно подсмотреть для собственного оператора, особенного если вы внутри совей компании строите свою платформу на базе Kubernetes ;)

eBPF программы однозначно стали новым трендом – они помогают повысить уровень observability и security, нередко их можно встретить и у Kubernetes Secuity вендоров. Но помимо очевидных плюсов, которые привносит eBPF, также не стоит забывать и про угрозы, которые они могут принести. Статья eBPF Offensive Capabilities – Get Ready for Next-gen Malware от Sysdig как раз про это.

Авторы выделили четыре eBPF offensive capabilities:

- Abusing direct map access
- Abusing Kprobes
- Abusing TC hook
- Abusing Uprobes

Для каждого из векторов они приводят рабочий код, а также возможные меры prevention. Если говорить о глобальных способах митигаций даннного направления, то это ограничение capabilities SYS_BPF для root юзера.

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

Совсем недавно обновился интересный проект за которым мы с удовольствием наблюдаем и возможно кому-то даже для решения каки-то специфичных, узких задач даже и подойдет. Речь идет о Usernetes, который представляет из себя Kubernetes без root привилегий. Проект похож на Rootless kind и Rootless minikube, но в отличии от них он поддерживает создание кластера с множеством нод.

Самая идея и фича крутятся вокруг KEP-2033: Kubelet-in-UserNS (aka Rootless mode).

K8s Network Policy Migrator – это инструмент для миграции кастомных сетевых политик Calico или Cilium в нативные сетевые политики Kubernetes. Инструмент предлагает такие возможности, как предварительные проверки, сбор и преобразование политик, а также удобные опции проверки, применения, отката и очистки.

Будет полезно, если вы переезжаете в кластер, где в качестве CNI используется не привычный вам Calico или Cilium, а что-то другое, но наличие NetworkPolicy очень необходимо.

Само собой, тулза способна конвертировать только тот функционал, который есть и в кастомоных и в нативных политиках. FQDN, L7 и Host политики она не поддерживает, точно также как и привязку по Service name, Service Account и прочему... Наверное, в качестве инструмента для миграции стоит также упомянуть NetworkPolicy editor от Cilium – там можно создать Cilium политику и перевести её в Native. О нём мы уже как-то рассказывали на канале.

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

Безопасность Linux контейнеров (да, есть и Windows реализация [1,2,3]) неразрывно связана с безопасностью ядра Linux. И по этому вопросу есть два великолепных ресурса от Александра Попова и Андрея Коновалова соответственно:
- Linux Kernel Defence Map
- Linux Kernel Exploitation

Отличные ресурсы, чтобы погрузиться в kCTF и kernelCTF ;)

Рады поделиться записью нашего вебинара "Patch management не поможет, фиксики не спасут", который мы проводили на прошлой неделе! Так что если вы по тем или иным причинам не смогли на нем присутствовать, то теперь можно спокойно посмотреть, оставить обратную связь и задать свои вопросы ;)

Начнем эту неделю с образовательной темы по работе Kubernetes, а именно с ответа на вопрос "Where does the kubelet mount volumes?".

Краткий ответ /var/lib/kubelet/<pod-id>/volumes/.

А более подробный - в рамках данной стать ;)

Самому автору понадобилось это из-за:"Recently, I was troubleshooting an issue where some files were being mounted as a volume to a container in a Pod on a Kubernetes cluster. The volume appeared to be mounted successfully, but the container was failing to authenticate with credentials that should have been present in the mounted directory."

Так при прочтении ее всегда давайте себя отчет в том что все показывается на kind кластере с его спецификой.