Как мы уже неоднократно рассказывали одним из способов уменьшить «шум» от сканеров известных уязвимостей — это уменьшить количество компонентов, которые лежат в образе. И к этому глобально можно подойти 2 способами (multi-stage сборку рассматриваем как само собой разумеющееся):
1) На основе специализированного образа (scratch, alpine, distroless, chainguard)
2) На основе динамического анализа

Если о первом способе мы много пишем и многие знают, то про второй как раз нет. Ввиду того что нужен специальный инструментарий для этого. И такой инструментарий как раз есть - проект Slim (или SlimToolkit ранее известный как DockerSlim).

Проект позволяет посмотреть, что действительно используется во время работы и только это и оставить в итоговом образе! Но как вы понимаете тут очень важно (как и в случае любого динамического анализа) это покрытие кода тестами ...

Но сегодня хотелось бы отметить и еще одну новую экспериментальную фичу/флаг --obfuscate-metadata, которая вдохновлена докладом "Malicious Compliance" (мы писали о нем тут и тут). Да, он автоматом обфусцирует (реализация тут) данные о пакетах python, ruby, node и сканеры не видят уязвимости ;)

И повторим важную мысль относительно сканеров уязвимостей: "Все подходы, анализы на базе статического анализа позволяют защититься только лишь от легитимного пользователя, но не являются никакой помехой для вредоносного"

kubernetes-for-soc – репозиторий, призванный ускорить процесс обучения аналитиков SOC, позволив им быстро освоить необходимые основные понятия и знания. Быстрый темп развития технологий оставляет SOC аналитикам мало времени для приобретения глубоких знаний и опыта, необходимых для эффективной защиты и/или мониторинга внедрений Kubernetes.

Репозиторий состоит из двух частей: threat model и observability (скоро обещают добавить третью часть – checklist). В нём отражены основные threats, threat actors, attack vectors и attack path присущие Kubernetes.

Но всё-таки это нельзя назвать полноценным руководством. Однако для SOC аналитиков, которые никогда не трогали Kubernetes будет полезно.

Хотим напомнить, что уже на следующей неделе, а именно 14 и 15 ноября нас можно будет найти на SOC-Forum 2023: там мы представим два доклада «SOC в контейнерах» и «EDR vs Containers: актуальные проблемы».

openSUSE MicroOS - еще одна container specific OS. Если Flatcar, Talos у многих уже на слуху, то эта ОС нет. По своей концепции она ближе к Flatcar. А так обладает всеми свойствами присущими специализированным ОС для запуска контейнеров. Видно, что направление развивается и все больше игроков/проектов появляется. Возможно, кому-то приглянется именно это реализации (в первую очередь ставим на пользователей Rancher).

Так уже в принципе глупо отрицать тот факт, что сегодня при построении контейнерной инфраструктуры требуется специализированная ОС, а не ОС общего назначения, чтобы получиться все преимущества от использования контейнеров как для сопровождения, так и для обеспечения безопасности.

Уже завтра стартует SOC Forum 2023, где наша команда Luntry представит 2 доклада. Также там у нас будет стенд с интересными подарками, которые можно получить за участие в небольшой игре/активности для которой мы приготовили вот такие карточки. Так что все кто будет на конференции - подходите, участвуйте, спрашивайте про безопасность контейнеров и Kubernetes!

С недавнего времени Kyverno теперь может валидировать не только Kubernetes, но и впринципе любые ресурсы. Мы уже рассказывали о возможностях Kyverno [1,2] и даже вкратце затрагивали проект json-validator, который скорее всего вылился в новый – kyverno-json.

Сейчас авторы предлагают использовать новый проект для валидации:

- Terraform files
- Dockerfiles
- Cloud configurations
- Service authorization requests

kyverno-json можно запускать как CLI, веб-приложение с REST API или использовать в качестве библиотеки Golang. Уже сейчас доступна небольшая библиотека политик для AWS, ECS и Dockerfile. Также есть возможность попробовать новый проект онлайн – по ссылке доступен playground.

Мало кто знает, но в документации Google Cloud есть прям замечательная (и очень большая) библиотека правил для OPA Gatekeeper - их там порядка 90! При этом они идут с примерами как удовлетворяющих их ресурсов, так и нет (считай тесты).

Отличная библиотека для вдохновения и оценки собственного набора политик. При желании тоже самое можно перенести и на Kyverno.

На недавно прошедшей конференции EnvoyCon был представлен довольно интересный доклад на тему security, а именно – Envoy Gateway End User Threat Model Report: Raising Awareness of Gateway API Security.

Также автор доклада поделился репозиторием созданным по мотивам доклада, где рассмотрел Compromised Proxy Scenario, Compromised Controller Scenario, нарисовал возможные деревья атак и приложил k8s ресурсы для воспроизведения своей демо из доклада

Напомним, что сегодня наша команда Luntry (достаточно в большом составе и оба авторы данного канала будут на сцене) будет на VK Kubernetes Conf! Там мы и доклад представим и в круглом столе про развитие Kubernetes поучаствуем (в следующем году ему будет 10 лет если отсчитывать от Initial release)!

Будем рады пообщаться лично =)

Недавно наши хорошие товарищи поделились (а теперь и мы с вами) своим проектом, которые они уже сами у себя используют более чем 2 года.

Проект называется k8s-calico-networksets-controller и он по сути добавляет поддержку FQDN в NetworkPolicy от CNI Calico!

Вся магия происходит с помощью selector в NetworkPolicy с определённым label и через создание/обновление Calico NetworkSet.

Если вам не хватало поддержки FQDN в NetworkPolicy от CNI Calico, то это решение для вас)

P.S. Всем хороших выходных!

В конце прошлой недели вышел Kyverno 1.11 с новыми возможностями:

1) Добавлен новый тип подправила validate.cel, позволяющий использовать выражения Common Expression Language (CEL) для проверки ресурсов.
2) Улучшения в Policy Report: теперь для каждого ресурса создается PolicyReport, который автоматически удаляется при удалении соответствующего ресурса. AdmissionReports и BackgroundScanReports теперь считаются эфемерными и очищаются после объединения в итоговые отчеты.
3) Обновления Notary: добавлена поддержка проверки аттестатов OCI 1.1.
4) Поддержка Cosign 2.0: теперь проверка Tlogs и SCTs включена по умолчанию и может быть отключена через атрибуты в политике.
5) Кэширование проверки образов для ускорения процесса.
6) Возможность очистки ресурсов через TTL label cleanup.kyverno.io/ttl. Присвоение метки ресурсу с необходимыми правами приведет к его удалению в указанное время.
7) Переработка CLI и новая схема тестирования.

Наш хороший товарищ Павел Сорокин (вы могли его видеть среди докладчиков на нашей конференции БЕКОН) у себя на канале сделал замечательную серию очень технических постов про hostPID: true и --pid=host:

Часть 1
Часть 2
Часть 3
Часть 4

А именно он разбирается к каким последствиям может привести наличие данных параметров и какие механизмы безопасности (Yama, AppArmor) каким образом могут это ограничить.

Также можно вспомнить про замечательный репозиторий BadPods и там также глянуть эту тему ;)

Заглянув в release notes к бета-версии Containerd v2, мы с радостью увидели изменение, запрещающее доступ к io_uring по умолчанию.

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

Помимо этого изменения, хотелось бы отметить ещё пару:

- Add support for userns in stateless and stateful pods with idmap mounts (KEP-127, k8s >= 1.27)
- Add support for user namespaces (KEP-127)

Совсем недавно прошла конференция KubeCon + CloudNativeCon North America 2023 и уже стали доступны и слайды и видео на их канале. Как всегда там море всего интересного!

Пока отдельно выделим один доклад "A Wind of Change for Threat Detection" от ребят из Apple, посвящённый проблемам rule-based detections в runtime в контейнерных средах. Как мы и говорим уже не один год все идет к поведенческому анализу.

И отдельно стоит отметить в первые проходившую Multi-TenancyCon NA 2023, которая отдельно проводилась в эти же дни. И видно как тема правильной организации multi-tenancy становиться актуальной для большого числа компаний.

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

Kubelet Serving Certificate Approver – репозиторий с контроллером, который аппрувит kubernetes-io/kubelet-serving CSR, используемый kubelet для обслуживания TLS endpoint. Проект поддерживает версии Kubernetes 1.22 - 1.28.

Контроллер может быть полезен, если:

- вы хотите установить безопасное общение с endpoint kubelet (с точки зрения СА)
- подписанные serving сертификаты рассматриваются сервером API как действительные сертификаты обслуживания kubelet
- не хотите использовать флаг --kubelet-insecure-tls во время установки metrics-server

К слову сказать, оригинальная идея принадлежит проекту kubelet-rubber-stamp, который не поддерживается уже 3 года.

Недавно давали интервью по поводу безопасности в Kubernetes и концепции ZeroTrust. Почитать можно тут, а свое мнение оставить в комментариях к данному посту ;)

Так предотвращать, дешевле чем расследовать =)

Всем хороших выходных!

Так как нашей команде Luntry часто приходится участвовать в различных проектах по безопасности Kubernetes систем: аудиты, пентесты, архитектурные проекты. То приходится порой думать о некоторых моментах, к которым просто так не придешь, никогда об этом не задумываясь. Одним из таких последних моментов был момент, когда требовалось понять стоит ли определенные высокопривелигерованные микросервисы (там хороший SA) располагать в одном Namespace или расселить на разные. При решении этой задачи как раз и пригодился наш атакующий опыт.

Смысл заключается в том, что если у злоумышленника на Node есть возможность создать Pod в таком Namespace (где и эти высокопривелигерованные сервисы), даже с учетом того что стоит множества правильных политик PolicyEnginе (против Bad Pods и тд), то у него все равно остаётся возможность смонтировать внутрь такого Pod интересующий его SA из того же самого Namespace! Далее когда он смонтируется туда, то можно смело забирать его с Node ...

Как митигейшены можно сделать следующее:
1) Чтобы уменьшить риск компрометации, критичные сервисы разделать по Namespaces
2) Namespaces c критичными/инфраструктурными сервисами привязывать только к определенным инфраструктурным Nodes
3) Писать политики PolicyEngine, которые проверяют использование критичных SA, только в определенных сервисах

P.S. Еще была крутая идея для атаки - все это провернуть через StaticPod, но там нельзя ссылать на другие ресурсы (на тот же SA)…

P.S.S. Ближайшие дни мы на HighLoad++ 2023 Msk и будем рады пообщаться лично =)

Казалось бы, инструмент IceKube – что-то новое и интересное в мире Kubernetes Security, но как бы не так.

Тулза умеет искать возможные attack path в кластере от самых минимальных привилегий до cluster-admin. Результаты своей работы отображает в графовой БД – Neo4j. На этом моменте нельзя не упомянуть инструмент, о котором мы рассказывали совсем недавно, и который, очевидно, был взят за основу – KubeHound.

Суть работы у IceKube точно такая же, даже вектора attack path одинаковые и ничего нового авторы не придумали. Но всё-таки отличия у инструментов есть – написаны на разных языках и IceKube имеет пару правил, относящихся к Managed Kubernetes, а именно AKS и AWS.

Для тех, кто хочет детальнее изучить инструмент, посмотреть на примеры и ознакомиться с проблематикой – рекомендуем статью "IceKube: Finding complex attack paths in Kubernetes clusters" от авторов тулзы.

29 ноября 2023 года в 11:00 наша команда Luntry примет участие в online эфире AM Live по теме "Защита контейнерных сред"! Дискуссия будет состоять из 3-х частей:
1) Угрозы и риски безопасности для контейнерных сред
2) Защита контейнерных сред на примере Kubernetes
3) Прогнозы

Подключайтесь, смотрите, потом можно будет еще в комментариях обсудить поднятые вопросы)

Статья с говорящим названием "Rootless Containers - A Comprehensive Guide" расскажет все о rootless контейнерах и врятли у вас останутся еще какие-то вопросы по данной теме после ее изучения.

В качестве Rootless контейнеров приводятся и частично рассматриваются:
- Docker rootless-mode (c 19.03)
- Podman rootless-mode
- BuildKit rootless-mode
- LXC unprivileged-mode
- Apptainer userns-mode or fakeroot-mode

Не обошлось тут и без рассмотрения темы User Namespaces ;)

В Москве прошел HighLoad++ 2023 и мне там довелось побывать ведущем одного из залов, где основная тематика была Security и Platform engineering. Если с первой темой все более-менее понятно (сюрпризом было только упоминание на слайдах нашего решения Luntry в контексте поведенческого анализа), то на второй теме хотелось бы остановиться и поделиться своими наблюдениями (IMHO):
1) У зрелых IT компаний есть зрелые продвинутые платформы, полируемые уже не 1 год
2) Platform team в таких компаниях становиться "тесно" в рамках одной компании со своим продуктом
3) Данные Platform в разном виде: Dev Platform, Self-hosted облачные платформы как на базе Kubernetes, так и нет хочется/планируется выводить во внешний Мир

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

И да, я как один из участников программного комитета конференции DevOpsConf призываю всех присылать заявки (до 15 декабря) на доклады нам! Я лично с радостью рассмотрю и помогу с заявками по теме Security, Kubernetes и Platform engineering ;)

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

Мы привыкли, всегда говоря о Kubernetes, говорить про оркестратор, фреймворк, платформу, НО по сути на сегодняшний день это же и в каком-то роде определенный СТАНДАРТ. При этом, честно говоря, в этом стандарте есть и хорошее, и плохое (как и в любом стандарте). И у всех одинаковые боли, проблемы в инфраструктуре и, по сути, одинаковые решения, которые можно прийти и обсудить в сообществе у которого все тоже самое и они уже это проходили или банально найти специалистов. Такого бы не было если у вас кастом. При этом это касается любой темы и направления: reliability, observability и security.

Как по мне стандартная проблема, лучше специфичной =)
А что вы думаете на этот счет?

Всем хороших выходных!