Наконец-то мои руки дошли до новых сетевых фишек/реализациях в Kubernetes, а если быть более конкретным то до двух проектов: Cilium Service Mesh и Istio Ambient Mesh. При этом хотелось с ними познакомиться параллельно, чтобы можно было производить сравнение их фич и подходов.

Начнем прям с очень верхнеуровнево сравнения:
- L4 в первом реализуется на eBPF, второй в компоненте ztunnel (есть также планы переноса в eBPF) - все катиться как DaemonSet
- L7 в первом реализуется в envoy из того-же DaemonSet, второй при необходимости может создать Waypoint proxy (под капотом envoy) на service account или на namespace

Видим что sidecar пропали. Но разработчики Istio говорят что sidecar-реализация продолжит развиваться и поддерживаться и совместима (насколько я понял) с новой реализацией - тоесть одновременно можно как использовать sidecar, так и нет.

Offensive инструментов для Kubernetes выходит не так много, так что как только я заметил его – не сразу решился рассказать о нём, а для начала попробовать его в деле. Сегодня речь пойдет о KubeDagger.

Сама тулза основана на ebpfkit – руткит, написанный на eBPF и предоставляющий огромные возможности для атакующего: obfuscation techniques, container breakouts, persistent access, command and control, pivoting, network scanning, Runtime Application Self-Protection (RASP) bypass. Более подробно о том как это работает авторы рассказали в своем докладе.

Но на самом деле не всё так радужно. Так и не понятно как его позиционируют сами авторы. Для работы большинства функционала нужен ряд capabilities – CAP_SYS_ADMIN, CAP_SYS_RESOURCE, CAP_NET_ADMIN и shared network namespace.

Часто такое встречаете в контейнере? Лично я нет.

Наш канал k8s (in)security сегодня отмечает День Рождение - 3 года !!!

Уже 3 года мы стараемся каждый будний день (хотя бы раз в день) Вас радовать/информировать/просвещать в вопросах информационной безопасности контейнеров, Kubernetes, DevSecOps. И просто делиться опытом и знанием нашей команды Luntry в этой области: как в разработке, защите, так и атаке!

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

P.S. А у меня так вообще двойной праздник в этот день - также 2 года исполняется моему сынишке с чем я его и поздравляю =)

Эту неделю начинаем со статьи – Enhancing Kubernetes Security with Kyverno, RuntimeClass, and Kata Containers. В ней автор показывает как с помощью связки Kyverno[1], Kata containers[2] и RuntimeClass[3] можно повысить безопасность кластера Kubernetes.

Ещё по отдельности эти технологии обладают довольно мощным функционалом для security, но объединив их всех вместе можно получить ещё больше профита:

– Enhanced Security
– Greater Flexibility
– Developer and User Productivity

В конце статьи, в качестве примера приводятся две политики для Kyverno. Первая – mutate политика, принудительно проставляет kata RuntimeClass всем Pods запущенным в namespace test. Вторая – проверяет что все Pods с privileged или runAsRoot securityContext, используемые в namespace kube-system деплоятся через kata RuntimeClass.

Продолжаем тему сравнения Cilium Service Mesh и Istio Ambient Mesh.

Если обратить внимание на функциональные возможности, то они практически идентичные. Уверен, есть какие-нибудь нюансы, но и по структуре того где на каком уровне (L7,L4) что реализуется даже сходится. При этом оба на L7 используют Envoy как мы с вами знаем. Скорее отличия будут на L4.

Если вы уже эту тему копали вглубь, то делитесь в комментариях!

Kubernetes Network Policies Viewer – небольшой онлайн-инструмент, который может пригодиться во время ручного написания Network Policy для Kubernetes.

Да, инструмент сильно похож на Cilium Editor (о котором мы уже рассказывали), но и свои отличительные особенности у него есть. Тулза выдаёт наглядное представление о том, как будет работать описанная Network Policy. Бывает очень полезной, когда нужно проверить правильность работы множества сетевых политик.

Из минусов – поддержа только Native Network Policy и отсутствие возможности генерировать сетевые политики простым накликиванием (как это сделано в Cilium Editor).

В эту пятницу 31 марта выступлю на конференции True Tech Day (offlinе + online) от компании МТС в секции Cybersecurity с докладом "Безопасность контейнеров и Kubernetes".

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

Преза будет небольшой, но я там наконец визуализировал одну важную вещь по безопасности образов контейнеров, которой прям не терпится поделиться!

В рамках изучения Cilium Service Mesh и Istio Ambient Mesh (прошлые посты 1,2) я наткнулся на занимательную статью "Exploring Cilium Layer 7 Capabilities Compared to Istio". Там сравниваются не Service Mesh реализации, а L7 возможности стандартного CNI Cilium (v1.12) и sidecar реализации Istio. И из этой статьи можно узнать много всего интересного о деталях реализации CNI Cilium и Istio, а именно:
- L7 фильтрация в ресурсе CiliumNetworkPolicy реализована как расширение/фильтр (Cilium.L7Policy) для Envoy proxy
- Как выглядит/хранится L7 правило внутри CNI Cilium
- CNI Cilium использует для этого Envoy filter, а Istio использует RBAC filters из апстрима Envoy
- чем является identity в Cilium, как он вычисляется (база это IP, labels) и хранится (это никакой не криптографический приметив, а просто целое число). А в Istio для этого служит service account token - там вообще все сроиться вокруг сертификатов, что как вы понимаете надежнее

Также там поднимается вопрос/проблема, что при модели Envoy per Node ресурсов потребляется меньше, но в случае его отказа страдают сразу все микросервисы на Node. Есть и еще одна интересная проблема с Network cache-based identity, что как я написал выше используется в Cilium, но это заслуживает отдельной заметки ;)

На канале мы уже затрагивали [1,2] тему Kubernetes Validating Admission Policies, но сегодня появился еще один повод. В официальном блоге Kubernetes вышла статья – Kubernetes Validating Admission Policies: A Practical Example.

Несомненным плюсом данного механизма является то, что для валидации данные не отправляются на admissions webhook (как например это реализовано в OPA или Kyverno, или в любом другом Policy Engine), а сразу обрабатываются, под капотом Kubernetes. Ну и конечно же CEL, в качестве языка описания выражений для проверки будет сильно проще в понимании и освоении, чем Rego (тот, что используется в OPA Gatekeeper).

Для более детального погружения в тему советую ознакомиться с видео – Kubernetes Validating Admission Policy Changes The Game. В нём автор показывает практические примеры использования данной технологии, а также рассматривает её недостатки и преимущества.

В статьей "Could network cache-based identity be mistaken?" авторы демонстрируют проблему network cache-based идентификаторов, на примере, идентификатора который используется CNI Cilium и применяется для контроля NetworkPolicy. По итогу у них получается сделать так что NetworkPolicy применяется к микросервису не правильно и обходится!

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

Все это может быть из-за не актуального состояния кэша, которое может быть связано с сетевыми проблемами:
- Network outage
- Cilium pod was down, during an upgrade
- Resource constraints that cause the agent to be slow
- Resource constraints that cause API server to be slow in sending pod events to Cilium pod
- Programming bug that cause the agent to crash
- и т.д.

P.S. Я думаю это открывает достаточно интересный простор для исследования =)

Те, кто использует Vault знают, что есть два способа интеграции с Kubernetes:

1) Agent Injector (через sidecar-контейнер)
2) Vault CSI Provider

С недавнего времени появился третий, самый что ни на есть Kubernetes-native подход – с помощью Vault Secrets Operator и его CRD. Vault Secrets Operator работает, отслеживая изменения в CRD. Каждый CRD предоставляет спецификацию, необходимую для того, чтобы Operator мог синхронизировать секреты хранилища с секретом Kubernetes. Затем Operator записывает данные из хранилища непосредственно в целевой Kubernetes Secrets. В целом, плюсы со сравнению со старыми способами следующие:

- Workloads can mount Kubernetes secrets without adding any Vault-specific configuration.
- Secrets are synced per CRD instead of per consuming pod.
- Kubernetes secrets act as a durable cluster-local cache of Vault secrets.

Vault Secrets Operator находится в public beta и доступен только в последней версии Vault.

"Container and image vocabulary" - классная визуализация и простое объяснение основных терминов в области контейнеризации.

Самое то, если вы делаете первые шаги в данной области.

- Спокойно запускаете DEV и PROD окружения в одном кластере?
- Уверены что ваши namespaces хорошо изолированы друг от друга?
- Собственными руками организовали multitenancy уровня Namespaces as a Service?

Специально для проверки качества таких реализаций и был создан Multi-Tenancy Benchmarks. А к нему в придачу для автоматизации проверки плагин для kubectl под названием kubectl-mtb.

Так все проверки разбиты на 2 класса:
- Configuration Checks (CC)
- Behavioral Checks (BC)

К сожалению, 7 проверок из 23 так и не автоматизировали. НО их можно подсмотреть в документации проекта Capsule и дописать или сделать ручками ;)

Мы уже не раз рассказывали [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, а также хранение секретов в соответствии с облачной спецификой.