А помните или знаете ли вы как начинался Kubernetes?

Если нет, то прекрасным занятием на выходные будет просмотр фильма "Kubernetes: The Documentary"! Сейчас доступно 2 части (не знаю будут ли еще):
- PART 1 (25 мин)
- PART 2 (31 мин)

Снято это проектом Honeypot и у них есть и другие документалки про Vue.js, GraphQL, Elixir, Ember.js.

Всем хорошей пятницы и выходных!

В комментариях на той неделе написали, что в теме безопасности supply chain обязательно нужно и рассказать и о таком проекте как Tekton. И только я взялся за подготовку поста про него, как вышла замечательная статья "How Citi is building the secure software factory with Sigstore and Tekton".

В рамках статьи авторы рассказали о проекте Secure Software Factory, который является прототипом реализации для CNCF's Secure Software Factory Reference Architecture, которая базируется на CNCF's Software Supply Chain Best Practices White Paper и SLSA guidelines.

Свою реализацию ребята в будущем планируют сделать доступной в рамках OpenSSF Supply Chain Integrity. Пока можно посмотреть видео работы их системы.

Безопасность supply chain совсем скоро будет просто и доступна всем и останется только (и самое сложное) адаптировать уже существующие процессы компании под это.
Изучив все документы – вас никто не сможет удивить в теме безопасности supply chain!

P.S. Пост про проект Tekton это не отменяет ;)

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

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

В этом году я также планирую представить новое исследование на тему Kubernetes на ZeroNights 2022. На текущий момент это скорее всего будет исследование с рабочим названием "NetworkPolicy: родной межсетевой экран Kubernetes". Посмотрим на то как и что могут NetworkPolicy и как они устроены в различных CNI и куда они развиваются. На текущий момент мы с моим коллегой накидываем идеи и готовим заявку)

Cloud Native мир дарит нам много сюрпризов!


Уязвимость CVE-2022-21701 в Istio

В случае если у атакующего есть права на создание Custom Resource под названием gateways.gateway.networking.k8s.io, то он может создать другие Kubernetes ресурсы, которые он по идее (правам) создавать не может, на пример, Pods, что может привести к повышению привилегий (Privileged Escalation).


Уязвимость CVE-2022-24348 в ArgoCD

В случае если у атакующего есть возможность подготовить вредоносный Helm-чарт, то он может позволить ему сдампить Secrets и другую критичную информацию других приложений из кластера, что может привести к повышению привилегий (Privileged Escalation).


Два абсолютно разных проекта, но насколько же однотипные (одной природы) уязвимости - не находите? ;)

Это точно новый мир и мне очень интересно наблюдать за тем, как и что там развивается и порой идет вот так не по плану ведь из-за своих особенностей подобное встретить в другой сфере (ПО) можно или очень редко или вообще не возможно. И это требует глубоких знаний как в работе самого Kubernetes, так и сторонних проектов.

В эту среду 09.02.2022 в 16:00 мой коллега и я будем гостями крутого подкаста linkmeup с темой "eBPF и ни слова про сети". И все это в преддверии нашего выступления на конференции HighLoad++ 17-18 марта в Москве с докладом "eBPF в production-условиях".

Если вам интересно что может дать eBPF кроме обработки сетевых пакетов, XDP и всего такого (об этом есть другой крутой выпуск этого же подкаста – очень рекомендую сначала послушать его ), то welcome на выпуск!

Ссылка на прямую трансляцию на YouTube.

Статья, которую можно было бы и в пятницу запостить, "RBAC Virtual Verbs: Teaching Kubernetes to Educate Dolphins", но глубина погружения в RBAC очень крутая =)

Ознакомившись с ней, вы узнаете, что помимо таких действий (verbs) как: list, get, watch, create, update, patch, delete, deletecollection еще есть и virtual verbs!

Автор в стать предлагает по обучать дельфинов! В качестве Dolphins будет специально созданный CustomResourceDefinition, а educate это просто значение для verbs внутри ClusterRole/Role!

Тоесть в Kubernetes на самом деле нет фиксированного списка разрешенных verbs!!!

При этом в жизни из virtual verbs в дефолтном Kubernetes вы еще можете встретить:
- use
- bind
- escalate
- impersonate
- userextras

Как-то прошло мимо меня, но в том году опубликовали отчет 3rd party security audit для проектов Argo: Argo CD, Argo Rollouts, Argo Workflows, Argo Events. В итоге сейчас на GitHub доступно 2 документа:
- Security Assessment
- Threat Model

С первым документом все банально - список находок уязвимостей/слабостей/проблем для рассматриваемой версии, что достаточно быстро становится не актуальным. А вот второй документ с моделями угроз для всех 4 проектов куда интереснее и полезнее для команд ИБ. Тем более я вижу все больше и больше интереса в индустрии к этим проектам. Поэтому Threat Model для таких достаточно необычных проектов будет очень полез при планировании обеспечения как их безопасности, так и системы в целом, где они используются.

Задумывались ли вы когда-нибудь о границах масштабируемости Kubernetes ?

Если вас порой посещают такие мысли то заметка "Kubernetes Scalability thresholds" как раз для вас. Из нее вы узнаете что ответ на этот вопрос совсем не прост, а также ряд достаточно интересных цифр о Kubernetes. Достичь таких цифр могут, конечно, далеко не многие компании, но все же.

Всем хорошей пятницы и выходных!

В статье "Fun with secrets - Where did they go?" автор в Kubernetes создает Secret со специальной annotation, указывающей на несуществующий Service Account и он успешно создается. Но потом не отображается, если запросить список Secrets! Автор начинает разбираться с этим поведением.

В дело идет etcdctl для прямого доступа к etcd, редактирование существующих Secrets, копание в документации - настоящий детектив! Кто убийца - спойлерить не буду ;)

По возможному импакту - пользователь без права удаления Secret, но с правом его редактировать - может удалить Secret.

Сегодня поговорим не о security, не о reliability и даже не об observability в Kubernetes.

А поговорим как можно упростить и улучшить жизнь разработчиков в инфраструктурах с Kubernetes (да и не только).

Кто-то может тут сразу поднять вопрос: "Нужно ли разработчику знать Kubernetes?" - об этом у меня был отдельный пост и в рамках нее упоминается статья "Maximizing Developer Effectiveness". Из которой вы и могли уже узнать о таком замечательном проекте от команды Spotify как Backstage.

Backstage это OpenSource портал для разработчиков с системой плагинов, позволяющий обозревать всю информацию о системе в одном месте! И да эта система уже понимает, что такое Kubernetes!


Проект находится в CNCF Sandbox, у него уже более 50 крупных публичных компаний пользователей. Я знаю и российские компании, которые используют данное решение.

Да, в ряде больших российских ИТ компаний есть собственные внутренние порталы для разработчиков, сделанные силами платформенной команды. Но если у вас нет не возможностей, не желания вести свою внутреннюю разработку для этого, то Backstage это первый кандидат для пробы из готовых решений.

Прямо online можно поиграть с решением на данном demo стенде.

Дискуссия: Где правильнее (безопаснее) хранить секреты - в переменных окружения или на файловой системе?

В статье "Stop Storing Secrets In Environment Variables!" автор достаточно эмоционально отстаивает свою точку зрения на этот счет) Его фаворитом тут является использование ephemeral filesystem mounts.

А какая ваша позиция на этот счет и что говорит ваш опыт работы с секретами?

Компания Google в своем Security Blog сообщила: "Until December 31 2022 we will pay 20,000 to 91,337 USD for exploits of vulnerabilities in the Linux Kernel, Kubernetes, GKE or kCTF that are exploitable on our test lab."


Максимальное вознаграждение за эксплоит теперь составляет 91,337$, при этом вознаграждение есть и за 1day и за дубликаты с уникальными техниками эксплуатации!

Напомню, что в 2020 году компания Google (родитель Kubernetes) расширила свою Vulnerability Rewards Program (VRP), добавив туда Kubernetes-based инфраструктуру под названием kCTF.

О парочке таких публичных успешных вознаграждений я уже писал [1,2].

Мне кажется, что это очень хорошо показывает, насколько Google внимательно относится к Kubernetes и какую ставку на него делает.

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

В связи с ростом сложности и запутанности систем, на первый план выходит observability. А то мало ли на чем там у вас это все держится ;)

Это как надежности, так и безопасности системы касается.

Всем хорошей пятницы и выходных!

Все больше встречаю компаний, которые задумываются или уже начинают экспериментировать c Service Mesh в своих инфраструктурах как для задач связанных с информационной безопасность, так и нет. Но далеко не все на сегодняшний день представляю возможные вариации реализаций Service Mesh и их плюсы и минусы.

В статье "eBPF for Service Mesh? Yes, but Envoy Proxy is here to stay" мне понравилось как рассматривается текущая картина в сравнении да еще и с учетом технологии eBPF. В итоге рассматривается 4 архитектуры:

1) Sidecar proxy (service proxy)
2) Shared proxy per node
3) Shared proxy per service account (per node)
4) Shared remote proxy with micro proxy

Все это при этом сравнивается по 4 пунктам:
- Memory/CPU overhead
- Feature isolation
- Security granularity
- Upgrade impact

И не могу не сказать о статье "How eBPF will solve Service Mesh - Goodbye Sidecars" - там речь о еще одной архитектуре:
5) eBPF Accelerated Per-Node Proxy

2 важные цитаты про eBPF в этом контексте из статей:
1) " this would be quite difficult and may not be the right approach. eBPF is an event-handler model that has some constraints around how it runs."
2) "For some use cases, a proxy is still needed."

Выводы делайте сами с учетом ваших потребностей ;)

Сheckov прекрасный инструмент, который позволяет управлять и анализировать IaC таких платформ как Terraform, Kubernetes, Helm и многих других. Он активно продвигает концепцию Policy-as-code.

Его можно использовать как CLI для сканирований на локальных машинах разработчиков или даже как часть IDE или более обыденно в CI pipelines через GitHub Actions. Но все равно остаётся риск что злоумышленник обойдет эти этапы. И тогда последним бастионом защиты остается Validating Admission Controller!

Проект Whorf это как раз такой контроллер на базе Сheckov.

Мое мнение:
1) Whorf проигрывает любому специализированному Policy Engine для k8s
2) Kyverno и OPA Gatekeeper также умеют в CLI
3) Вы врятли его даже попробуете так как для запуска надо получать API key от вендора

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

Всем привет!

Напомню что ещё есть возможность купить билеты на ZeroNights 2022 по сниженной/ранней цене и подать свой доклад на конференцию через CFP. Если кто-то сомневается или делает это впервые, то я могу помочь и все подсказать ;)

И конкурс!
В комментариях к этому посту напишите историю из вашей практики или друзей друзей про fails в области ИБ при работе с Kubernetes.

Для затравки я напишу две (согласовано с действующими лицами) вне конкурса!

3 наиболее интересные на мой взгляд истории получат билеты на ZeroNights 2022!

Победителей объявлю 28 февраля ;)

Проект vulnerability-operator это логическое продолжение проекта sbom-operator, от того же автора. Если sbom-operator отвечает за формирование SBOM, то vulnerability-operator берет результаты первого и по расписанию сканирует его на известные уязвимости сканером Grype.

На текущий момент данный оператор берет SBOM из git-repository сканирует его и результат отдает в JSON-file через endpoint и/или как Prometheus метрики.

С автором я обсудил еще один вариант совместной работы этих операторов, и он его уже занес в планы. А именно такой:
1) sbom-operator создает результат своей работы в виде ресурса PolicyReport и связывает его по ownerReference с микросервисом (по аналогии как это делает Starboard-operator).
2) vulnerability-operator реагирует на появление нового PolicyReport и переодически его сканирует и обновляет информацией о известных уязвимостях.

В итоге это позволит полностью реализовать Kubernetes Resource Model (KRM), в которой всегда все о системе можно узнать из YAML ресурса =)

Kubernetes Security SIG и Policy WG зарелизили новый документ, который касается вопроса контроля автоматизации, так и безопасности происходящего в кластере, под названием "Kubernetes Policy Management Paper".

По сути это набор best practices для управления конфигурациями Kubernetes, используя политики (привет Policy Engines!). Документ освещает два момента:
1) Какие проблемы Kubernetes политики могут помочь решить
2) Как Kubernetes политики могут быть реализованы

В итоге, обсуждается эталонная архитектура для управления политиками в Kubernetes с описанием каждого необходимого компонента.

Без внимания не остается Runtime политики, покрывающие происходящие уже внутри контейнеров и дополняющие Policy engines.

Документ MUST READ для всех. Без подобного построить грамотную безопасность в K8s невозможно на мой скромный взгляд.

Для некоторых может быть новостью, но

kubeclt -n <namespace> get all - не работает!

То есть вы получите не полную - не правильную картину. И при этом это совсем не новость и не сенсация в Kubernetes сообществе — это уже неоднократно обсуждалось [1,2].

Имея не правильную картину происходящего в кластере, можно принять не правильные решения и тем самым привести к сбоям, проблемам и долгим отладкам в недоумении от происходящего. На пример, вы не будете видеть кастомных NetworkPolicy или ресурсов от Istio и долго упорно отлаживать сетевое взаимодействие ...

Одним из решений проблемы может быть krew плагин для kubectl под названием ketall/get-all.

За более детальным погружением в проблему и другими возможными решениями рекомендую обратиться к моему выступлению "Kubernetes Resource Model (KRM): Everything-as-Code"

В продолжении вчерашнего поста поделюсь еще одним нюансом работы с Kubernetes при этом на прямую затрагивающим вчерашнюю задачу получения всех ресурсов из Namespace.

И так, знайте когда вы делаете запрос к Kubernetes API по любому из ресурсов, то в ответ вы получаете всегда целый/полный YAML данного ресурса со всеми вытекающими, а не просто несколько строк. Тоесть в попытке получить список всех ресурсов в конкретном Namespace в ответе к вам придет все их содержимое и если там, на пример, сотни Pods, то придет вся информация о них, аналогично и про все другие ресурсы. Так что, имейте ввиду, что такими запросами можно не плохо так нагружать Kubernetes API.

P.S. Один из старых постов про verbosity в kubectl.

Сегодня опять расскажу о том, что Kubernetes (пока еще) не умеет, но на это уже заведен KEP: "In-place Update of Pod Resources", в ожидании которого большое количество Ops специалистов (для Sec это будет также полезно знать).

Основной смысл данного улучшения заключается в том, чтобы можно было обновлять Pod resource requests и limits вовремя работы без перезапуска Pod или его Containers. По-другому это еще могут называть как Vertical Resources Scaling.

Бывает так что приложение при своем старте требует достаточно существенное количество ресурсов, а далее уже использует куда меньше ресурсов при штатной работе. Вот тогда и надо сначала выделить большое количество ресурсов для Pods, а потом поправить requests и limits для него.

Насколько я знаю прародитель нашего герой - Borg подобное умеет.

В комментариях можете поделится какие KEP или просто фичи вы ждете или вам бы очень хотелось видеть в Kubernetes.