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

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

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

В том и том варианте есть как свои плюсы, так и минусы. Нужно иметь ввиду что это также отражается и на безопасности: обнаружение проблем, исправление проблем, мониторинг безопасности приложения и т.д.

Очень классная исследовательская работа "Docker image history modification - why you can't trust `docker history`". Общая идея статьи показать, что история образа это всего лишь meatadata, которая также может быть изменена/подделана и не надо ей слепо доверять. И тут опять плавно возвращаемся к supply chain атакам.

Отдельное внимание уделяется инструменту от Google под названием container-diff. А потом демонстрируется (почти пошаговая инструкция) как можно подделать историю и данный инструмент не найдет отличий.

Для корректного подтверждения подлинность образов Docker, которые вы создаете или используете, лучше использовать их подпись (в Docker есть Docker Content Trust (DCT), а в Kubernetes, на пример, Notary в pipeline), а не данную metadata.

Я лично не знаю кто-либо использовал сравнение истории для определения аутентичности образов, но мало ли кто думал в этом направлении...

Для тех, кто разбирается с проблемами работоспособности, возникающими с workloads в Kubernetes такой ресурс как Events хорошо знаком (если забыли, то вспомните нижнюю часть вывода команды describe). Он очень полезен при решении проблем, но время от времени можно задаться вопросом, а какие они вообще бывают и о чем могут сообщить, предупредить ...

Для этого на этот (да и на любой) может помочь исходный код ;) В данном файле собраны все (и это не правда) Events с группировкой по категориям Container, Pod, Image, kubelet и других более мелких групп. К сожалению, там все-таки собрано не все — вот, на пример, событие Evicted описано в другом файле и сколько таких еще - не известно.

Можно обратить внимание, что Events относящихся к безопасности нет (по крайней мере в этом списке и я таких не знаю). Но было бы круто если бы они там появились — это прекрасное место для уведомления о runtime угрозах. При этот на сколько я понимаю сторонние решения могут взять это на себя и генерировать подобные сообщения, имея права работы с Events ресурсами.

Вернемся к теме «Нужно ли разработчику знать 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.