Часто в компаниях, использующих контейнерные инфраструктуры (включая Kubernetes), вижу, что основной приоритет при внедрении безопасности идет на DevSecOps под соусом Shift-left security на базе тех или иных сканеров (SAST/DAST/Images scanner и т.д.). При этом термин Shift-left воспринимают почти буквально и весь приоритет идет на "левую" сторону. А что с "правой" стороной?!

Про все эти сканеры ранней стадии нужно понимать и помнить:
1) Пока вы их настраиваете и внедряете в этот момент ваш прод кластер уже может быть атакован
2) От недобросовестных или неквалифицированных сотрудников, подрядчиков, имеющих доступ в прод, это не оберегает
3) Они далеко не все находят (там хватает ошибок и 1 и 2 рода) - никаких гарантий они вам не дают, 0day уязвимостей никто не отменял
4) Об опасной 1day уязвимости вы можете узнать, когда компонент уже используется в проде и все время что вы будете обновлять вы под угрозой

По этой теме есть классная статья "Is shifting security left a pipedream?" и хочу привести оттуда следующую цитату: "While I consider DevSecOps an eventuality, the realist in me knows that to move security left, you must first improve security on the right."

Если для вас происходящее в контейнерах, в кластерах в динамике одна большая слепая зона, то у вас очень-очень большая проблема. В общем, в погоне за Shift-left security не забывайте о "правой" стороне ;)

Оказывается, далеко не все слышали о "4С" в области Cloud Native безопасности.

А под этим незамысловатым сокращением скрывается:
- Cloud,
- Clusters,
- Containers,
- Code.

Это те слои, о которых стоит думать о безопасности Cloud Native приложений. Об этом можно почитать в официальной документации Kubernetes. Сразу скажу, что сами внутренности данных слоев там расписаны прям очень-очень поверхности. Но общее впечатление для людей вне темы сложить может.
Отдельно стоит на это посмотреть если вы используете management Kubernetes, который на себе берет ответственность как правило за Cloud и части Clusters (возможны правда и свои нюансы) – детальнее смотрите в Shared Responsibility Model вашего облачного провайдера.

В конце прошлого года в Kubernetes было исправлено 2 уязвимости.

CVE-2020-8569: snapshot-controller DoS

snapshot-controller это опциональный компонент и его можно вывести из строя через неавторизованный API запрос, в котором идет ссылка на несуществующий ресурс или ссылка и во все отсутствует. По итогу получаем NULL pointer dereference.


CVE-2020-8570: Path Traversal bug in the Java Kubernetes Client

Уязвимость в Java клиенте, которая при копировании архива из вредоносного Pod (подконтрольного атакующему), может при распаковке привести к перезаписи любого файла доступному пользователю на запись.
Примечательно что уязвимость была найдена CodeQL Automated scanning by GitHub.

Сегодня хотелось бы поднять такой дискуссионный (даже холиварный) вопрос про участие разработчиков в процессах безопасности.

Есть два устоявшихся (уже не знаю сколько лет назад) тезиса, которые можно услышать в большинстве компаний:
1) "Разработчикам безопасность не интересна - они ей заниматься не будут".
2) "Нельзя наказывать разработчиков за уязвимости, так как от них никто не застрахован".

Получаем картину, где у разработчиков нет ни обязанности и ни ответственности...

При этом безопасность это не только (и даже не столько) про поиск уязвимостей. На сегодняшний день контейнеры, Kubernetes и Cloud Native подход к безопасности в целом дают целый спектр инструментов для предотвращения и для обнаружения угроз в момент попытки их реализации. То есть от уязвимостей никто не застрахован, но затруднить их эксплуатацию и помочь обнаружить это малочисленной (как правило) команде безопасности разработчики сегодня могут (на пример, NetworkPolicy, профили поведения ПО для обнаружения аномального поведения –

Магия девяток.

Рад сообщить, что мой доклад "Kubernetes: Трансформация к SecDevSecOpsSec" был принят на конференцию DevOpsConf 2021. Конференция пройдет в offline формате в Москве 30 и 31 мая. Так что будет прекрасная возможность пообщаться лично)

В основном, речь в докладе пойдет о том, как Kubernetes позволяет отлично управлять угрозами (Identify, Protect, Detect, Respond, Recover, Deception) и организовывать эшелонированную оборону. Также затрону: DevSecOps, SSDL, Shift Left/Everywhere Security, OODA, SOAR, ZeroTrust, Self-protecting. Доклад будет полезен как Security специалистам, так DevOps специалистам, работающим с Kubernetes и позволит одинаково видит проблемы, пути решения и возможности этого в Kubernetes.

__P.S. Данный доклад я должен был еще прочитать в конце прошлого года, но мероприятия были отменены.__

В рамках одной из последних встреч CNCF SIG-Security приняли участие люди из PCI Council (PCI - Payment Card Industry) - они на текущий момент создали рабочую группу 2021 SIG: Best Practices for Container Orchestration, рассматривающую стандарты и "best practices" документы в области безопасности контейнеров. Как они сами пишут в своем анонсе: "The goal of the SIG is to provide guidance for companies on how to enhance security when using container orchestration tools in their virtual or cloud infrastructure. This guidance will include an overview of container orchestration tools as well as a breakdown of payment industry considerations for critical components of typical system implementations."

Так что если ваша компания так или иначе связана с PCI, то вам определенна будет интересна эта активность, а если вы QSA аудитор, то можете и принять в ней участие.

Опубликовали 3-Tier Pod Security Proposal и demo прототипа.

Создатели сообщают о том, что они близки к завершению, так что давай те посмотрим, что нас ждет в замене текущей реализации PodSecurityPolicy.
- Применение политик будет завязано на labels на namespace
- 3 режима работы: Enforcing, Audit, Warning
- 3 встроенных профиля (privileged, baseline, restricted) из Pod Security Standards
- Dry-run запуск
- Аудит будет применятся и к templated pod resources, но действовать непосредственно на Pods.

Обратите внимание на раздел Flexible Extension Support, по которому можно сделать вывод, что мы увидим PSPv2 (путь исправления текущих недостатков PSP), а не полный переход на модель сторонних контроллеров типа Kyverno или OPA.

На последней конференции AWS re:Invent 2020 состоялся релиз open source Amazon EKS Distro (EKS-D).

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

Основные преимущества использования, согласно тезисам презентации, обеспечиваются возможностью удобной миграции кластеров (например из тестовой локальной среды on premise на Amazon EKS), наличием необходимых патчей безопасности и совместимости компонентов, а так же расширенной поддержкой версий Kubernetes со стороны AWS, в течении 14 месяцев. EKS-D строится на основе kops, включает etcd & etcdctl, CoreDNS, Upstream CNI, CSI sidecars, aws-iam-authenticator.

С точки зрения пентестера, security специалиста, EKS-D - это отличная возможность потренироваться и локально развернуть свой EKS-кластер для исследований.

На данном канале уже не раз упоминался такой документ от CNCF как Cloud Native Security Whitepaper, в котором есть много категорий инструментов по соответствующей теме. В текущий момент CNCF разрабатывает Cloud Native Security Map (Vanilla), где теперь для каждой из этих категорий приводит перечисления коммерческих и open source проектов. Будем следить за его прогрессом и посмотрим, что из этого выйдет в конечном итоге. Но вы уже сейчас можете посмотреть черновик ;)

Dostainer - Kubernetes Resource Exhaustion PoC Container

Данный проект позволяет исчерпать ресурсы в Kubernetes кластере 3 способами:
- Выделив весь оставшийся RAM на Node
- Выделив все оставшееся место на диске
- Fork bomb

При этом в YAML файле проекта содержаться и меры по предотвращению исчерпания ресурсов и для их применения необходимо их просто раскомментировать.

Как и для чего может быть полезен данный проект?)

1) Наглядно продемонстрировать коллегам необходимость использования лимитов в YAML ресурсах приложений.
2) Проверить все ли у вас корректно настроено в мониторинге и сможет ли SRE заметить такую проблему и быстро ее обработать.
3) Проверить как поведут ваши приложения (и кластер) если окажутся на Node с таким вот контейнером - некоторый такой элемент chaos engineering.
4) Департаменту безопасности обновить сигнатуры вредоносных образов контейнеров ;)

В комментариях предлагайте свои варианты использования!

AWS анонсировал релиз ECS Exec для EC2 и AWS Fargate
ECS Exec - возможность запустить интерактивный шелл на EC2 и Fargate, под капотом автоматически монтируемый том c бинарями SSM agent, который обеспечивает необходимую коммуникацию с контейнером.

С точки зрения безопасности, доступ определяется IAM политикой ecs:ExecuteCommand, в контексте users/groups/IAM roles для всего кластера или конкретного контейнера. ECS Exec поддерживает Amazon CloudWatch и CloudTrail для мониторинга и логирования выполняемых команд и S3 для хранения архивов. Коммуникация между ECS Exec и контейнером зашифрована с помощью TLS1.2 по умолчанию, так же можно использовать собственный KMS ключ.

К тому же, стоит отметить что ранее совсем не было возможности делать exec-ing для контейнеров запущенных на AWS Fargate - легковесной fully managed microVM на основе firecracker. (об этом мы уже писали) Поэтому, кажется, что ECS Exec будет довольно востребованной фичей, при условии и соблюдении принципов least privilege при конфигурации IAM.

4 мая в рамках Virtual KubeCon + CloudNativeCon Europe пройдет очередной Cloud Native Security Day.

Уже сейчас доступно расписание данной секции. В докладах будут рассмотрены и затронуты такие темы:
- Безопасность Open Source кода (разработка, проверка, распространение - в общем весь supply chain)
- Как WebAssembly может быть использован для написания Kubernetes admission политик
- Как eBPF инструменты могут помочь при решении threat detection задач в Kubernetes окружении
- Как Hierarchical Namespace Controller (HNC) и `Kyverno могут вместе помочь реализовать “namespaces-as-a-service”
- Проблемы расследования инцидентов в Cloud Native окружениях
- Представят новый фреймворк для оценки рисков в Kubernetes на базе CIS benchmarks и матрицы MITRE ATT&CK для containers/Kubernetes


Также будет Capture The Flag в Kubernetes окружении!

Из рубрики наблюдений. Заметил, что очень много людей пытаются начинать строить безопасность Kubernetes сразу исходя из пунктов различных документов best-practices.

Мое мнение, что нужно идти от себя, от собственных рисков, моделей нарушителей, моделей угроз и т.д., в общем со знанием дела что и для чего вы меняете/добавляете, а не от общепринятых практик, которые могут быть лишь ориентиром для вас. Некоторые и них могут вам не подходить, даже может что-то ломать (нужно помнить о Dev, Ops команд) и уж точно не учитывать ваши особенности. Не говоря, что уже есть собственные финансовые, временные, человеческие, процессные ограничения и особенности.

Со временем, опытом и знанием вы точно придёте к тому что из этого списка best-practices вам актуально и вы будете их отслеживать и контролировать.

Тема создания Network Policy в Kubernetes не такая простая как кажется на первый взгляд. Недавно авторы CNI Cilium создали проект NetworkPolicy Editor, который позволяет создавать, визуализировать и делится сетевыми политиками в online формате на странице https://editor.cilium.io/.

Отдельно отмечу правый нижний угол, где есть 6 полезных туториалов с теорией. Если вам этого недостаточно, то посмотрите вебинар "Demystifying Kubernetes Network Policy".

А если и этого недостаточно, то сегодня в 20:00 (Мск) можно посмотреть по данной теме и технический тренинг "Securing Kubernetes w/ Network Policies", где также будут покрыты темы CNI Cilium и eBPF.

Статья "Using Kubelet Client to Attack the Kubernetes Cluster".

Данный материал хорошо раскрывает аспект безопасности Kubernetes кластера со стороны его компонента под названием kubelet. Этот компонент присутствует на каждой Node и является связующим звеном между Kubernetes API и Container Runtime.

В статье рассматриваются такие моменты как:
- Описание целей и задач kubelet
- kubelet API с его недокументированными возможностями
- Утилита kubeletctl, очень полезная при pentest
- Слабые настройки kubelet, которые могут приводить к удаленным атакам на кластер
- Пути повышения безопасности для kubelet

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

Спустя год Microsoft обновила матрицу Adversarial Tactics, Techniques & Common Knowledge (ATT&CK) для Kubernetes, актуализировав и дополнив ее с учетом новых угроз и изменений в Kubernetes.

Убрали:
- Техники связанные с Kubernetes Dashboard (если k8s у вас старый, то это еще актуально)
- Технику с Tiller endpoint от Helm 2 (если у вас не Helm 3, то еще актуально)

Добавили:
- Exposed sensitive interfaces — это когда привилегированные сервисы без аутентификации для всех желающих выставляют
- Sidecar injection - техника выполнения своего кода без порождения новых подозрительных Pods
- Malicious admission controller - закрепление в системе по мотивам вот этого доклада
- Access managed identity credential - про доступ к Instance Metadata Service (IMDS)
- CoreDNS poisoning - название говорит само за себя, а атака идет на его ConfigMap
- ARP poisoning and IP spoofing - живее всех живых в 2021
- Images from private registry - техника из добавленной тактики Collection

Не думал, что когда-нибудь пересекусь с Vmware Tanzu, но в итоге пришлось. Для тех, кто не знает это Cloud штука от Vmware с поддержкой Kubernetes со множеством имен:
- Project Pacific
- vSphere with Kubernetes
- VMware Tanzu Kubernetes Grid (TKG) и VMware Tanzu Kubernetes Grid Integrated Edition (TKGI)
- + различные редакции Basic/Standart/Advanced

Может еще как-то и что-то - может где-то и ошибся, но разобраться с тем, что понаписал их маркетинг не просто.

Из интресного:
1) Как и в OpenShift (речь о project), тут namespace это security boundary
2) Основной Container Runtime это MicroVM (а не контейнер) под названием CRX (Сontainer Runtime eXecutive). Это такая мини-виртуальная машина с ядром Linux внутри (на базе ответвления Photon OS). При этом Pod под таким управлением называется Native Pod или vSphere Pod. Поддержка Open Container Initiative (OCI) в наличии
3) Работа сети лежит на NSX-T

Было бы интересно послушать людей кто работал с этим решением.

Сегодня рассмотрим сервис AWS IAM, как основной инструмент для аутентификации и авторизации AWS EKS.
Для аутентификации EKS использует Webhook Authentication Token, API-серверу передаётся специально сформированный токен, в котором передаётся идентификатор ARN (Amazon Resource Name) IAM-пользователя/роли.

Далее API-сервер, с помощью AWS IAM Authenticator обращается к сервису AWS IAM, который проверяет имеет ли данный пользователь права обращаться к кластеру AWS EKS, сравнивая ARN запроса с ARN mapRoles в aws-auth ConfigMap.

После того, как пользователь прошёл аутентификацию, Kubernetes должен c помощью Role Based Access Control проверить сам запрос — есть ли у данного клиента право на выполнение запрошенных действий, например — выполнение вызова kubectl get pods. Так же для аутентификации AWS EKS в качестве альтернативы может использоваться OpenID Connect (OIDC).
Таким образом, при условии грамотной конфигурации, AWS IAM представляет собой мощный инструмент для обеспечения безопасности AWS EKS.