В официальном блоге Kubernetes появилась запись "Securing Admission Controllers". И посвящена она как нетрудно догадаться безопасности такого важно для Kubernetes механизма как Admission Controllers. На нем базируется, по сути, Kubernetes operators и те же PolicyEngines.

И данная запись на самом деле приурочена к выходу whitepaper под названием "Kubernetes Admission Control Threat Model" от SIG Security. В документе вы найдете:
- Attack Tree - дерево атак, связывающее начальные условия, угрозы, защиты и возможные последствия
- Threat Model - всего выделили 16 угроз.
- Mitigations - 8 штук

Особое внимание обратите на угрозы с ID: 4,6,11,17. При их реализации атакующий сможет:
1) Запустить workload, который по идее уязвимым Admission Controller был бы запрещен
2) Получить доступ к чувствительной информации, с которой работает Admission Controller

Хардкорная блоговая запись "CVE-2022-0185 - Winning a $31337 Bounty after Pwning Ubuntu and Escaping Google's KCTF Containers" еще один прекрасный пример (на ряду с CVE-2021-22555) побега из контейнера через kernel уязвимость хоста в рамках kCTF. Код эксплоита.

Основные моменты:
- Уязвимость позволяет в Kubernetes совершить побег из Pod на Host.
- Уязвимость появилась с 5.1-rc1 в марте 2019.
- Для атаки атакующий должен иметь доступ к контейнеру с CAP_SYS_ADMIN privileges (что само по себе считай побег) или к команде unshare(CLONE_NEWNS|CLONE_NEWUSER), которая даст CAP_SYS_ADMIN privileges в новом user namespace
- SeccompDefault в значении RuntimeDefault благодаря блокировке unshare способен замитигейтить данную багу (и все это только с 1.22)

Как и в прошлый раз я рекомендую: используйте AppArmor/SeLinux/seccomp профили для приложений, а также всегда имейте возможность смотреть что происходит внутри ваших контейнеров - прокачивайте observability.

Статьи по теме от вендоров [1,2].

Одним из самых популярных вопросов на всех форумах по Kubernetes это: "А кто, как ставит Kubernetes?"

Не знаю кто как, но так точно hard way =)

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

Чем опасен доступ к nodes/proxy в RBAC?

Именно на этот вопрос исследователи дают ответ в заметке "Node/Proxy in Kubernetes RBAC".

По итогу:
- Возможность работы с Pods на Node напрямую через Kublet API в обход Kubernetes API
- Право GET позволяет читать, например, получить список Pods на Node
- Право CREATE позволяет читать, например, выполнить команду в Pods
- Доступ к портам, что закрыты firewalls
- Обход средств контроля безопасности, таких как Kubernetes Audit Log и Admission controls

Отдельно стоит еще посмотреть на заметку "Detecting direct access to the Kubelet". По итогу, понять какой именно пользователь обращался к node proxy в Audit log нельзя, но можно увидеть, что кто-то обращался к nodes/proxy sub-resource по записям в логе о TokenReviews и SubjectAccessReviews ресурсах от kubelet.

Заодно ребята еще проверили багу 2019 года с “Abusing Kubernetes API server proxying” и убедились что она работает до сих пор.

P.S. Также не забывайте про "*" ;)

secureCodeBox это kubernetes-based модульный toolchain от проекта OWASP на базе множества open source сканеров для continuous security scans. Это какая-то мечта любого DevSecOps специалиста!

Смотрите сами:
- Поддержка более 15 сканеров: Amass, Git Repo Scanner, Gitleaks, Kubehunter, Kubeaudit, Nikto, Nmap, Nuclei, Semgrep, Trivy, ZAP и другие.
- Встраивание в CI/CD pipeline или Kubernetes окружение
- Наличие собственного Dashboard, интеграции с DefectDojo и Kibana (ELK Stack) или кастомная интеграция
- Управление и контроль через его Custom Resources: Scan, ScheduledScan, ScanType, ParseDefinition, ScanCompletionHook, CascadingRule (еще один шажок в направлении Security-as-Code)

Сам еще этого монстра не тестировал, но выглядит как минимум впечатляюще. Пример использования тут. Если кто уже опробовал его в деле - пишите в комментариях ;)

Статья "Hardening Kaniko build process with Linux capabilities" о повышения уровня безопасности процесса сборки при использовании Kaniko. Вопрос сборки образов внутри Kubernetes/containers мы уже как-то поднимали и обсуждали момент с преимуществами такого подхода. Но это статья не о простом использовании Kaniko, а о том, как можно улучшить, обезопасить процесс.

Ситуация с Kaniko следующая - его контейнер запускается от пользователя root. Можно, конечно, предположить, что ему для работы нужны далеко не все capabilitys =)

План: забираем все capabilitys и явно добавляем только нужные!

Автор в своих изысканиях с Kaniko пришел к такому результату: CHOWN, SETUID, SETGID, FOWNER, DAC_OVERRIDE.

Как вы понимаете такой подход работает и для других приложений ;)

Повсюду говорят о важности безопасности supply chain, но реализовать это не просто ведь состоит это не из одного какого-то действия, а из целой цепочки и ряда разнообразных типов инструментов. И тут руки опускают и включается режим ожидания “комбайна”, который сделает все сам через одну красную кнопку ...

Но если вы не ждун и руки чешутся все это реализовать здесь и сейчас, то статья "Improve supply chain security with GitHub actions, Cosign, Kyverno and other open source tools" как раз для вас как ориентир.

Тут вам и генерация, и проверка checksum, SBOM, подписи образа с помощью Docker Content Trust (DCT), Cosign, Syft, Kyverno, а также сканирование на уязвимости с помощью Trivy и все через GitHub actions!

Отдельно выделю раздел "Further improvement or study" о том, как еще можно улучшить данную цепочку.

Появилась мысль создать стикерпак канала "k8s(in)security" =)

Все же любят наклейки?!

Буду рад и очень признателен за идеи текста, картинок, что вы хотели бы видеть в стикерпаке и с радостью бы наклеили на свой ноут или системник.

Взаимодействие с дизайнерами, печать я возьму на себя.

В дальнейшим данный стикерпак буду раздавать на конференциях или высылать в качестве призов/подарков. А авторам чьи идеи войдут в реализацию будут среди первых кто получит стикерпак ;)

В общем пишем и предлагаем в комментариях!!!

P.S. Идеи буду собирать до конца февраля.

А помните или знаете ли вы как начинался 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. А то мало ли на чем там у вас это все держится ;)

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

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