Вышла статья "Container security fundamentals part 2: Isolation & namespaces" из цикла о котором я писал ранее. Опять же тут про базу - без которой никуда ... И на этот раз она посвящена всем имеющимся на текущий момент Namespaces и какую они роль играют в вопросе изоляции.

21 марта в Москве в онлайн и офлайн форматах пройдет VK Kubernetes Conf!

Как обычно среди докладов там будем много интересного как про сам Kubernetes, так и про его безопасность.

Я там также поучаствую в рамках кругло стола, где мы пообсуждаем «Тренды в разработке и безопасности». Скорее всего зароним там темы eBPF и WebAssembly как альтернативу docker контейнерам.

Ссылка на регистрацию тут.

P.S. Мое выступление с VK Kubernetes Conf 2021 можно посмотреть тут.

Top 10 most used policies for Kyverno – подборка самых популярных и часто используемых политик Kyverno. Несмотря на то, что Kyverno является маленьким кусочком в большом пазле (фреймворке) под названием Kubernetes, и в зависимости от окружения политики могут быть разными, вот некоторые из наиболее распространненных политик, которые часто используются в коммьюнити:

– Resource limits
– Namespace isolation
– Security context
– Image policies
– Network policies
– Labeling
– Pod affinity/anti-affinity
– Secrets management
– RBAC policies
– Compliance

Если вы хотели подробней узнать о Kubernetes SeriviceAccount Token, то эта статья для вас. В ней рассматриваются следующие аспекты:

– ServiceAccountToken это всего лишь JWT
– ServiceAccount Token Process Flow – как токен назначается и монтируется внутрь Pod
– Headers, Content и Signature – из чего состоит токен

Важно отметить, что начиная с версии Kubernetes 1.24 токены для Service Account не генерируются автоматически. Для их создания нужно использовать TokenRequest API.

О том, что может делать атакующий с правами на создание TokenRequest мы рассказывали ранее.

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

Всю прошлую неделю гремел кейс Dero Cryptojacking связанный с Kubernetes [1]. Как по мне там чего-то такого особо интересного нет - много где можно с этим ознакомиться...

НО извлечь урок и понять (еще раз) угрозу анонимного доступа (anonymous access к Kubernetes API) (через который атака и прошла) можно. Именно этому и посвящена статья "Let's talk about anonymous access to Kubernetes". А именно:
1) Принцип работы и назначение
2) Отключение данного доступа

Несколько дней назад было опубликовано три уязвимости в CNI Cilium:

1. Cilium-agent container can access the host via `hostPath` mount – если у атакующего существует возможность изменять используемые images в Workloads, подменив image в cilium-agent, он может получить доступ к директории /opt/cni/bin на Node через hostPath.

2. Cilium eBPF filters may be temporarily removed during agent restart – во время рестарта агента Cilium есть небольшой промежуток времени, когда eBPF функционал недоступен. В этот момент злоумышленник, например, обойти Network Policy.

3. Potential network policy bypass when routing IPv6 traffic – при определенных условиях Cilium может ошибочно присвоить source IP-адрес кластеру, идентифицируя внешний трафик как исходящий от хоста, на котором работает Cilium. Как следствие, это может привести к обходу Network Policy.

Уязвимости затграгивают разные версии, необходимые патчи уже выпущены. Самое время обновиться.

Наконец-то мои руки дошли до новых сетевых фишек/реализациях в 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" - классная визуализация и простое объяснение основных терминов в области контейнеризации.

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