Я уже писал, что веду 3-х дневное обучение "Cloud Native безопасность в Kubernetes".

И вот недавно на одном из таких тренингов, один из участников (респект тебе) сделал вот такой замечательный MindMap по его итогам! Выкладываю его с разрешения его создателя. Сначала я хотел внести туда какие-то свои мысли, корректировки и дополнения, а потом решил, что так будет даже лучше (или мне просто пока лень) показать, как видят материал участники! То есть тренинг "Cloud Native безопасность в Kubernetes" глазами его участников.

Думаю, что данный MindMap будет полезен многим ;)

Изучайте новое, от теории переходите к практике, не бойтесь не понятного! Чем больше в сообществе, в индустрии будет грамотных специалистов, тем лучше будет нам всем!

В официальной документации Kubernetes в разделе Security появился целый новый подраздел о "Multi-tenancy", объясняющий данную концепцию. Тема сейчас для многих очень актуальная.

Оттуда вы узнаете о:
- Use cases
- Terminology
- Control plane isolation (Namespaces, Access controls, Quotas)
- Data Plane Isolation (Network isolation, Storage isolation, Sandboxing containers, Node Isolation)
- Additional Considerations
- Implementations (Namespace per tenant, Virtual control plane per tenant)

Все очень хорошо описано и систематизировано. И не забываем и про прошлые посты [1,2,3,4,5] и опрос на эту тему, которые помогут сложить картину еще более четко о Multi-tenancy.

Если вам периодически хочется некого инсайда о делах/вопросах безопасности в Kubernetes, то просто вспомните что это OpenSource проект и все что с ним связано ведется на GitHub ... И можно просто посмотреть открытые issues со соответствующими labels - связанными с security. Таких labels там всего 5:
- sig/security
- wg/security-audit
- committee/security-response
- area/security
- official-cve-feed

Так что когда вам скучно или просто не чем заняться, то можно посмотреть, что там обсуждают и еще не закрыто в Kubernetes - бывает страшно и/или смешно ;)

Обзорная статья "Let's talk about Kubernetes on the Internet" из которой вы узнаете сколько, как почему и каких Kubernetes кластеров смотрит в Internet;)

В частности идет речь про торчащие наружу порты от:
- Kubernetes API server - около 1 миллиона и львиная доля благодаря managed Kubernetes
- kubelet - около 200 тыщ. и причины такого малопонятны
- etcd - около 3 600 и установить все ли это относиться к Kubernetes так невозможно

Помните, что везде где это возможно старайтесь ограничить взаимодействие с системными портами Kubernetes как снаружи, так и внутри.

P.S. Прошлые сканы. Можно заметить, что цифры только растут.

Время от времени вы уважаемые читатели спрашиваете, когда и где я еще буду выступать с новыми докладами. Пока конкретные даты и конференции назвать не могу, так как CFP еще идут. Но могу рассказать какие темы я сейчас уже готовлю на конец этого года:
1) "Специфика расследования инцидентов в контейнерах" - в данном докладе рассмотрим какая есть специфика, которая ряд моментов делает более сложными, а некоторые более простыми.
2) "Безопасность Kubernetes: Фаза Deception" - рассмотрим ловушки для злоумышленников в Kubernetes на базе его механизмов и не только.
3) "Сочетание несочетаемого в Kubernetes: удобство, скорость, безопасность" — это рабочее название доклада, в котором хочу показать, как ИТ и ИБ в кластере Kubernetes могут сразу делать и оптимально, и удобно и при этом безопасно. И все живут мирно и дружно!

Какой-то материал я пока специально придерживаю для докладов и не публикую его на канале для эксклюзивности материала =)

P.S. Всегда рад в комментариях почитать ваши запросы как на какие-то посты по теме или на доклады .

Большинство людей (до 85% населения Земли) являются визуалами (главным типом восприятия является именно зрительный контакт) и изучать таким людям что-то новое или сложное проще на картинках. У Ивана Величко есть замечательный блог с разделом Learning Series, где можно узнать много всего о containers и Kubernetes именно в такой форме. Сейчас есть серии на темы:
- Debunking Container Myths
- Mastering Container Networking
- Working with Kubernetes API
- Writing Kubernetes Controllers/Operators
- Implementing Container Manager

Данная серия будет очень полезна как новичкам, так и знатокам - лично я из каждого поста, картинки открываю для себя что-то новое Kubernetes. Могу это смело рекомендовать на ряду с изучением официальной документации Kubernetes - просто MUST READ!

Если вы используете Service Mesh Istio или планируете, то перед вами рано или поздно станет вопрос ее безопасности и организации безопасности с ее помощи (если захотите). И как раз для вас на последнем IstioCon 2022 была два доклада на данную тему:
1) Service Mesh Security Best Practices - From Implementation to Verification
2) A beginner’s guide to following Istio’s security best practices

Давненько ничего не писал про eBPF - исправляюсь!

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

За последнее время в данной подсистеме и новые уязвимости находились и публиковались эксплоиты для них. На пример, для CVE-2021-4204 и CVE-2022-23222. По ссылкам можно посмотреть код и поиграться с эксплоитами. При этом важно знать и помнить (многие этот момент теряют), что баги есть везде и сами эти уязвимости на работу решений на базе технологии не влияют и вред системе не наносят (а то это один из частых вопросов к нам - ведь у нас в разработке используется eBPF).

Также тема разработки вредоносного кода не стоит на месте (технология крутая и явно приковывает к себе внимание) и я знаю как минимум 2 новых проекта на eBPF:
- pamspy - дампер кред для Linux. Для своей работы он использует userland пробу для хука функции в PAM (Pluggable Authentication Modules), что открывает дорогу к sudo, sshd, passwd, gnome, x11 и тд
- TripleCross - Linux eBPF rootkit с возможностями backdoor, C2, library injection, execution hijacking, закрепления и скрытой работы.

Продолжая копать тему различных архитектур реализации ServiceMesh и её развития с учетом технологии eBPF, наткнулся на замечательную статью "eBPF, sidecars, and the future of the service mesh".

Автор данной стать задается двумя вопросами:
1) Насколько мощна технология eBPF при работе с сетью?
2) Можно ли полностью отказать от sidecars proxies и делать все в ядре?

В процессе этого рассказывается:
- Что такое eBPF
- Проблемы конкурентной multi-tenancy
- Ограничения eBPF
- Проблемы Per-host proxies
- Будущем ServiceMesh

По итогу ответы таковы: "Перенести всю логику в eBPF в текущих реалиях нельзя, но сочетать userland sidecars с eBPF можно и нужно".

Примечательно что если прошлая статья на эту тему была от авторов Istio (+ доклад "Sidecarless with eBPF or sidecar with Envoy proxy?"), то эта от Linkerd и они сходятся в своих взглядах и оценках. Далее я планирую ознакомится с материалами от команды Cilium у которых есть свой взгляд на ServiceMesh ;)

Свежая серия постов на тему матрицы угроз для Kubernetes! Серия состоит из 4 частей:
1) MITRE ATT&CK Matrix for Kubernetes - вводная статья
2) MITRE ATT&CK Matrix for Kubernetes: Tactics & Techniques Part 1 - рассматриваются стадии initial access, execution, persistence и privilege escalation.
3) MITRE ATT&CK Matrix for Kubernetes: Tactics & Techniques Part 2 - рассматриваются стадии defense evasion, credential access и discovery.
4) MITRE ATT&CK Matrix for Kubernetes: Tactics & Techniques Part 3 - рассматриваются стадии lateral movement, collection и impact.

На самом деле авторы ошиблись, добавив в название MITRE ATT&CK, ведь само описание делают на базе матрицы от Microsoft (которая по мне более правильная и полная).

P.S. Аккуратно - на картинке есть опечатки!

"How Attackers Use Exposed Prometheus Server to Exploit Kubernetes Clusters" - крутой доклад с Kubecon 2022 EU. Слайды тут, статья тут и видео тут.

Из него вы узнаете почему выставлять Prometheus endpoints в интернет (или вообще на обозрение злоумышленникам) эта плохая идея. Авторы в качестве экспортеров взяли два самых популярных:
- Node Exporter
- Kube State Metrics

И показывают какую информацию из них может извлечь атакующий (картинка в превью) и как это можно использовать уже для атаки на сам кластер или приложения в нем. Сами авторы это обозначили как Kubernetes fingerprinting with Prometheus =)

Весь материал будет полезен как пентестерам, так и внутренним службам ИБ.

В случайных блужданиях по глубинам интернета наткнулся на интересный проект - SecurityPatterns.io

По сути, это гайд о том, как писать security patterns, да еще и с примерами. C гайдом все достаточно прозаично:
1) Постановка задачи (определение проблемы)
2) Определения актива, на которой влияет данная проблема
3) Моделирование угроз
4) Разработка паттерна безопасности

Причем тут Kubernetes спросите вы?! Во-первых, для него можно и нужно такое разрабатывать. Во-вторых, в разделе примеров — это уже сделали за нас! В примерах вы найдете:
1) Source Code Management
2) Container Platform
3) Container Orchestration
4) Service Mesh
5) API based Microservices

Все я это не осилил - объем впечатляет и лично буду пользоваться как справочником при необходимости ;)

"Kubernetes Ephemeral Container Security" это пост не про то зачем и как пользоваться ephemeral containers, а про их влияние на безопасность.

А если быть точнее, то, как с этим работают разные PolicyEngine ведь этот тип контейнеров, также является частью YAML. По сути, такой же мыслью я уже задавался на канале в данном посте. И автор данного поста приходит к таким же результатам и выводам, как и я.

Далее автор смотрит на эти контейнеры еще с точки зрения RBAC - где они выглядят как subresource с именем pods/ephemeralcontainers и к нему можно давать и не давать доступ пользователям.

По итогу:
1) Обновляйте свои политики для PolicyEngine
2) Контролируйте RBAC

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

Отдельно с ними пообсуждали тему расследования инцидентов в контейнерах средах – Kubernetes. В итоге могу поделиться следующей информацией:
1) Случаев и запросов на расследование инцидентов в контейнерах средах становится все больше.
2) Подобные расследования становятся ночным кошмаром для специалистов, если в инфраструктуре заранее не были предусмотрены соответствующие инструменты и практики. А таких инфраструктур, к сожалению, сейчас абсолютное большинство и помочь получается редко.
3) Сошлись на мнении что приложения в контейнерах проще/лучше грамотно защитить, чем потом пытать там что-то либо расследовать ввиду специфики работы контейнеров и оркестраторов.

О своем взгляде на все это я расскажу в докладе "Специфика расследования инцидентов в контейнерах" (доклад пока в стадии рассмотрения CFP конференции).

Сегодня в центре внимания статья "Load external data into OPA - The Good, The Bad, and The Ugly".

Благодаря данной статье вы сможете ориентироваться в методах получения дополнительной информации для принятия решения об авторизации действия. По-другому это еще можно назвать обогащением. Все это так или иначе помогает создать полый контекст и принять решение. В статье рассматривается 6 способов:
1) Including data in JWT tokens
2) Overload input for OPA within the query
3) Polling for data using Bundles
4) Pushing data into OPA using the API
5) Pulling data using OPA during Policy Evaluation
6) OPAL (Open Policy Administration Layer)

В официальной документации OPA есть раздел "External Data" и там можно ознакомится с этими же способами (за исключением последнего).

При работе с OPA Gatekeeper можно использовать встроенную в Rego функцию http.send (это сценарий 5), но также у него есть и свой уникальный способ через специализированный ресурс Provider, который и рекомендуется использовать на сегодняшний день.

Я думаю, что сегодня все понятно просто по стартовой картинке =)

Да, оказывается уже есть OWASP Kubernetes Top 10! Проект молодой и еще не до конца доделанный - на текущие момент описано 7 или 10 пунктов (хотя и у тех 7 внутри не все еще готово). По задумке авторов каждый из пунктов состоит из разделов:
- Overview
- Denoscription
- How to Prevent
- Example Attack Scenarios
- References

Сам рейтинг:
K01:2022 Insecure Workload Configurations
K02:2022 Supply Chain Vulnerabilities
K03:2022 Overly Permissive RBAC Configurations
K04:2022 Lack of Centralized Policy Enforcement
K05:2022 Inadequate Logging and Monitoring
K06:2022 Broken Authentication Mechanisms
K07:2022 Missing Network Segmentation Controls
K08:2022 Secrets Management Failures
K09:2022 Misconfigured Cluster Components
K10:2022 Outdated and Vulnerable Kubernetes Components

Какое мое мнение по этому рейтингу? Напишу в завтрашнем посте ;)

Относительно OWASP Kubernetes Top 10 из прошлого поста. Как и в любом рейтинге (ничем не подкрепленным) любая позиция в нем дискуссионная, так что на порядок, в котором тут расставлены риски я бы не обращал внимания - хорошо смотреть на картину в целом.

Хотя позиция K01:2022 Insecure Workload Configurations тут явно не поколебима - потому что это касается любого YAML, а у нас все в Kubernetes то YAML.

При этом на мой взгляд первая позиция неразрывно связанна с K04:2022 Lack of Centralized Policy Enforcement ведь первый риск решается (как вариант) с помощью Policy Enforcement (PolicyEngine) - нужно было ли это прямо в отдельный пункт выносить - не знаю. При том что упоминание PolicyEngine есть почти в каждом из пунктов.

Удивило полное отсутствие упоминание Runtime Security в данном перечне, этого даже в скользь нет в K05:2022 Inadequate Logging and Monitoring ... Хотя почти во всех примерах приводят ситуации, когда атакующий что-то выполняет в контейнерах. Таким образом авторы как-то взяли и выкинули всеми любимый кейс с запуском майнеров вообще.

Так же на мой взгляд сейчас остро стоит вопрос с Multitenancy в Kubernetes и как один из рисков, когда один из tenant нарушает изоляцию другого. И это куда распространённее чем тот же K06:2022 Broken Authentication Mechanisms.

По и тогу я бы K04:2022 и K06:2022 заменил бы на Runtime Security (точнее Malware activity) и Multitenancy (точнее Isolation missing).

А какие у вас мысли по данному рейтингу?

Учиться никогда не поздно и учеба никому не вредила - встречайте Awesome Cloud Native Trainings! Это подборка бесплатный тренингов от Cloud Native Computing Foundation проектов и разработчиков программного обеспечения связанного с Kubernetes. Чисто на свой вкус выделю следующие тренинги:
- Kyverno Fundamentals
- OPA Policy Authoring
- Observability Fundamentals
- eBPF Fundamentals Certificate
- Certified Calico Operator: eBPF
- Introduction to Prometheus and PromQL
- Kubernetes related courses

Материал будет полезен Dev, DevOps, SRE и Security инженерам.

Сегодня нужно исправить одно досадное упущение. И заключается оно в том что такой замечательный инструмент как Teleport еще ни разу не фигурировал на данном канале. Штука многогранная, но поговорим о ней в контексте Kubernetes.

По сути Teleport представляет из себя шлюз для identity и access management для Kubernetes API. Очень ярко это раскрывается в статье "How to Give Developers Secure Access to Kubernetes Clusters". Из статьи вы узнаете и как по шагам его у себя поставить и какие бенефиты он может дать:
1. Identity-based access to your Kubernetes cluster
2. Full visibility of all activities performed on your Kubernetes cluster
3. Helps you implement best pratices for Kubernetes access easily
4. Makes you more productive

Отдельно выделю возможность 3 формата для visibility происходящего в сессиях:
- session recording
- unified audit logs
- live view

И, конечно, возможность писать kubectl exec сессии!

P.S. За вопросами в специализированное сообщество @ru_teleport

Если по каким-то причинам вам не подошел наш вчерашний герой (Teleport), то не унывайте как альтернатива ему есть решение HashCorp Boundary.

Мощный лонгрид "User and workload identities in Kubernetes" посвящённый AuthN (на самом деле это 4 статья из цикла). Помимо более-менее очевидных моментов что кочуют из статьи в статью про аутентификацию в Kubernetes - типа: внутренние и внешние субъекты, различные стратегии аутентификации (static token, bearer token, X509 certificate, OIDC и т.д.), назначение и роль Service Accounts и подобное.

В данной статье есть очень классный момент про работу Service Accounts и Secret до версии 1.24 и начиная с нее. Если вы об этом не знали, то тут появляется значительное отличие по работе. Если раньше при создании Service Accounts для него Secret с token создавался автоматически, то теперь этого не происходит (но можно вернуть прежнее поведении через специальную annotations - читайте в этой же статье). С версии 1.24 желаемый token монтируется в Pod автоматически как projected volume и имеет срок действия (чего не было раньше)!