Мне очень нравится концепция SBOM, но к сожалению как и любой стандарт в этом мире он имеет одну и ту же проблему ...

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

Постепенно люди создают issue, MR для исправления этого, но ментейнеры пока не особо спешат это менять.

Релизнулся Kubernetes 1.26 под кодовым названием Electrifying, а с ним и новые версии v1.22.17, v1.23.15, v1.24.9, v1.25.5! Но вернемся к 1.26 - там 37 новых улучшений (11 Stable, 10 Beta, 16 Alpha) и 12 фич было убрано.

А связанного с security на этот раз там совсем мало:

1) Signing Kubernetes release artifacts graduates to Stable [SIG Release] - нужное и ожидаемое развитие
2) CEL in Admission Control graduates to Alpha [SIG API Machinery] - забавная и неожиданная фича, заслуживающая отдельного поста

В Kubernetes 1.26 появилась новая v1alpha1 API фича - валидация admission policies.
Благодаря данному нововведению можно в admission control через Common Expression Language выражение добавить собственную проверку (соответствие политики)!

Сейчас для такого используются admission webhooks, которые пересылают запрос/ресурс на тот или иной (как правило) Policy Engine (Kyverno, OPA Gatekeeper), где происходит проверка на соответствие политики. С данным нововведением никакой пересылке не происходит, и проверка происходит сразу в Kubernetes и его же силами!

Для активации этого необходимо включить:
- ValidatingAdmissionPolicy feature gate (так называется и новый тип ресурса)
- admissionregistration.k8s.io/v1alpha1 API через --runtime-config

Для более детального погружения - рекомендую почитать два KEP:
1) KEP-3488: CEL for Admission Control
2) KEP-2876: CRD Validation Expression Language

P.S. Ну что заменит эта фича Policy Engines ?)

Мы сейчас живет во время платформ и сегодня почти все строят свои платформы вокруг Kubernetes! Я так за последнее время узнал о порядка 8 отечественных заменах OpenShift =)

Так как как под капотом таких платформ находится ванильный Kubernetes и его берут как есть (те пресловутые 4/5 бинарей и другие артефакты), то важно проверять их целостность (integrity). Кстати, это же касается и облачных провайдеров, что предлагают услугу managed Kubernetes.

В блоге Kubernetes вышла заметка "Kubernetes 1.26: We're now signing our binary release artifacts!", которая как раз может помочь вам проводить подобные проверки.

Сегодня хочу со всеми поделиться записью выступления и слайдами со своего доклада "Сочетание несочетаемого в Kubernetes: удобство, производительность, безопасность" c HighLoad++ 2022 Msk.

Буду рад ответить на любые вопросы ;)

Изучая на просторах сети различные кастомные реализации собственных аналогов Policy Engine (для проверки Kubernetes ресурсов), частенько встречаю такое как на скриншоте.

И решил составить свой небольшой топ проблем подобных решений:
- Малый набор поддерживаемых ресурсов - как правило только native ресурсы для workloads. В итоге работают те же обходы, что и для PSP.
- Собственный, ограниченный синтаксис для правил, который применяется только там и нигде более.
- Возможность обхода проверок на уровне Pods за счет, промежуточной модификации родительского ресурса через тот же Mutating Admission Controller

Стали доступны материалы с OSS Japan 2022 - все видео тут. В рамках данного мероприятия были отдельные направления и я особенно выделю: ContainerCon и OpenSSF Day.

На последнем было четкое попадание в тематику нашего канала - "Protecting Kubernetes Resource Manifests in End-to-end SDLC".

А так как я топлю не только за security, но и realiability (по мне они не отделимы), то так же хочу поделиться информацией, что стали доступны доклады с SREcon22 Europe/Middle East/Africa. Там, кстати, тоже не забывают про безопасность, на пример, доклад - "How Can SRE Help Security Governance? Sub-title: How to Unstuck GRC with SRE".

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

Один из самых сложных вопрос, который меня периодически спрашивают: сколько времени вы занимаетесь/разрабатываете Luntry? Тяжелый он для меня, потому что смотря с какого момента вести отсчет... В основе нашего решения по защите контейнеров и Kubernetes, есть мысли и идеи, которые были в моем другом проекте (который не выстрелил) по защите IoT, embedded devices и т.д. Так что сейчас у нас есть немного кода, который был и лет 5 назад =)

По сути тогда и сейчас мы имеем дело с ОС Linux, также, тогда мы работали с иммутабельными прошивками устройств, а сейчас с иммутабельными образами контейнеров! Вот так нам удалось идеи из одной сферы перенести в другую ;)

Пост из рубрики "Знали ли вы?" =)

Детали по этому поводу тут и тут.

Пояснение от разработчиков k8s:
"It's not quite the same (and thank goodness). This does not generate local endpoints for you. You can't get an automatic LB from it. It generally can't be used behind an Ingress.

All it produces is the equivalent of a CNAME record."

Это также на тему использования NetworkPolicy и PolicyEngine ;)

Вот и в новой блоговой записи появилась информация о новой security фичи "Kubernetes 1.26: Introducing Validating Admission Policies". О данной фичи я уже писал ранее и об этом можно почитать тут.

Из нового тут можно у знать о следующих моментах:
Во-первых, для работы с этим механизмом появился не один новый ресур, а два, которые работают в связке:
- ValidatingAdmissionPolicy - описание политики.
- ValidatingAdmissionPolicyBinding - где политика должна применяться (namespaceSelector, objectSelector).

Во-вторых, стало известно о возможности параметризировать политики за счет связей/отсылок на другие Kubernetes ресурсы (ну прям полная Policy-as-Code).

В-третьих, появлении в официальной документации раздела "Validating Admission Policy", где можно обо всем узнать еще более подробно о данной фиче, на основании различных примеров.

Недавно помогали одному из клиентов с такой задачей.

Задача: На каждой Node (с учетом ее типа Master/Worker) с определенной периодичностью, необходимо запускать тот или иной workload, выполняющий определённую логику (установка параметров, сбор данных и т.д.).

Важно, что это Oneshot задача, на каждой Node (не забываем, что они могут появляться и исчезать), выполняющаяся по какому-то расписанию. То есть, по сути, это такое сочетание DaemonSet (гарантирует присутствие на каждой Node) и CronJob (запускает задачу по расписанию и по завершению исчезает).

Единого, встроенного ресурса, выполняющего такую логику в Kubernetes НЕТ! Обсуждение этого момента можно найти, на пример, тут:
- #36601 CronJob daemonset (previously ScheduledJob)
- #64623 Run job on each node once to help with setup

Вариантов реализации разного уровня упоротости я нашел аж 6 штук. Но хотел бы тут поделиться одним, реализованным сторонним проектом OpenKruise. Там есть operator, который управляет 2 новыми сущностями (Custom Resources), решающими как раз данную задачу:
1) BroadcastJob
2) AdvancedCronJob

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

Сегодня хочу всех познакомить с одним удивительным проектом о котором я узнал достаточно недавно - Nixery.

Данный проект позволяет легко, на лету запросить образ контейнера с необходимым набором инструментов в нем, просто перечислив их через слеш в URL - вот в такой вот манере:
- docker run -ti nixery.dev/shell/git/htop bash - образ с интерактивными шелом, git и htop утилитами.
- docker pull nixery.dev/shell/ps/findutils/tshark - образ с интерактивным шелом, ps, findutils и tshark утилитами.

Базируется это все на Nix package manager и optimized layering strategy.

Очень удобно когда нужен образ с каким-то утилитами, а готовить его самостоятельно долго. Вот тут есть классный пример применения для отладки distroless образов.

https://ima.ge.cx/ - простенький online проект для быстрого просмотра содержимого образа из публичного реджистри. Для этого достаточно просто прямо в URL указать интересующий образ.

В общем, полезно как для ленивых, так может и для тех кто работает в закрытых контурах, чтобы зря ничего не качать ;)

Сегодня в фокусе нашего внимания исследование "Supply-Chain Security: Evaluation of Threats and Mitigations" об атаках и методах защиты цепочки поставки с оценкой их эффективности. Понравилось, что это все на примерах с реальной оценкой, а не просто на теории.

Содержимое:
- Review and re-evaluation of supply chain
- Model of modern typical CI/CD pipeline
- Attack injection point versus attack execution point
- Supply chain attacks and mitigations
- Summary of threat model (PDF)
- Summary of Mitigations (PDF)
- Source Repository
- Secrets
- Signing
- Dependency Tracking (SBOM)
- Attestation
- Example of a Centralized CI Pipeline

Как один из выводов это важность centralized CI pipeline для обеспечения Supply-Chain Security.

Если начинать потихоньку подводить итоги 2022 года, то самыми интересными для меня (IMHO) и нашей команды Luntry открытиями/прорывами/адаптациями/... года в области Kubernetes security стали:
1) Тема container specific OS - в этом году поглубже погрузился в данную тему и вообще по индустрии видно пристальный взгляд на это направление
2) Chainguard images - distroless images набирают обороты и становятся все доступнее, как раз благодаря вот таким вот проектам
3) Фичи в новых версиях Kubernetes - в этом году вышли 1.24, 1.25, 1.26:
- UserNamespacesSupport
- Forensic Container Checkpointing
- Поддержка cgroup v2
- Admission Policies

А как у вас в этом вопросе?)

Вообще я не любитель давать какие-то прогнозы, но тут что-то самому захотелось (самого себя проверить что ли через год) немного заглянуть в будущее и посмотреть, что нас ждет с в техническом плане с безопасностью контейнеров и Kubernetes в новом 2023 году. Возможно, сказывается то, что за этот год пришлось взаимодействовать с огромным количеством разных компаний из различных отраслей по вопросом контейнеризации (чего раньше в таких масштабах у меня не было). А также, участие в программном комитете DevOpsCоnf и еще более шире увидеть, что и в каком состоянии сейчас находится в индустрии в целом.

Кратко:
1) Повышенное внимание регуляторов к контейнерам
2) Платформизация систем компаний
3) В DevSecOps развитие Security Gate и ASOC систем
4) Ориентир на Security Observability
5) Рост атак на контейнерезированные окружения, важность безопасности supply chain

Более подробно с разъяснениями вот тут.

Есть еще Нострадамусы? То welcome в комментарии!

И сегодня подведем итоги 2022 года и немного заглянем в 2023:
1) Наш проект Лантри постепенно начинает помогать все большему и большему количеству компаний, использующих Kubernetes!
2) Данный канал продолжает расти (> +1600) и надеюсь радовать вас интересным и качественным контентом.
3) Наша небольшая команда в этом году приняла участие более чем в 12 мероприятиях по безопасности Kubernetes [1,2,3,4,5,6,7,8,9,...], а также были и различные подкасты [1,2,3] и вебинары!
4) Мой тренинг по безопасности Kubernetes все обновляется и расширяется и, кажется, такими темпами скоро перестанет укладываться в 3 дня =)
5) Есть определённые новые идеи/мысли запустить и попробовать что-то новое в следующем году как в виде форматов, так и по части различных активностей в образовательной деятельности. Главное, чтобы хватило на все времени и сил.


Всем большое спасибо, что читаете, комментируете, спрашиваете!

Всем хорошо встретить Новый Год, отдохнуть в праздники и не болеть!

Начнем год с забавной познавательной стать "Fun with SSRF - Turning the Kubernetes API Server into a port scanner" полезной как для атакующих, так и для защищающих.

Тут важно сразу понять, что все описанное в данной заметке это стандартная функциональность, а не какие-то уязвимости! Так все крутиться вокруг ресурса Validating Admission Webhooks (частью спецификации является service или URL). Помимо создания данного ресурса нужны будут права создавать еще и Namespace и Pod.

PoC сканера можно взять тут.

Сегодня я бы хотел привлечь ваше внимание к блоговой записи и репозитарию на канале одного моего товарища.

Сразу скажу, что речь в данной работе пойдет не про Kubernetes, а про Docker в чистом его проявлении в сочетании с OPA, а не как обычно принято на данном канале про OPA Gatekeeper =)

И так, моему товарищу понадобилось захерденить Docker executor и для этого нашелся Docker OPA Plugin, а вот правил проверок для него не нашлось, что в итоге и было реализовано!

P.S. Если тема интересная то в комментах можно подробнее расспросить автора об успешности работы все этого (Spoiler: не все так гладко как хотелось бы) ...

Компания Microsoft в очередной раз обновила свою Threat matrix for Kubernetes (по сути это уже 3 редакция)!

Помимо добавления новых техник (Static pods,Collecting data from pod) и расширения уже имеющихся (Container service account,Exposed sensitive interfaces) появилась и удобная интерактивная версия матрицы.

Еще появился и маппинг на техники MITRE ATT&CK, что удобно при использовании интерактивной матрицы.

А также, что более важно, появилась отдельная вкладка с Mitigations, которая на сегодняшний день включает в себя 32 пункта, каждый из которых привязан к той или иной тактике!