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
Дискуссия!

По идее на прямую доступ к Kubernetes API никто не имеет (либо пользуются этим в исключительных случаях) и раскатывают все через Git (GitOps, GitOps operatos и т.д.). В общем Git является источником правды (root of trust). Хочешь что-то изменить - закомить сначала в Git, пройди все pipelines и только тогда попадай в Kubernetes.

Но в вопросах безопасности порой чрезвычайно важна скорость реакции, что приводит к необходимости обхода стандартных путей или их сокращению. И как следствие ломается концепция root of trust ... И системы становится в некотором плавающем, неопределенном состоянии, непонятным для всех команд, кто не в курсе этого (Dev, Ops, SRE и т.д.).

Например, в обход Git выкатили/изменили/откатили/... NetworkPolicy или политику PolicyEngine. (Я не говорю уж о способах, которые это делают совсем не явно для инфраструктуры)

Безопасность должна обеспечивать непрерывность работы бизнеса, а не палки в колеса.

Как вы думаете как это должно выглядишь правильно ?
👍1
Конкурс!

14 июня на конференции DevOpsConf 2022 в Москве я выступлю с докладом "SOAR в Kubernetes малой кровью". Благодаря организаторам у меня появилось возможность разыграть 1 online билет!

SOAR расшифровывается как Security Orchestration, Automation and Response. Это такой класс ИБ решений, который предназначен для оркестрации систем безопасности - автоматизировать типовые сценарии реагирования на события ИБ. Я данную тему поднимал уже не однократно [1,2,3,4,5].

На мой скромный взгляд в Kubernetes на базе его концепций (reconciliation loop, декларативная природа и т.д. ) можно построить не только self-control, self-healing, но и self-defence систему.

В комментариях для данного поста напишите сценарий в области ИБ в Kubernetes, который бы вам хотелось бы (или он уже у вас реализован) обрабатывать автоматизировано: случилось что-то и на это последовала какая-то реакция. Варианты принимаются до 03.06.2022. Выбирать буду я на свой субъективный взгляд ;)
🔥4👍21😁1
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