k8s (in)security – Telegram
k8s (in)security
12.1K subscribers
1.01K photos
38 files
1.56K links
Канал о (не)безопасности Kubernetes + микросервисных, контейнеризированных приложений.

Ведет команда www.luntry.ru

Вопросы, идеи, предложения => @Qu3b3c

https://knd.gov.ru/license?id=673ddbc21039886b1d03b7ce&registryType=bloggersPermission
Download Telegram
Trivy Operator PolicyReport Adapter - проект, предназначенный для перевода CustomResources от Trivy Operator (Не понял чем он отличается от Starboard-operator) в унифицированный формат PolicyReport и ClusterPolicyReport от Kubernetes Policy Working Group. Это позволяет использовать проект Policy Reporter для работы с различными результатами политик и сканов.

Таким образом в одном интерфейсе можно работать с:
- VulnerabilityReports
- ConfigAuditReports
- CISKubeBenchReports
- ComplianceReports
- И результатами работ того же Kyverno.

Все декларативно и при этом в одном интерфейсе.
👍7
Крутой GitHub репозитарий "Software Supply-Chain Security Reading List" - в общем все о Supply-Chain Security. Содержит следующие разделы:
- Policy - где это вообще требуется и описывается
- Incidents/Threats - уже случившиеся инциденты
- Solutions - решения из данной области
- Organizations - организации, занимающиеся данным вопросом
- Background - полезные материалы для понимания данной области
- Reports and summaries - различные документы и отчеты по данной теме

Тема хоть для многих и не столь актуальная сегодня (ввиду текущего уровня зрелости ИБ), но явно таковой станет.
🔥9👍3
Недавно мы с коллегой выступали на конференции с докладом "NetworkPolicy — родной межсетевой экран Kubernetes". Сейчас доступна запись и можно изучить ее и разобраться чем отличаются и что могут Native и Custom NetworkPolicy на базе Calico и Cilium.

+ раз и навсегда понять зачем не нужно в Kubernetes городить своих огородов из разных костылей и искать железку в стойку ;)

Приятного просмотра!
🔥14👍7
Если вы планировали провести эти выходные с пользой, то как раз для вас CNCF выложил записи докладов (+ слайды) с недавно прошедших своих сессий:
- KubeCon + CloudNativeCon Europe 2022
- ServiceMeshCon EU 2022
- Kubernetes on Edge Day EU 2022
- Kubernetes Batch + HPC Day EU 2022
- Cloud Native SecurityCon EU 2022
- Kubernetes AI Day EU 2022
- Cloud Native Wasm Day EU 2022
- FluentCon EU 2022
- KnativeCon EU 2022
- GitOpsCon EU 2022
- Cloud Native Telco Day EU 2022
- PrometheusDay EU 2022
- Cloud Native eBPF Day EU 2022

Обратите внимание, что доклады на тему security были не только на Cloud Native SecurityCon, но и в основной программе, и в других сессиях ;)

Наиболее интересные на мой взгляд доклады по security я выделю отдельно.
🔥19🥰3
Документация Kubernetes это все-таки кладезь полезных материалов. Сегодня хочу подсветить недавно появившуюся страничку "Role Based Access Control Good Practices". Она содержит:
- General good practice
- Kubernetes RBAC - privilege escalation risks
- Kubernetes RBAC - denial of service risks

Обязательно к чтению!
👏13
Mind map для Linux privilege escalation. Может быть полезно если нужно поднять привилегии в контейнере ;)
🔥19👍7
Как активно для своих микросервисов в Kubernetes вы используете distroless образы?
Final Results
6%
Очень активно
17%
50/50
22%
Очень неактивно
55%
Не применяем
Не многие знают, но я периодически провожу тренинг "Cloud Native безопасность в Kubernetes" — это 3-х дневное обучение для компаний. Это теоретический курс, который покрывает абсолютно все аспекты безопасности Kubernetes, но обратной стороной его всеобъемлемости является отсутствие практики.

И вот мы с товарищем некоторое время назад решили это исправить и сделать практику, которая будет выполнена в виде специальной лаборатории (образ VM).

Какие основные идеи мы туда закладываем:
- Обучение без учителя (задания и прохождения в одном флаконе для спокойного самостоятельного изучения)
- Упражнения на все темы какие только возможны в области безопасность Kubernetes
- Упражнения на атаку и защиту
- Знакомство со множеством OpenSource проектов
- Minikube в несколько Nodes (ничего ставить не надо)
- CNI на выбор calico и cilium (важно для темы NetworkPolicy)

Мы рассчитываем все завершить к концу 3-4 квартала этого года. Будем рады услышать любые идеи и предложения!
🔥59🥰4👎2
Совсем недавно я с коллегой выступал на конференции HighLoad++ Foundation 2022 в Москве с докладом "eBPF в production-условиях". Сейчас хочу поделится слайдами и видео с нашего выступления. По теме безопасности eBPF мы рассмотрели такие аспекты как:
- Safety и security eBPF
- BPF_LSM
- Уязвимости в подсистеме eBPF
- Вредоносный код на eBPF
- capability для работы eBPF
- Подпись eBPF программ

В комментариях можно, как всегда, поспрашивать вопросы по данной теме! В нашем решении мы активно используем eBPF, так что знаем о нем не понаслышке.
🔥16👍4👎1
Отличный лооонгрид "Cracking Kubernetes RBAC Authorization Model". Если вы хотите из одной статьи узнать, что и как там устроено в Kubernetes RBAC, то это то, что вам нужно! Проще сказать, чего там нет по данной теме: специфика verb, моменты с Aggregated ClusterRoles и subresources. Ну и вопрос повышения привилегий (1,2,3,4,5) остается за рамками данной стать. Все остальное есть и продемонстрировано очень хорошо!
🔥12👍2
Скорее всего о том, что можно назначать запуск определённых Pods на определенных Nodes (с помощью тех же NodeSelector, nodeAffinity) вы в курсе. И о том, что в этом задействованы Node labels вы также в курсе.

Но в курсе ли вы о том, что на базе этого для правильной реализации концепции Node isolation/restriction необходимо использовать labels с определенным prefix?!

node-restriction.kubernetes.io/ - специализированный prefix в сочетании с NodeRestriction admission plugin предотвращает от настройки и модификации kubelet данного label!

Таким образом, атакующий, попавший на Node, не может модифицировать такой label и тем самым заставить определённые Pods запустить на себя. На пример, в инфраструктуре есть Node с лейблом type, который может принимать значения frontend, backend, pci-dss. Атакующий, попав на frontend не сможет заставить запускаться на ней Pods с pci-dad.

По данной теме посмотрите еще данный пост.

P.S. Сегодня первый день DevOpsConf 2022 - буду рад пообщаться лично, пообсуждать Luntry, Kubernetes и т.д. !
🔥8
Достаточно лаконичная картинка из статьи "How to Spot Gaps in Your Public Cloud Kubernetes Security Posture", отражающая различные области/аспекты ИБ для той или иной части Kubernetes кластера. На картинке отображено не все, но для старта самое то =)

P.S. Сегодня на DevOpsConf 2022 в 12:10 в зале ОргМет я выступаю с докладом "SOAR в Kubernetes малой кровью" - приходите и смотрите online.
👍9
"Bypassing Falco: How to Compromise a Cluster without Tripping the SOC" - наверно моя любимая презентация с KubeCon + CloudNativeCon Europe 2022.

Для тех, кто давно и активно занимается безопасность/пентестами/аудитами/... контейнеров здесь ничего нового - давно успешно применяют в работе ;) Но вот если вы еще верите в 2022 году в СИГНАТУРНЫЕ подходы, то вам это будет очень полезно посмотреть (слайды, видео).

Автор также выложил на GitHub весь исходный код, что он использовал, и готовый image со снипетами атак.

Также посмотрите мои прошлые посты (1,2,3) про обход правил Falco. Вообще это проблема любого rule/sigtnature-based решения ... Свой взгляд на эту проблему я подробнее раскрываю в докладе "Kubernetes: Observability важная часть Security" с Kuber Conf 2021.

P.S. Так пентестерам будет очень полезно посмотреть, как быть невидимыми для SOC ;)
👍7🔥2
На сайте 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, которые уже можно взять к себе на проработку ;)
🔥15🥰2🤔1
Используете ли вы immutable OS на Nodes в Kubernetes кластере?
Final Results
18%
Да
37%
Нет
45%
Что это такое?
Еще одна впечатляющая работа с 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 моды!
🔥14👍4
Очень крутая статья `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) на разные случаи жизни подготовила.

Также не забывайте о них и при анализе безопасности своих микросервисов и окружения (а то бывает вот так).
👍5🔥2
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. К сожалению, часто при описании тулы, упоминаются фичи платной версии.
👍4
Если у атакующего в контейнере есть капабилити CAP_SYS_ADMIN или он находится в привилегированном контейнере (securityContext.privileged:true), то для побега из контейнера ему даже не требуется никаких уязвимостей! Пускай у вас там хоть все запатчено и перепатчено =)

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

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

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

P.S. Еще можете посмотреть такой кейс с core_pattern
👍10
Молодой 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 в другие системы и т.д.).
👍9