На сайте DevOpsConf 2022 стали доступны все слайды конференция, включая мои по теме "SOAR в Kubernetes малой кровью". Начав с Kubernetes Policy Management Whitepaper и специализированных ресурсов PolicyReport и ClusterPolicyReport, я в ней показал как можно сделать SOAR (Security Orchestration, Automation and Response) в Kubernetes на двух фазах:
- Deploy - с помощью PolicyEngines
- Runtime - с помощью Agents и Responce Engines

В качестве Policy Engine я использовал Kyverno, так как он умеет проверять, изменять и создавать Kubernetes ресурсы. А в качестве Responce Engine я выбрал связку Argo Events и Argo Workflow, которые позволяют создавать playbooks любой сложности!

И, конечно, привел примеры нескольких playbooks, которые уже можно взять к себе на проработку ;)

Еще одна впечатляющая работа с Kubecon 2022 Eu - "Protect the Pipe! A Policy-based Approach for Securing CI/CD Pipelines" (слайды, видео). Главными героями (стек) в этой работе выступают:
- Tekton - Cloud Native CI/CD
- in-toto - framework to secure the integrity of software supply chains
- sigstore - new standard for signing, verifying and protecting software
- Kyverno - Policy Engine

Авторы выделяют дерево атак на Tekton Pipeline и потом защищают его с помощью упомянутых решений. Самое классное в этой работе то, что все это сопровождается live demo и при этом доступен весь исходный код! Tак что можно познакомится со всеми инструментами самостоятельно на minikube и создать реально защищенный pipeline по последнему писку cloud native моды!

Очень крутая статья `Kubernetes Ephemeral Containers and kubectl debug Command`. Из статьи вы узнаете:
1) Зачем вообще понадобились Ephemeral Containers - если вдруг вы еще не знаете
2) О существовании команды kubectl debug
3) О дефолтном поведении kubectl debug при отладке
4) Первый сценарий: kubectl debug в сочетании с shareProcessNamespace
5) Второй сценарий: kubectl debug с указанием конкретного conntainer в Pod
6) Третий сценарий: kubectl debug с копированием целевого Pod
7) И можно ли работать с Ephemeral Containers без kubectl debug

Ephemeral Containers - перешли в Beta и включены по умолчанию в 1.23, а появились в версии 1.18. Индустрия уже и отладочные образы (типа KoolKits) на разные случаи жизни подготовила.

Также не забывайте о них и при анализе безопасности своих микросервисов и окружения (а то бывает вот так).

Tetragon - eBPF-based Security Observability and Runtime Enforcement от создателей CNI Cilium. Это rule-based решение типа Falco, Tracee. При этом то, за чем следим описывается в отдельном Custom Resource - TracingPolicy.

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

И сразу несколько Linux-исследователей взялись за оценку подобного подхода и продемонстрировали обходы:
- Bypassing eBPF-based Security Enforcement Tools
- Tetragone: A Lesson in Security Fundamentals
- Tetragon: case study of security product's self-protection

Тул на самом деле интересный, правда требует тонкой (хирургической) настройки на уровне каждого syscall с его аргументами. Если вы пишете на eBPF (как мы в нашем решении), то там есть на что посмотреть в исходном коде - правда есть и вот такие вставки на assembler с исповедью разработчика)

Поиграться с ним можно в этой лабе.

P.S. К сожалению, часто при описании тулы, упоминаются фичи платной версии.

Если у атакующего в контейнере есть капабилити CAP_SYS_ADMIN или он находится в привилегированном контейнере (securityContext.privileged:true), то для побега из контейнера ему даже не требуется никаких уязвимостей! Пускай у вас там хоть все запатчено и перепатчено =)

Одним из подобных векторов, о котором мы сегодня поговорим, является использование Usermode helper programs. Таких программ порядка десятка и почти все можно использовать для побега из контейнера, так как при срабатывании того или иного события эти программы выполнится на хостовой ОС.

Самой известной такой программой является release_agent. О данной программе есть куча статей и данную технику можно встретить во множестве тулов и эксплоит паках.

Но есть, на пример, и такая как (менее известная) core_pattern — вот как раз про нее и рассказывается в статье "Escaping privileged containers for fun", которую я рекомендую почитать. Техника очень проста и стабильна ;)

P.S. Еще можете посмотреть такой кейс с core_pattern

Молодой PolicyEngine под названием Kubewarden на днях отпраздновал выпуск версии 1.0.0!

Я за ним мало слежу и вообще не встречал его среди клиентов (но судя по опросу на канале он используется). Но тут при чтении данного анонса мой взгляд зацепился за строчку "Reuse your existing Open Policy Agent / Gatekeeper policie". Ранее я думал, что там политики можно писать только на Rust, Go и Swift. То сейчас (с какого-то момента) можно переиспользовать те же политики от OPA Gatekeeper или просто писать на Rego (я и таких фанатов знаю).

Какой смысл писать политики на Rego тут, а не в OPA Gatekeeper (и то без мутаций)?! Я честно кроме выгоды от переносимости Wasm больше не увидел ... Написание политик на высокоуровневых языках (Rust, Go и Swift) еще понятна - там мы получаем всю их мощь, включая гигантский набор библиотек (по статистике, анализу, ML, готовых API в другие системы и т.д.).

Сегодня в фокусе нашего внимания статья "How to secure Kubernetes ingress?". Статья очень базовая - но кому мешало знание базы?! Для примера там раcсматриваются Ingress controller на базе Nginx и cert-manager. А далее по шагам разбирается:
- Конфигурирование controller для работы с SSL
- Создание Secret с информацией о сертификате
- Добавление в Ingress ресурс информации о TLS
- Приобретение SSL сертификата и настройка cert-manager

При этом не забывайте, что можно одновременно использовать несколько Ingress controller и , конечно, о необходимости их своевременно обновлять ;)

На днях обновление получил документ "Cloud Security Technical Reference Architecture" от организации Cybersecurity and Infrastructure Security Agency (CISA). Полностью документ я еще не изучил, но беглое чтение по диагонали показало его интересность.

Я выделил несколько ключивиков, по которым вы можете определится стоит вам его изучать или нет.
- Continuous Monitoring
- Incident Handling
- Authorization Boundary
- Infrastructure as Code
- DevSecOps
- ZeroTrust
- Cloud Migration
- Cloud Security Posture Management (CSPM)

Слово Kubernetes там не упоминается ни раза =)

В моих книжных рекомендациях пополнение! Теперь к вот этим трем [1,2,3] добавилась еще одна книга - "Hacking Kubernetes: Threat-Driven Analysis and Defense".

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

Особое внимание можно обратить на такие главы как:
- Applications and Supply Chain
- Hard Multitenancy
- Policy
- Intrusion Detection

Приятного чтения)

Я уже писал, что веду 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. Аккуратно - на картинке есть опечатки!