Мы уже не раз рассказывали [1,2] про сторонние сервисы, которые могут помочь при написании Network Policy для Kubernetes. Но сегодня я хочу поделиться личным опытом – недавно я воспользовался помощью Github Copilot для создания сетевых политик и был приятно удивлён результатом!

Если вы создаете сетевые политики в директории с другими Kubernetes Resources, то Copilot понимает контекст и сразу начинает предлагать вам правильную политику (причём без указания prompt, просто нажимая TAB) с нужными лейблами и портами, что очень удобно. Причем неважно какая политика – Native, Calico или Cilium.

Безусловно, AI очень крутой помощник, но перепроверять его работу всё-таки стоит =)

Мы очень рады анонсировать нашу конференцию!

БЕКОН - техническая конференция по БЕзопасности КОНтейнеров и контейнерных сред

Дата и место: 7 июня 2023 года в Москве

Целевая аудитория: Архитекторы, Инфраструктурные и платформенные команды, DevOps/DevSecOps, ИБ департаменты.

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

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

P.S. Обратите внимание, что зал небольшой - билетов совсем немного!

P.S.S. С автором названия связались и все подарки будут переданы лично =)

В след за Kubernetes threat matrix компания Microsoft выпустила DevOps threat matrix.

Похожую матрицу делали исследователи в работе "Attacking and Securing CI/CD Pipeline", так что если вам тема интересна - рекомендуем освежить в голове и эту работу 2021 года.

Проект wrongsecrets от организации OWASP на примере 28 challenges покажет как НЕ НУЖНО хранить свои секреты.

Задания можно поднимать как локально (docker, minikube), на ванильном Kubernetes, так и в облаке (AWS, GCP, Azure). Отдельно отмечу, что в тасках фигурирует использование Vault, а также хранение секретов в соответствии с облачной спецификой.

На этой неделе мы опубликовали детали 6 докладов что будут представлены у нас на конференции БЕКОН:
- "OPA с shared Docker executor", Павел Сорокин (OZON)
- "Не такой очевидный RBAC Kubernetes", Дмитрий Евдокимов (Luntry)
- "Distroless своими руками", Антон Мокин (Тинькофф)
- "Как правильно готовить Kyverno и работать с его алертами", Алексей Миртов (Yandex Cloud)
- "Kubernetes, ответь мне, кто я для тебя?", Константин Аксенов(Флант)
- "K8s в PCI DSS", Александр Маркелов (Райффайзен Банк)

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


Билеты можно приобрести тут.

Недавно наткнулся на заметку "Let's talk about Kubelet authorization", посвященную Kubelet authorization. Основной сценарий тут крутится вокруг того, что атакующий может тем или иным способом попасть на Node и завладеть кредами kubelet, которые он использует для общения с Kubernetes API Server, для поднятия привилегий и распространения атаки.

Из интересных/важных моментов:
- Команда kubectl auth can-i --list покажет только права выданные RBAC, а другими authorization modes отображены не будут (а нам тут интересен режим Node authorizer), но их можно индивидуально проверить с помощью kubectl auth can-i
- Проверьте на своих кластерах что данная настройка для kube-apiserver выставлена именно так --authorization-mode=Node,RBAC, что работал и RBAC и Node authorizer
- Отказ в режиме авторизации Node, означает что запрос передается на режим RBAC и он уже там может быть разрешен. На пример, путем накидывания прав на группу system:node
- Обязательно Node authorizer должен работать в связке с NodeRestriction Admission Controller
- Все эти права могут меняться от дистрибутива к дистрибутиву, от инсталляции к инсталляции, так что всегда стоит проверять этот момент.

Но для полноты картины в данной теме я бы порекомендовал ознакомиться с исследованием "Kubernetes Control Plane Vulnerability Assessment", о котором мы писали ранее - там раскрыто намного больше деталей.

В эту пятницу мы с нашей командой вместе с этим замечательным стендом будем представлены на CISO Forum.

Если вы или ваши коллеги будут на данном мероприятии - подходите, мы с удовольствием пообщаемся на тему безопасности контейнеров, Kubernetes и расскажем про наш Luntry!

Несколько дней назад релизнулся Kubernetes v1.27 под кодовым названием Chill Vibes. Обновления по части security следующие:

1) Kubelet seccomp by default. Фича перешла в stable в этой версии. Позволяет по дефолту применять seccomp profile для каждого Workload, запускаемого в кластере.

2) User namespaces. Фича перешла в alpha в этой версии. Благодаря user namespaces процесс может быть запущен от root, при этом фактически не будет иметь доступ к хосту.

3) Accessing node logs via kubectl. Теперь админы кластера могут получать логи с Nodes через Kubernetes API. Это безусловно помогает повысить безопасность кластера, уменьшая необходимость ручного подключения к Nodes через SSH.

4) Self user attributes. Новый API endpoint, который позволяет пользователю идентифицировать самого себя, что поможет определить какие RBAC правила на него наложены.

5) Kubernetes CVE Feed. Сам фид был обновлен для полной поддержки спецификации JSON.

P.S. – список всех нововведений в 1.27 можно посмотреть тут.

Продолжаем [1,2,3] рассматривать тему sidecar-less архитектур Service Mesh. И сегодня у нас две занимательные статьи:
1) "The Future of Service Mesh is Networking"

Основной вывод: "The future of service mesh is as a networking feature, not a product category"

Также от сюда можно узнать о проекте Merbridge, который использует eBPF для ускорения service mesh (Есть поддержка: Istio, Linkerd2, Kuma).

2) "The Future of Istio: Sidecar-Less and Sidecar with Ambient Mesh"

Хорошо иллюстрированная заметка об Ambient Mesh.

Публикуем еще 2 доклада из программу нашей конференции БЕКОН (за деталями на сайт):

- "Как приручить Linux capabilities в Kubernetes", Николай Панченко (Тинькофф)
- "AppArmor и Kubernetes: настройка проактивной защиты для безопасности приложений", Сергей Канибор (Luntry)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Стал доступен "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 есть такое пристальное внимание со стороны ИБ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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