Книга "Zero Trust Container Security for Dummies"

Цитата: "Zero Trust security takes a proactive approach to security. Instead of relying on reactive, signature-based protections, Zero Trust security is based on a declarative model in which you define acceptable behavior and block everything else. Allow lists are highly pronoscriptive and minimize the attack surface."

В этой мини книге (50стр) вы найдете хорошую теорию по ZeroTrust для контейнеров и рекламу решений SUSE.

kubectl-execws - утилита на Go, которая по сути является заменой kubectl exec, которая работает через WebSocket. Тоесть весь kubectl не нужен. При этом данная утилита может обходить Kubernetes API server (привет Kubernetes Audit Log!), благодаря прямому соединению с kubelet API, работающим на Nodes. Инструмент будет больше полезен для атакующих целей (привет сигнатуры на kubectl!).

P.S. Как работает kubectl exec можно узнать/вспомнить тут.

Всех поздравляю с 1 сентября! С Днем Знаний!

И хотел бы сегодня поделиться знанием, почему наше решение по безопасности для Kubernetes называется Luntry ("Лантри"). Хотя некоторые нас порой называют "Люнтри" и как вы увидите дальше это в принципе тоже верно.

И так, Luntry ("Лантри") это выдуманное слово, образованное от французского слова "Lune" (Люн), что в переводе значит Луна. Так что "Люнтри" это можно сказать произношение на французский манер =)

Почему Луна?
1) Как и многое в теме контейнеров и Kubernetes ("Штурвал") мы пошли от морской темы. Луна является для моряков спутником, светилом, ориентиром в темное время. Мы также являемся для пользователей Kubernetes – показываем и подсказываем что, где и как работает (плохо/хорошо/опасно/безопасно).
2) Обратная сторона Луны — часть лунной поверхности, которая не видна с Земли. И Лантри как возможность эту сторону увидеть, понять и контролировать ;)
3) Альбом "The Dark Side of the Moon" группы Pink Floyd никакого отношения к названию не имеет, но в легенду ложиться просто супер ;)

P.S. Интересно ли вообще информация о внутренней кухне, о разработке или лучше чисто писать про безопасность Kubernetes?

Сегодня хочу поделиться своими мыслями и наблюдениями (на наших клиентах) на тему NetworkPolicy (хотя это применимо не только к ним) и работе/поддержке/сопровождению их - по-модному Day 2.

Многие думают, что, написав или сгенерировав ресурс NetworkPolicy для микросервисов, дело сделано, но по факту все только начинается ... Теперь становится нужно контролировать что:
1) политики применились к чему нужно и не более
2) политики находятся в актуальном состоянии и вовремя обновляются
3) политики не отвалились ввиду изменений в микросервисах
4) все ваши департаменты в курсе того какой микросервис как ограничен
5) все ваши процессы учитывают наличие политик

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

Ко мне самому осознание этого пришло не сразу, а в процессе, когда мы делали соответствующую функциональность, помогающему клиенту решить эти проблемы в момент, когда количество его NetworkPolicy сильно перевалило за сотню.

Так что если вы только на пути к NetworkPolicy - не забывайте о том, как вы будете с ними жить в Day 2 ;)

В официальной документации Kubernetes появился раздел Security Checklist. Он состоит из самых базовых рекомендаций по аспектам:
- Authentication & Authorization
- Network security
- Pod security
- Enabling Seccomp
- Enabling AppArmor or SELinux
- Pod placement
- Secrets
- Images
- Admission controllers

Отдельно обратите внимание на предупреждение в начале раздела, чтобы у вас не сформировалось ложного представления об этом checklist'е!

P.S. На канале публиковались и другие подобные чеклисты [1,2] ;)

Если вы до сих пор задаетесь вопросом что такое Distroless Images, то крутецкая статья "What's Inside Of a Distroless Image - Taking a Deeper Look" даст вам ответ на этот вопрос и посмотреть еще глубже, что у них там под капотом! Краткое содержание:
- Сложности работы с scratch containers
- Вариант distroless/static и его специфика
- Вариант distroless/base и его специфика
- Вариант distroless/cc и его специфика
- Вариант для interpreted или VM-based languages
- Общая оценка использования distroless images
- Классная подборка дополнительных материалов по теме

Очень классно, так это демонстрация каждого варианта через утилиту Dive, через которую понятно все содержимое данных образов.

Так что после прочтения статьи вы поймете что distroless images бывают разные =)

Сточки зрения ИБ я повторюсь [1,2,3,4], что это позволяет уменьшить attack surface, усложнить закрепление атакующему, снизить шум от сканеров известных уязвимостей, тоесть вещь MUST HAVE!

P.S. Результату голосования по данной теме тут.

Официальная документация Kubernetes продолжает радовать отличными разделами и сегодня это "Kubernetes API Server Bypass Risks". Такими темпами авторам книг про безопасность Kubernetes не останется тем ;)

И так, Kubernetes API Server имеет встроенные механизмы безопасности (audit logging, admission controllers) и все должно проходить через них. НО есть ряд путей, которые позволяют их обойти! Вот как раз таким путям и их митигации и посвящена данная страница документации.

Выделено 4 пути обхода через:
- Static Pods
- The kubelet API
- The etcd API
- Container runtime socket

Если честно, то описанное в пункте про Static Pods не соответствует результатам наших экспериментов, о которых мы писали тут. Кто-нибудь еще пробовал? Нужно разобраться кто не прав)

Стали доступны видеозаписи выступлений с Open Source Summit Latin America 2022. Конечно же не обошлось без тем о безопасности Kubernetes. Я для себя выделил:
- "Exploring Runtime Security and Forensic using eBPF" - очень базовый доклад с примерами на Tracee в конце.
- "A Checklist for Security from the Container to the Kubernetes: An Overview End to End " - упоминание chain-bench и двух checklists: Kubernetes Security Checklist и Container Security Checklist.
- "Edit, Debug, & Secure the K8s Manifest Lifecycle: Why is it Important and How Can You Get it Right?" - про жизненный цикл YAML manifests и работа с ними с помощью утилиты monokle (обратите внимание)!
- "Building a Secure By-Design Pipeline with an Open Source Stack" - доклад про kubescape.
- "SOAR with Postee: Automated Incident Response for Cloud Native Risks" - доклад про Postee. Данный доклад можно сравнить с моим докладом про SOAR.
- "MLSecOps with Automated Online and Offline ML Model Evaluations on Kubernetes" - MLSecOps 0_o

Тут попалась любопытная заметка "Implementing Quarantine Pattern for Container Images". Под карантином тут понимается специальный registry для плохих образов (не удовлетворяющих тем или иным внутренним требованиям). Помимо выделенного registry также задействуются:
- Quarantine Flag
- RBAC
- Policy Engine

По сути это частный случай концепции Registry Staging из "CLOUD NATIVE SECURITY WHITEPAPER".

PCI Security Standards Council выпустил документ "Guidance for Containers and Container Orchestration Tools", делался он в рамках специальной SIG группы и по сути состоит из 3-х частей:
1) Общая информация о контейнерах и оркестраторах - совсем базовая информация. Kubernetes упоминается 4 раза на документ ;)
2) Списка угроз и best practices для противодействия им в контейнерных окружениях - основное мясо документа
3) Примеры для работы с угрозами и практиками - 4 use-cases

Рассматриваемые темы:
- Authentication
- Authorization
- Workload Security
- Network Security
- PKI
- Secrets Management
- Container Orchestration Tool Auditing
- Container Monitoring
- Container Runtime Security
- Patching
- Resource Management
- Container Image Building
- Registry
- Version Management
- Configuration Management
- Segmentation

Документ хороший - рекомендую к ознакомлению! Какой-то карточной специфики там особо нет, так что может быть полезен всем.

Завтра подсвечу наиболее любопытные моменты на мой взгляд.

Как и обещал сегодня поделюсь своим мнением о наиболее интересных моментах из документа "Guidance for Containers and Container Orchestration Tools" и, конечно, это будет из раздела 3.1 Threats and Best Practices, как самого интересного с технической точки зрения.

1) Я не понял смысл и пользы от разделения на “Applicable to Use Case”. В некоторых моментах я вообще не согласен. Например, пункт 11.1 Resource Management говорит, что работа с Limits есть только в Containerization in a Mixed Scope Environment, а в других случаях не важно. Поэтому я бы советовал смотреть на эти колонки с достаточной толикой скептицизма.
2) Важный пункт 4.1,4.2 Network Security прямо говорит о подходе запрещено все, что не разрешено и не двузначно намекает о использовании NetworkPolicy ;)
3) Удивило требование 4.3 Network Security про шифрование общения с API оркестатора, которое я нигде ранее не встречал. В угрозе написано про "packet sniffing or spoofing attacks", но подобного я лично никогда не наблюдал, хотя теоретически это возможно и скорее всего атакующий будет это делать в тех условиях, когда это можно сделать другим более легким способом.
4) В пункте 6.1 Secrets Management прямым текстом написано, что для работы с секретами нужно использовать стороннее решение за пределами кластера: "should be held in encrypted dedicated secrets management systems". Seald Secret и подобные проекты по push-модели совсем не в почете?!
5) Пункт 8 Container Monitoring - бальзам на мою душу, так как это было в точности то, что мы в первую очередь реализовали в Luntry.
6) Пункт 9 Container Runtime Security (почему-то он не часть пункта 8) несет в себе как по мне спорные моменты - мы увеличиваем изоляцию, но теряем в наблюдаемости. И, по сути, выигрыш только в усложнении побега из контейнера через уязвимости ядра и не более.
7) Понравился пункт 13.2 Registry в котором говорится про Registry Staging, о котором я писал недавно.
8) Пункт 15. Configuration Management полезная напоминала про важность pre-prod окружения для security.
9) Пункт 16. Segmentation это про multitenancy ;)

Еще один обзор на "PCI Guidance for Containers and Container Orchestration Tools" от известного западного коллеги. При этом он создал документ (xls, pdf) описав каждый из пунктов раздела 3.1 Threats and Best Practices со спецификой Kubernetes! Так что настоятельно рекомендую с ним ознакомиться.

В ближайшие дни мы с моим коллегой из Luntry представим аж две новые презентации про pentest и digital forensic в Kubernetes:
- 15 сентября. 14:40. KazHackStan 2022 (Казахстан, Алматы) - "Специфика расследования инцидентов в контейнерах", Дмитрий Евдокимов
- 15 сентября. 15:45. CyberCamp 2022 (online) - "Расследование инцидентов в средах контейнеризации", Сергей Канибор
- 18 сентября. 12:00. HackConf 2022 (Санкт-Петербург) - "Pentesting Kubernetes: From Zero to Hero", Сергей Канибор
- 20 сентября. 19:15. VolgaCTF 2022 (Самара) - "Pentesting Kubernetes: From Zero to Hero", Сергей Канибор

И бонусом еще участие в круглых столах и meetup:
- 22 сентября. 20:20. Innopolis meetup: DevOps (Иннополис) - "Кто и что такое CTO в ИТ startup’е?", Дмитрий Евдокимов
- 23 сентября. 11:00. Kazan Digital Week 2022 (Казань) - круглый стол "Облачные технологии в финтех", Дмитрий Евдокимов


Обратите внимание на обширную географию и на возможность посмотреть одно из выступлений в online! И мы как всегда будем рада новым знакомствам и общению - так что не стеснитесь подходить на конференциях ;)

Крохотная иллюстрированная заметка о том как по шагам работает Kaniko, о котором я уже пару раз писал [1,2].

Безопасная сборка образов в кластере Kubernetes это очень важно - это помогает следовать принципу наименьших привелегий!

Определение уязвимостей, для исправления которых следует отдать приоритет, и обеспечение того, чтобы эти исправления действительно сделали вашу систему более безопасной, — одна из самых сложных задач, с которыми может столкнуться команда безопасности.

И тут на помощь приходит Vulnerability Exploitability eXchange (VEX) и о нем идет речь в статье "How a Vulnerability Exploitability eXchange can help healthcare prioritize cybersecurity risk".

VEX это концепция и machine-readable формат, которая может использоваться со SBOM, так и без него. Его основная цель дать понятие к чему уязвим данный продукт и дать рекомендации по исправлению. При этом он учитывает, что наличие уязвимости не говорит о ее эксплотируемости в конкретном случае (non-exploitable vulnerabilities). И имеет статус:
- Not affected
- Affected
- Fixed
- Under Investigation

Данная информация призвана упростить определение приоритетов исправления уязвимостей. Пример VEX можно посмотреть тут.

В общем авторы статьи рисуют будущее в духе: SBOM+VEX+SLSA

P.S. Из статьи мне понравилась фраза: "Without the ability to see into what we must protect, it can be difficult to determine how to quickly reduce risk."

Мои слайды "Специфика расследования инцидентов в контейнерах" c KazHackStan 2022.

Буду рад ответить на любые вопросы в комментариях!

P.S. Обратите внимание, что некоторые спрашивают и ведут диалог в чате канала.

Хочу обратить отдельное внимание на Kubelet Checkpoint API из презентации "Специфика расследования инцидентов в контейнерах" (слайд 34) c KazHackStan 2022.

Это реально крутое будущее как для security, так и для IT, на пример, для реализации live migration. Пока что данное API в Kubernetes находится в ContainerCheckpoint feature gate, который по умолчанию отключен, и очень ограничен и упрощен:

POST /checkpoint/{namespace}/{pod}/{container}

Тоесть пока что можно просто сделать checkpoint/snapshot и потом в ручную с ним поработать. Но мы то знаем что под капотом у него CRIU (Checkpoint and Restore in Userspace), который может это и восстанавливать и запускать! Полностью с этим можно поиграться сейчас можно в Docker при активации Docker Checkpoint (экспериментальная фича).

А так представьте, что можно будет брать и контейнер с атакующим переносить (делать live migration) в sandbox cluster и там наблюдать и изучать его действия ;)

Слайды моего коллеги "Pentesting Kubernetes: From Zero to Hero" c VolgaCTF 2022.

Задавайте свои вопросы в комментариях!