Если вы с разбегу захотите использовать PodSecurityPolicy, то вас ждет разочарование и придется начать с ряда приседаний:
1) Создать саму политику
2) Создать Role/ClusterRole, которая сможет использовать созданную вами политику
3) Создать RoleBinding/ClusterRoleBinding для связи роли с service accounts, users или groups
4) Включить PodSecurityPolicy admission controller

Последний пункт должен быть обязательно таким по очереди иначе вообще ни один Pod не сможет создаться в кластере!

Почему сделано так сложно мне лично непонятно... Использование той же NetworkPolicy куда проще, правда там реализация лежит на стороннем разработчике CNI плагина, а не на встроенном admission controller, как в случае с PodSecurityPolicy.

На выручку при создании PodSecurityPolicy может прийти лишь kube-psp-advisor, выполненный в виде Krew плагина. Он сгенерирует Role, RoleBinding и PodSecurityPolicy в едином YAML файле.

Постоянные читатели моего канала, которые со мной с самого начала, наверняка уже заметили что я достаточно негативно отношусь к таким вещам как предопределенные правила, сигнатуры, строгие чеклисты в виду их возникновения только лишь на знаниях о ТЕКУЩИХ возможностях атакующего. Все эти вещи ассоциируются у меня с предопределенностью, линейностью, некоторой неоспоримой, постоянной последовательностью. Но нет ничего более постоянного, чем временное. Особенно того что касается Agile разработки, развития микросервисов и подходов атакующих ;)

На эту мысль меня натолкнула еще несколько лет назад замечательная статья "The Dangers Of Linear Thinking and Why Security Analysts Should Defend in Graphs".

В статье в качестве примера приводится Incident Response активность, но это применимо и для построения безопасности в целом на мой взгляд это подходит. При построении системы безопасности также появляется подобный граф только разветвления там: А что мы защищаем? А что самое критичное? А какие модели нарушителей для нас актуальны в первую очередь? А как и где мы хотим обнаружить атакующего? А какой attack surface нужно закрыть в первую очередь? и т.д.

В виде списка это выглядит так: Для нашей инфраструктуры существуют такие требования, проблемы - начнем закрывать их по темам.

На пример, многие из тех же проверок CIS benchmark актуальны в основном для внутреннего атакующего, который уже проник на pod/контейнер. Хотя внешний атакующий еще должен стать этим внутренним атакующим. Поэтому слепое следование по списку, чеклистам, бенчмаркам, методикам может оставить более критичные вопросы без внимания.

Не думайте прямолинейно, а думайте в графах в соответствии с вашими приложениями, сервисами, инфраструктурой и бизнесом.

Еще одна очень важная политика на ряду с PodSecurityPolicy, NetworkPolicy в рамках Kubernetes это Audit policy. Логи аудита помогают ответить на вопросы: Что произошло? Кто сделал? Когда? Где?
Данная политика очень гибко конфигурируема можно задать: тип ресурса, за которым мы хотим наблюдать, namespace ресурса, типы операций, совершаемые над ресурсом, конкретные users и userGroups совершающие действия над этим ресурсом. И отдельно еще отмечу:

Уровень детализации:
• None
• Metadata
• Request
• RequestResponse

Стадии логирования:
• RequestReceived
• RequestStarted
• RequestComplete
• Panic

При этом на эту информацию можете подписываться как вы и потом обрабатывать, так и разные сторонние решения для осуществления своей работы. В дальнейшем более детальнее рассмотрим систему аудита в Kubernetes.

Многие каналы уже перепостили замечательную статью от команды Google Project Zero под названием "Enter the Vault: Authentication Issues in HashiCorp Vault" в которой рассказывается о двух [auth bypass в AWS iam integration и auth bypass в GCP iam integration] уязвимостях аутентификации в популярном решении для управления секретами для “cloud-native” приложений - HashiCorp Vault.

Я как человек, который уже долгое время занимается поиском и анализом уязвимостей в ПО, хотел бы тут отметить ряд вещей, на которые не все могли обратить внимание:
1) Cloud-native природа приложений неизменно увеличивает сложность приложения в моментах взаимодействия его частей. В данном случае задействовано аж 3 компонента: клиентская часть приложения, серверная часть приложения и облачный сервис.
2) Если вы используете Go, то это не значит, что никаких уязвимостей в вашем коде нет.
3) Найти такие уязвимости можно только при пентесте с анализом исходного кода. Никакие сканеры такое не найдут.

Также, при этом от этого исследователя совсем незамеченным осталась еще одна группа уязвимостей "Kubernetes: Multiple issues in aws-iam-authenticator", которая не вошла в данную статью.

В containerd была исправлена уязвимость, приводящая к утечки кредов при операции image pull. Закрытая уязвимость получила идентификатор CVE-2020-15157. Уровень критичности был оценен на Medium, CVSS score равный 6.1 и вектор CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N.

Для эксплотации данной уязвимости атакующему необходимо подготовить манифест образа в формате OCI Image или Docker Image V2 Schema 2 с URL, указывающим на местоположение внешнего слоя. В итоге, по умолчанию резолвер containerd пойдет по данном адресу и будет пытаться скачать данный образ. В некоторых случаях атакующий сможет узнать username и password для registry. А в определенный случаях так и вообще узнать креды от cloud virtual instan и тем самым получить доступ и к другим его ресурсам.

Множественные проблемы с утечкой secret данных при включенном подробном логировании

- CVE-2020-8563: Утечка VSphere Cloud кредов (из secret) через логи при logLevel >= 4
- CVE-2020-8564: Утечка pull secrets или других кред в docker конфиг файле через логи при loglevel >= 4
- CVE-2020-8565: Утечка Kubernetes authorization tokens (включая bearer tokens и basic auth) из-за неполного фикса CVE-2019-11250 через логи при logLevel >= 9
- CVE-2020-8566: Утечка Ceph RBD Admin secrets через логи при loglevel >= 4

Детальный обзор CVE-2020-8563 можно посмотреть тут.

Конечно, у атакующего должна быть возможность читать данный лог =)

Вчера для себя открыл два ресурса-сборника статей, инструментов на тему контейнеров, Kubernetes и облаков (Azure, Amazon Web Services, Google Cloud Platform):
1) Cloudberry Engineering - на данном ресурсе понравилась, что все статьи и инструменты протегированны и можно очень просто фильтровать по нужной теме.
2) CloudSecDocs - данный ресурс понравился тем, что все структурировано и представлено в сжатом, минималистичном виде - хорошо использовать как стартовую точку в изучении той или иной теме.

Насколько у авторов хватит сил, времени и желания все это поддерживать в актуальном состоянии покажет только время.

Подобных проектов категории "awesome-whatever" очень много: Awesome Kubernetes security [1,2,3,4], Awesome container security [1], Awesome Docker Security [1] и т.д.

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

Usernetes — это Kubernetes не требующий никаких root привилегий. Для реализации этого проект запускает Kubernetes и Container runtime без root'а, используя user_namespaces, mount_namespaces и network_namespaces. Также для реализации концепции rootless контейнеров для настройки сети он использует usermode сетевой стек (slirp4netns), файловую систему fuse-overlayfs и проект RootlessKit + практически не содержит SETUID/SETCAP исполняемых файлов.

Данный проект можно назвать скорее референсным для основной ветки Kubernetes и надеюсь когда-нибудь они встретиться и это будет в том или ином виде доступно в Kubernetes из коробки. Ну а пока это не так - помните, что атакующий выполняющий побег из контейнера почти автоматом получит root привилегии на хосте.

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

28-29 октября в online формате будет eBPF Summit 2020. Как можно понять из названия все мероприятие посвящено технологии eBPF. С каждым днем данная технология становится популярнее в инструментах и продуктах разного класса от отладки и наблюдений до сетевых стеков и безопасности. Очень большое значение эта технология играет для контейнерных инфраструктур (конечно, Kubernetes) - говорю это не понаслышке, а как один из разработчиков продукта для контейнерной безопасности, использующий eBPF. В программе много разных интересных докладов включая и безопасность. Мой основной интерес привлекли доклады из секции Lightning Talks, чем из основной программы, которые больше напоминают keynote доклады. Мероприятие бесплатное. Если интересно, как и куда будут развиваться контейнерные технологии, то данный контент очень рекомендуется к изучению.

Также 29 октябре в online формате на российской конференции мой хороший товарищ (соавтор некоторых сообщений на канале, человек, который уже не раз ломавший Kubernetes на проектах) выступит с докладом "Защита Kubernetes со всех сторон". Мероприятие бесплатное и докладчика можно помучить вопросами ;)

На этой неделе целенаправленно поговорим о сканирование образов (images) контейнеров, хотя уже не раз это обсуждали.

И так сканирование образа может проходить на 3-х стадиях:
- Build: во время сбора image в CI\DI пайплайне. То, что подается как ShiftLeft security подход.
- Deployment: во время деплоймента в Kubernetes кластер. Может быть частью validation admission процесса.
- Runtime: после того как image уже используется контейнером в Kubernetes кластере. Для реализации этого может быть использовано либо сканирование образов в вашем registry или сканирование непосредственно на worker nodes.


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

А да в основе всех коммерческих решений лежит тот или иной OpenSource движок для сканирования образов: Anchore, Clair, Trivy и т.д.

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

1) Высокий уровень шума - базовая проблема, которая как снежный ком тянет за собой все последующие пункты. Сканеры всегда что-то находят, даже в самых последних версиях образов ОС. При этом с точки зрения атакующего ~90-100% может быть вообще никогда не проэксплотировано, так как уязвимые функции из библиотек не используются.
2) Это не Shift left security - IMHO это эксплуатация хайпового подхода. Настоящий Shift left security в таком случае уже должен работать с исходным кодом в момент разработки сервиса, а не когда он уже написан. Для это есть другой класс инструментов.
3) Наличие False negatives - данные решения также могут и пропускать известные CVE в вашем коде по множеству причин: он качества их БД уязвимостей, до способа добавления стороннего кода разработчиками в проект (куски кода, статически слинкованные библиотеки и т.д.).
4) Только известные CVE (1day) - с точки зрения бизнеса не имеет роли как была скомпрометирована система и принесен ущерб. Инцидент должен быть обнаружен максимально быстро как в случае 1day, так и 0day атаки.
5) Strong Security Team - разгребать все это должна сильная команда безопасности, способная понимать, что для их сервиса актуально, а что нет, какие риски принять можно, а какие нет. Также хорошо бы иметь security champions внутри команд разработки.
6) Stop delpoy?! - очень красивая история, когда из-за критической уязвимости автоматически блокируют деплой. Но по факту, практически никто так не делает так как из-за простоя сервиса финансовые потери могут быть куда больше, чем он от непонятной уязвимости. Бизнес останавливать не будут.
7) Психология - разработчики и другие сотрудники, видя красные дашборды и успешно функционирующий сервис одновременно, постепенно будут терять мотивацию тщательно следить за этим моментом, ведь есть более важные бизнес фичи, приносящие прибыль.

Одно дело на демонстрации посмотреть дашборд сканера, где все красиво отображается, и совсем другое работать над улучшением данной картинки — это большая работа и мало кто это понимает.

Вещь нужная, но вы должны понимать эти моменты, когда соберетесь заниматься данным вопросом. Нужно адекватно расставлять приоритеты, оценивать силы и возможности своей команды.

Третья часть [1,2] по мыслям о сканирование образов (images) контейнеров.

Во второй части мы говорили о мифах, недостатках и проблемах инструментов данного класса. Сейчас рассмотрим, как же всё-таки можно улучшить данную картину. Основная проблема как мы уже выяснили это количество "шума", которое генерируют данные инструменты.

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

Лучше идти по пути уменьшения количества данного "шума". И в первую очередь это будет связано не с внедрением каких-то других решений по безопасности, а с культурой разработки продукта внутри вашей компании (это вам никто не продаст в виде готовой коробочки).

1) Культура ведения кода - отдельная большая область, которая покрывает темы от монорепов до использования сторонних библиотек во внутренних репозитариях (а не выдирать уязвимые куски кода и вставлять в свой проект). Общая цель которой это упростить автоматическим средствам анализа поиск недостатков.
2) Distroless images - убрать дистрибутив с кучей его бинарей, библиотек из image. Дает сразу море преимуществ - тут и размер образа уменьшается, и attack surface уменьшается, уменьшается и возможности атакующего, что попадет внутрь такого контейнера, так и "шум" уменьшается. Общая цель убрать, то, что не используется, чтобы уменьшить от них “шум”.
3) Оптимизированный порядок слоев в образе - слои в образе должны быть от более толстых, к более тонким (к часто обновляемым). Общая цель которой это упростить и ускорить автоматическим средствам анализа поиск недостатков.

Ну и на последок можно рассмотреть честный Shiftleft security подход - на пример, это умеют некоторые решения класса SCA (Software Composition Analysis).

Блогпост с детальным обзором CVE-2020-8566 про утечка Ceph RBD Admin secrets через логи при loglevel >= 4. Напомним, что недавно было обнаружено 4 уязвимости в Kubernetes примерно одной сути и содержания - утечки secret данных при включенном подробном логировании. У атакующего должна быть возможность читать данный лог.

Четвертая часть [1,2 ,3] по мыслям о сканирование образов (images) контейнеров.

Сегодня предлагаю посмотреть очень детальное и внушительное исследование от стороннего исследователя. Он написал серию статей по данной теме:
1) Testing docker CVE scanners. Part 1: false negatives and what they mean for your security
2) Testing Docker CVE Scanners. Part 2: How good is package detection?
3) Testing docker CVE scanners. Part 2.5 — Exploiting CVE scanners
4) Testing Docker CVE scanners. Part 3: Test it yourself / Conclusions

Для повторения экспериментов автор сделал доступным репозитарий со своими скриптами и данными.

Полностью согласен с выводами автора. Приятно видеть, что я не одинок в своих оценках и выводах.

Отличная заметка "When LIST is a Lie in Kubernetes", рассказывающая о том, что к содержимому ресурсов secrets можно получить и без GET, а только лишь с помощью LIST. При этом всем данная особенность работы в Kubernetes документирована: "For these reasons watch and list requests for secrets within a namespace are extremely powerful capabilities and should be avoided, since listing secrets allows the clients to inspect the values of all secrets that are in that namespace. The ability to watch and list all secrets in a cluster should be reserved for only the most privileged, system-level components."

Так что если вы хотите кому-то (аудиторам, сканерам или т.д.) ограничить доступ к secrets с помощью LIST, то этого не происходит.

Сегодня еще отдохнем немного от темы сканирования образов (думаю еще 1-2 поста и я закрою данную тему).

Сейчас мы поговорим о Static Pods.

Это Pods, которые управляются не через Kubernetes API server, а kubelet на самой Node. В основном это нужно для служебных задач кластера, на пример, бустрапа чего-либо. Подробнее о них можно почитать в документации. Для запуска таких подов достаточно расположение YAML файл с описанием Pod по определенному пути и указанием на него в `kubelet.

Но это также очень полезная штука и для атакующих (недобросовестных сотрудников и т.д.), которые проникли на Node тем или иным способом (вариантов и способов хватает). Просто authentication token от kubelet атакующему может не хватить - на пример, чтобы создать Pod в kube-system namespace. Что делать? Выход: пойти в обход Kubernetes API server, с помощью Static pod ;)

Пятая часть из цикла [1,2,3,4] сканирования образов.

Сегодня речь пойдет про создание минимального docker образа. Есть замечательная серия постов (+ код) на эту тему под названием "The Quest for Minimal Docker Images". Сам автор об этом пишет так: "We’re going to review a number of techniques to reduce image size, without sacrificing developers’ and ops’ convenience." С уменьшением размера выкидывается все (или почти все) ненужное и сканеры образов начинают меньше шуметь + маленький размер образов для хранения.

1) Первая часть про multi-stage сборку.
2) Вторая часть об особенностях работы с различными языками Go, Java, Node, Python, Ruby, Rust и о Alpine образе.
3) Третья часть покрывает различные паттерны и анти-паттерны при работе с ЯП, фреймворками. А также использование Bazel, Distroless, DockerSlim, UPX.

Маленький комментарий о статической линковке - перед ней сканеры образов просто слепы - не забывайте об этом.

В итоге если вы по тем или иным причинам не можете использовать Distroless подход, вы можете прийти к концепции golden-image (минимального, хорошо проверенного, эталонного и т.д.) для своих команд.

Red Kube или Red Team KubeCTL Cheat Sheet - набор kubectl команд (27 штук), полезных при пентесте/аудите, и две лабы, где их можно все попробовать. Отдельно стоит отметить, что все команды автор разбил на категории в соответствии с матрицей MITRE ATT&CK. Так что это все очень хорошо классифицировано (особенно для начинающих). Но важно не забывать, что чтобы данные команды успешно выполнились у атакующего должны быть соответствующие права в системе. На пример, через скомпрометированный token полученный тем или иным образом.
Так же по мне использовать в атаке приносной бинарь kubectl - очень заметно, даже если переименовав, тем самым сбив детект у части решений по безопасности. Лучше curl (он, кстати, требуется для части этих команд), но он еще должен находится в образе – иначе тоже его нужно будет нести с собой.

Среди возможных сертификатов по Kubernetes от The Linux Foundation пополнение - CKS (точнее должен появится вот-вот до KubeCon + CloudNativeCon North America Virtual). Таким образом будет доступно 3 сертификата

- Certified Kubernetes Application Developer (CKAD) - для разработчиков.
- Certified Kubernetes Administrator (CKA) - для администраторов.
- Certified Kubernetes Security Specialist (CKS) - для специалистов по безопасности.

Для получения последнего необходимо также иметь сертификат CKA.

Учебный план сертификации по темам:
1) Cluster Setup (10%)
2) Cluster Hardening (15%)
3) System Hardening (15%)
4) Minimize Microservice Vulnerabilities (20%)
5) Supply Chain Security (20%)
6) Monitoring, Logging, and Runtime Security (20%)

Кто-то уже даже под это сделал симулятор экзамена и продает.

Недавно наткнулся на репозитарий с правилами детектов для Elastic Security Solution (развитие или дополнение ElasticSearch). Среди правил, там есть правила для AWS, Azure, GCP в соответствии с матрицей ATT&CK. Честно говоря, про Kubernetes там нет ничего. И мое внимание это привлекло лишь потому, что можно провести параллели с Falco, который также работает на основе правил (правда которые вы же и должны предварительно адаптировать под себя).

В правилах от Elastic Security Solution мне очень понравилось и позабавило поле false_positives. Понравилось тем, что авторы вообще проработали этот момент и сделали для этого хорошее описание, а позабавило что это поле есть наверно у 99% всех правил. При этом эти правила в основном для детектирования каких-то инфраструктурных вещей, что на мой взгляд определенно имеет право на существование.

А вот второй момент по детектированию аномального поведения тут реализован отлично, от того, как это сделано в Falco (в нем надо собственноручно описать нормальную модель поведения и поддерживать ее). Здесь используется отдельная категория для таких вещей как ML - machine learning. Насколько это качественно работает сказать абсолютно невозможно и единственный механизм влияния тут это численное поле anomaly_threshold. Что говорит нам о использовании нейронных сетей. При разработке своего детектора аномального поведения приложений в Kubernetes, мы также проводили эксперименты с нейронными сетями и пришли к выводу что основная их проблема это не возможность объяснить на основании чего было принято то или иное решение оператору и в случае false positive необходимость полного переобучения сети. Так что, меняя значение anomaly_threshold остается просто ждать какой-то магии и конечный результат вы вряд ли поймете.