Давненько ничего не было слышно про уязвимости в Kubernetes?!
Получите - распишитесь за целых 2 штуки!

CVE-2022-3162: Unauthorized read of Custom Resources
Уязвимость в kube-apiserver и имеет рейтинг Medium (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N).

Пользователь авторизованный на list или watch одного типа namespaced custom resource во всем кластере - может читать custom resources других типов из той же API group без авторизации. На пример, пользователь при list ресурса VirtualService на кластере из networking.istio.io, сможет читать и Gateway.

CVE-2022-3294: Node address isn't always verified when proxying
Уязвимость в kube-apiserver и имеет рейтинг Medium (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H).

Пользователь с возможностью манипуляций с Node и node/proxy, может через последний обратиться к Nodes из API server's private network. На пример, можно по обращаться к Control plane у облачного провайдера, хотя он не в вашем доступе.


Все поддерживаемые версии (1.22-1.25) получили патч, другие в пролете.

Компания Lyft опубликовала статью "Internet Egress Filtering of Services at Lyft", поделившись своим опытом об использовании Envoy как Explicit CONNECT и Transparent Proxy.

Как я думаю многие знают в Kubernetes нет ресурса Egress комплементарно дополняющего бы Ingress ресурс и с исходящим трафиком надо в итоге так или иначе мудрить (говорили об этом тут).

Тут как раз ребята рассказывают как они сделали Internet Gateway (IGW), принимая во внимание зашифрованный TLS трафик и возможность эксфильтрации данных через DNS c zero downtime.

В итоге, у них по умолчанию используется explicit proxy, а transparent proxy как запасной для библиотек, что не подчиняются explicit proxy.

Также там поднимаются такие вопросы как:
- Edge Internet Gateway vs Sidecar
- Rollout Strategy
- Developer Workflow
- HTTP Client Library Behaviors
- Next Steps: Private Subnets

Стали доступны записи докладов (287 штук - смотреть не пересмотреть) основной программы KubeCon + CloudNativeCon North America 2022! Как я писал ранее, до этого были доступны только доклады специализированных сессий. В основной программе как всегда очень много интересных докладов и, конечно, связанных с ИБ хватает.

Я для себя уже выделили следующие:
- "Running Isolated VirtualClusters With Kata & Cluster API"
- "Zero Trust Supply Chains with Project Sigstore and SPIFFE"
- "Using the EBPF Superpowers To Generate Kubernetes Security"
- "Kubernetes to Cloud Attack Vectors: Demos Inside"
- "Untrusted Execution: Attacking the Cloud Native Supply Chain"
- "The AdminNetworkPolicy API: A New Way for Cluster Admins To Enforce Security"
- "Multi-Tenancy: Tips, Tricks, Tools And Tests"
- "How the Argo Project Transitioned From Security Aware To Security First"
- "Securing the IaC Supply Chain"
- "Run As “Root”, Not Root: User Namespaces In K8s"
- "Armoring Cloud Native Workloads With LSM Superpowers"

Недавно узнав о policy-controller, я очень сильно проникся данным admission controller и решил поглубже копнуть про него. В итоге я нашел замечательный вебинар с названием "Sigstore Policy Controller (and creating your own policy)", где очень доходчиво рассказывают и о принципе работы и о там как писать собственные политики - ClusterImagePolicy. Помимо видео, в репозитарии авторов доступны и слайды и весь используемый код из live demo и используемые команды. В общем это отличная отправная точка для погружение в данный инструмент ;)

Хочу напомнить (кого-то познакомить) с двумя очень новыми и важными для безопасности Kubernetes фичами:
- KubeletInUserNamespace (Alpha 1.22)
- UserNamespacesStatelessPodsSupport (Alpha 1.25)

По тематике первой фичи рекомендую обратиться к ресурсу Rootless Containers, где данный вопрос очень подробно рассматривается. А по тематике второй фичи можно смело обратиться к исходникам Kubernetes, а именно к реализации userns_manager в kubelet. Все это в общем для тех кто хочет копать глубже чем просто установка параметров при запуске kubeapiserver ;)

Замечательная маленькая заметка "Modern containers don't use chroot" с обилием перекрестных ссылок на другие материалы (типа 1) по принципу работы современных контейнеров раскроет страшную тайну, что в контейнерах используется не chroot, а pivot_root. Как, зачем и почему уже в самой статье, но естественно это связано с security причинами ;)

Немного анонсов на ближайшее время, где я приму участие в конце этого года:
1) 23 ноября на ИБ Митап в Москве с докладом "Истории факапов ИБ при защите Kubernetes".
2) 24-25 ноября на HighLoad++ Msk 2022 с докладом "Сочетание несочетаемого в Kubernetes: удобство, производительность, безопасность", а также в первый день конференции я буду ведущим зала h2, который посвящён ИБ. На самой конференции меня будет легко идентифицировать по толстовке, что представлена в превью поста. Буду рад со всеми пообщаться!
3) 6 декабря в студии вместе с ребятами из VK Cloud мы пообщаемся на тему DevSecOps. Детали о самом мероприятии тут.

Ну и думаю хватит публичных активностей на этот год =)

P.S. До 1 декабря открыто CFP на DevOpsConf 2023 - успейте подать заявку. Если есть какие-то сомнения, то можно писать мне - помогу с подачей, особенно если это касается Kubernetes и его безопасности!

Экосистема Sigstore на одной картинке. Подпись ресурсов и ее верификация это новый большой тренд в облачной индустрии. И, конечно, чтобы идти в ногу со временем нужно в нем ориентироваться. Вот такая картинка от OpenSSF Landscape может в этом помочь.

Поговорим сегодня о криптомайнерах в контейнерах. Тема, которую очень часто любят поднимать security вендоры под соусом необходимости backup'ов или обнаружению по Indicators of Compromise (IoC).

Поэтому наткнувшись на статью "Detecting Cryptomining Attacks “in the Wild”" у меня сразу был некий скептицизм ... А после ее прочтения если не усилился, то по крайней мере остался на том же уровне. Шел конец 2022 года, а они все мучают бедный xmrig, как будто на нем свет клином сошелся. Весь расчет обнаружения у авторов на "average attacker or insider threat would use a popular ...".

Хорошо, что честно в статье написано: "Note that each individual measure has its own limitations. Combining them improves the efficiency of detection for sure. However, there are still some more advanced cryptomining techniques and attacks, such as the one that attacked Tesla." Тоесть реальный кейс с Tesla бы это все равно не решило/поймало ...

Похвалю раздел "Evasion techniques to avoid cryptomining detection" - в превью поста.

Сегодня в прицелах нашего внимания доклад "RCE-as-a-Service: Lessons Learned from 5 Years of Real-World CI/CD Pipeline Compromise" (слайды, видео) с известнейшей конференции BlackHat USA 2022.

В рамках доклада авторы демонстрируют множество сценариев как через CI/CD Pipeline можно с легкостью атаковать другую часть инфраструктуры (Kubernetes в том числе)! И, конечно, без внимания не остаются и способы защиты, которые могут помочь это предотвратить.

P.S. Ближайшие 2 дня буду рад увидеться и пообщаться со всеми на HighLoad!

Мой хороший товарищ Сергей Солдатов опубликовал замечательную вещь - 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
- Descriptors
- 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
- Description
- 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 для исправления этого, но ментейнеры пока не особо спешат это менять.