Вернемся к теме «Нужно ли разработчику знать Kubernetes». Общаясь с компаниями, использующими Kubernetes (и не только), повсеместно наблюдаю такую картину, что специалистов по ИБ в разы меньше (естественно), чем людей, занятых в разработке и поддержки. А к этому еще летит большое количество правок, изменений и т.д в микросервисах. Контролировать, проверять, реагировать на все это небольшой команде очень тяжело ...

Команде, занимающейся ИБ, нужна так или иначе помощь тех же разработчиков. НО разумно можно задаться вопросом: а нужно ли это разработчикам вообще? В поисках, ответа на этот вопрос я набрел на очень интересную статью "Maximizing Developer Effectiveness", с которой рекомендую ознакомиться.

После прочтения я пришел к таким выводам: чем больше разработчик будет знать и понимать как об окружении (в нашем случае Kubernetes), так и о процессах других команд, которые на него могут повлиять (тот же отдел ИБ - сканерами, проверками), тем проще и быстрее он без посторонней помощи (сам в себе) может решать задачи. И на этом всем можно хорошо стоить как DevOps, так и DevSecOps культуру в рамках компании.

С марта к данному каналу подключатся два моих хороших товарища и мы постепенно начнём раскрывать тему безопасности managed Kubernetes. А именно Google Kubernetes Engine (GKE) и Amazon Elastic Kubernetes Service (EKS).

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

Особое внимание, конечно, будет уделено Identity and Access Management (IAM) и другим особенностям характерным cloud provider’ам. Но также будем проводить сравнения, аналитику и анализ новостей, инструментов как для защиты, так и для атаки + свои мысли и идеи с проектов.

Если у вас есть какие-то идеи, предложения, пожелания, вопросы по данному направлению, то пишите в комментариях.

На канале также начнет появляться информацию о RedHat OpenShift. Для разработки и тестирования у нас в лабе появилась и данная система - буду постепенно изучать и ее.

В процессе разработки мы используем две бесплатные версии/модификации OpenShift:
- okd
- crc

Первый развернут на 5 нодах (3 мастера) и максимально приближен к оригинальному RedHat OpenShift - на нем мы гоняем интеграционные, большие тесты. Второй более минималистичен (там нет мониторинга) развернут в несколько копий по 1 ноде - на них мы обычно гоняем быстрые, частые тесты.

Если вы захотите поизучать/поиграться с RedHat OpenShift - обратите внимание на эти дистрибутивы.

Чтобы закрыть тему внутреннего тестирования и экспериментов в нашей команде - отвечу на вопрос что прилетал в личку. Как наша команда работает с Kubernetes?

Для этого у нас есть внутренний инструмент, который в несколько кликов или через CLI тулзу (она используется в CI\CD) поднимает Kubernetes кластер нужной конфигурации.

На текущий момент можно выбрать:
- foundation - выбор ОС для кластера (centos, debian, ubuntu, fedora, rhel)
- container_runtime - выбор container runtime (docker, containerd, crio)
- num_nodes - количество Node в кластере
- ttl - время жизни кластера
- kubernetes_version - версия Kubernetes (1.15-1.20)

И в ближайшее время добавится:
- cni - выбор сетевого плагина (calico, flannel, cilium, weave)
- service_mesh - при необходимости поставить сервисную сеть (istio, linkerd)

Это нам позволяет быстро тестировать наше решение, сторонние тулзы, проверять баги/уязвимости, проводить исследования и разные эксперименты на разных конфигурация.

На прошлой неделе Google зарелизили GKE Autopilot. Это новый вид кластера в GKE, который подразумевает, что data plane тоже управляется облаком. По сути, под собой это обвязка над Node Pools + Cluster Autoscaler + Admission Webhook, но теперь предоставляется SLA на поды 99.9%. У самого control plane SLA такой-же, как и у регионального кластера, что говорит о готовности решения для прода.

А теперь к интересной нам части - что сделали с точки зрения безопасности

Nodes:
- Container optimized OS с заhardenin'ым ядром
- нет доступа к нодам - не видны в консоли, нет SSH
- Shielded GKE nodes
- Secure Boot

Runtime:
- priviledged mode убран
- ограниченные capabilities ("SETPCAP", "MKNOD", "AUDIT_WRITE", "CHOWN", "DAC_OVERRIDE", "FOWNER",
"FSETID", "KILL", "SETGID", "SETUID", "NET_BIND_SERVICE", "SYS_CHROOT", "SETFCAP"), отсутствует CAP_NET_RAW!
- Seccomp профиль runtime/default
- запрещен hostPath, кроме /var/log
- запрещены host namespaces

Resources:
- изменения в kube-system не доступны
- cluster-admin не существует, только локальный админ внутри namespace
- Workload Identity - SA внутри k8s работают, как облачный SA. Отсюда, нет завязки на SA из metadata API

Add-ons которые планируют добавить:
- Istio
- Confidential GKE Nodes
- Application-layer secrets encryption
- Binary authorisation
- RBAC Google Groups
- Network Policies

Из-за жестких runtime ограничений, большинство тулинга (логгинг, мониторинг, etc) не запустится на Autopilot. Но это обещают исправить. Предоставленная конфигурация позволяет избежать ряда атак на ваш кластер, но из-за этого он менее гибок (что так же верно и для on-prem решения с теми же включенными опциями).

В целом, выглядит как то, что именно таким Kubernetes должен выглядеть by default. Если вас устраивает тулинг от Google Cloud в части логгинга и мониторинга, то Autopilot может стать хорошей заменой Standard cluster. В будущем с введением add-ons будет покрыт полный scope атак, начиная шифрованием памяти и заканчивая supply-chain атаками на образы.

В рамках CNCF SIG Security группы есть отдельная рабочая группа по теме Software Supply Chain. Как написано в их репозитарии: "In cloud native deployments everything is software-defined, so there is increased risk when there are vulnerabilities in this area. If an attacker controls the supply chain, they can potentially reconfigure anything in an insecure way."

Поэтому ребята активно обсуждают и готовят материалы по данной теме. Так в черновом варианте вы уже сейчас можете посмотреть документ "Software Supply Chain Best Practices".

Также:
- У них же есть классная подборка "Catalog of Supply Chain Compromises" из реальных случаев
- У Google есть статья "Help secure software supply chains on Google Kubernetes Engine"
- А MITRE недавно опубликовало "Deliver Uncompromised: Securing Critical Software Supply Chains"

P.S. Посмотрите прошлые посты по данной теме [1,2,3]

Я как один из организаторов конференции ZeroNights рад объявить, что мы опубликовали детали конференции этого года. Конференция будет юбилейной - 10 и проходить 1 день 30 июня в белые ночи в Санк-Петербурге в отличном месте на берегу Финского залива.

Уже сейчас можно подать заявку на доклад - CFP открыт. Ждем доклады как на атакующие темы, так и на защитные (ранее мы их выделяли в отдельный Defensive track). Я лично буду очень рад заявкам на темы контейнеров, Kubernetes и облаков ;)

Часто в компаниях, использующих контейнерные инфраструктуры (включая 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 окружении!