Мой хороший товарищ Сергей Солдатов опубликовал замечательную вещь - mindmap для Major Risks for Core Components of Container Technologies (NIST SP 800-190) !

Там отдельными разделами идут:
- Host OS Risks
- Container Risks
- Registry Risks
- Orchestrator Risks
- Image Risks

Очередная крутая статья "Digging into the OCI Image Specification" от авторов "Digging Into Runtimes – run", опять глубоко про основы, и на этот раз про OCI спецификацию образов.

Из статьи вы на теории и на практике познакомитесь с:
- Limitations of the Runtime Specification (runtime-spec)
- Image Format Specification (image-spec)
- Image Manifest
- Image Index
- Image Layout
- Image Configuration
- Conversion
- Denoscriptors
- File System Layer

MUST READ для всех кто работает с контейнерами и хочет понимать, что такое контейнеризация на самом деле.

CD Foundation в своем блоге опубликовал заметку "Policy in Continuous Delivery". В данной заметке рассматривается как важность проверки в процессе CD, так и различные примеры. При этом на текущей момент в Continuous Delivery Landscape в данной категории ("Policy") представлено 3 инструмента:
- Allero
- Kyverno
- Open Policy Agent

Важно проверять как CI/CD pipeline manifests, так и ресурcы с которыми идет работа.

В контексте Kubernetes, очередной раз отмечу два момента:
1) Kyverno и OPA могут использоваться на более ранней стадии - в CD
2) Пункт 1 не отменяет использования их как Admission Controller (класс Policy Engines), который является последним бастионом защиты и способен противостоять тем моделям нарушителя, что не обрабатываются в пункте 1

Поздравляю всех причастных с Международным днем защиты информации (Computer Security Day)! А так как мы живем с вами в DevSecOps эру и в процессе обеспечения информационной безопасности задействованы можно сказать все департаменты от Dev и QA до Ops и Platform team, то смело всех причастных к разработке ПО и сервисов ;)

Помните как о безопасности используемых компонентов, так и о среде разработки с окружением (Kubernetes, runtime), где в конечном итоге работает ваш код!

В официальном блоге Kubernetes вышла заметка "registry.k8s.io: faster, cheaper and Generally Available (GA)" и посвящена она переезду image registry c k8s.gcr.io на registry.k8s.io для образов Kubernetes начиная с версии 1.25. Все это было сделано для повышения надежности при запросе образов и увеличения скорости их скачивания.

Так что проверьте свои хардкоды! На пример, в скриптах, где вы проверяете подписи и SBOM для образов Kubernetes. Типа вот таких вот.

Классная блоговая запись с говорящим названием "Attacker persistence in Kubernetes using the TokenRequest API: Overview, detection, and prevention".

С Kubernetes 1.24 появилось TokenRequest API, позволяющее пользователю очень просто создавать JSON Web Token (JWTs) для аутентификации в Kubernetes API.

И как вы уже, наверное, догадались, злоумышленник с помощью этого API может творить не хорошие вещи, типа - долгоживущих, тяжело детектируемых, высоко привилегированных доступов в кластер. Об этом и данная статья со способами обнаружения этого всего.

Материал будет полезен как пентестерам, так и специалистам SOC.

Еще в студенческие годы мое внимание было захвачено такими механизмами безопасности Linux как AppArmor, seccomp и в меньшей степени на SeLinux, но на практике в проектах встречать их, к сожалению, практически не приходилось.

И приятно, что данные механизмы можно сказать обретают вторую жизнь в контейнеризации, в системе Kubernetes!

В недавней заметке "Finding suspicious syscalls with the seccomp notifier" рассказывается об адаптации seccomp к реальным условиям, что его можно было проще и удобнее использовать в реальных окружениях.
Из заметки вы узнаете:
- Новые возможности Security Profiles Operator
- Новой фичи seccomp notifier - действие SCMP_ACT_NOTIFY (появилась в ядре 5.9, также требует поддержку и на стороне Container runtime)

Таким образом использование seccomp становится куда удобнее – можно узнавать что там пошло не так в контейнере стандартами средствами!

На свет появился OWASP Top 10 CI/CD Security Risks вслед за OWASP Kubernetes Top 10, который мы рассматривали тут.

Я думаю это более чем описывает текущие тренды.

Каждый риск рассматривается по следующей структуре:
- Definition
- Denoscription
- Impact
- Recommendations
- References

P.S. По качеству и наполнению выполнено лучше чем для Kubernetes.

Напоминаю, что сегодня 6 декабря в 17:00 (МСК) на площадке VK Cloud поговорим с коллегами про DevSecOps.

В программе:
- DevSecOps — это больше про инструменты или все же про процессы?
- Реально ли автоматизировать процессы безопасности в больших проектах, где зависимости меняются каждый день?
- Можно ли воспроизвести паттерны DevSecOps с доступными на текущий момент инструментами?
- Где в компании место DevSecOps-специалиста и какие у него должны быть ресурсы?
- Как запланировать работу, которая зависит от множества факторов — например, доступности приложений или работы с другими департаментами?
- Q&A-сессия в конце вебинара.

Регистрация: https://vk.company/ru/press/events/953/

"Forensic container checkpointing in Kubernetes" - еще одна замечательная блоговая запись о новой фичи Kubernetes в официальном блоге. О данной фичи мы уже писали [1,2,3], но на всякий случай напомню, что она:
- Базируется на Checkpoint/Restore In Userspace (CRIU)
- Появилась в alpha статусе в Kubernetes v1.25
- Требуется включение ContainerCheckpoint gate на API server
- Требуется поддержка на стороне Container Runtime (В CRI-O уже есть, в containerd еще обсуждается)
- Для создания checkpoint требуется обращение к kubelet c Node
- Цепочка вызовов kubelet -> High-level runtime - > Low-level runtime - > criu
- Результат работы сохраняется в /var/lib/kubelet/checkpoints/checkpoint-<pod-name>_<namespace-name>-<container-name>-<timestamp>.tar
- Полученный Checkpoint можно восстановить как в Kubernetes, так и за его пределами


Возможность очень интересная и полезная, но еще очень сырая ...

Мне очень нравится концепция 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-noscript: 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", где можно обо всем узнать еще более подробно о данной фиче, на основании различных примеров.