При проектирование своего Kubernetes кластера чрезвычайно важным его элементом является Container Runtime. При этом мало кто знает, что он, по сути, состоит из 2 частей: High-level Runtime и Low-level Runtime.

High-level Runtime (CRI Implementations):
• Dockershim
• CRI-O
• Containerd
• Frakti
• rktlet

Low-level Runtime (OCI Runtimes):
• runC
• runV
• Clear Containers
• kata-runtime
• gVisor


Изучая и сравнивая Docker и Containerd - можно лишний раз убедиться, что специализированное решение (Containerd) лучше, чем решение общего назначения. Для этого я сравнил security related информацию, выдаваемую командами crictl inspect <containerid> и docker inspect <containerid>. По мимо той же прямой связи с ресурсами Kubernetes есть и нформация по capabilities, seccomp настройкам работающего контейнера.

Отдельно советую посмотреть слайды "How Container Runtimes matter in Kubernetes?" про сравнение данных вещей в плане производительности и более новое исследование "Performance Evaluation of Container Runtime".

На днях от одного security вендора вышел отчет "2020 Cloud Native Threat Report: Evolution of Attacks in the Wild on Container Infrastructure". В отчете авторы рассматривают "attacks against cloud native environments".

Мой же взгляд что атакующие в первую очередь не cloud атакуют, а приложения, сервисы и они могут даже не знать где это все располагается. Облачные/контейнерные технологии как и любые технологии изменяют/расширяют attack surface (те самые misconfigured Docker API). И глупо было бы со стороны злоумышленников к своим сканам приложений на различные RCE, не добавить еще и этот крутой мисконфиг.

Отчет строится на основе результатов полученными с помощью honeypots. Honeypots очень классная штука. ТОЛЬКО в зависимости от того, как он "приготовлен", такие результаты и получаться! Глупо ожидать от honeypots с misconfigured Docker API, ловли RCE атак на Redis, Nginx, WordPress и другие приложения, что крутятся и смотрят в интернет в ваших сервисах.

К сожалению, авторы совсем не описали свою методологию тестирования ... Говорится что "In 100% of the attacks, the initial access was ‘Exploit Public-Facing Application’.", то что это за приложения непонятно. Скорее всего Honeypot это misconfigured Docker API и все.

По мне заголовок отчета не соответствует содержимому и более правильное название — это "Анализ вредоносных images".

P.S. В отчете нет ни одного упоминания Kubernetes/k8s. Хотя можно было бы в интернет вытащить и порты от его сервисов (etcd, dashboard и т.д.) и вообще много чего еще интересного ;)

Интересную заметку в своем блоке опубликовали исследователи из одной security-компании - "Falco Default Rule Bypass".

Обходы заключаются в логической ошибке в описании двух достаточно серьезных правил детектирования: "Launch Sensitive Mount Container" и "Launch Privileged Container". Из-за этой ошибки атакующий может создать такие images, что при их использовании система Falco ничего не увидит и промолчит.

За данным проектом я наблюдаю давно и для меня всегда оставалась загадкой его целевая аудитория?!

Если предполагается что предопределённые правила нужны новичкам, то в это не укладывается конфигурирование файла falco_rules.yaml (объем которого боле 1600 строк). Для его грамотной настройки явно порог входа не новичок. Тут нужно и Kubernetes понимать и то, как работают все ваши сервисы. Часть правил к вам вообще может быть не применима или применима не всегда и не везде в вашей инфраструктуре. А с учетом того, что сервисы меняются/развиваются, то и данный файл с правилами также надо своевременно редактировать. И как мы видим в блоге ни сами авторы инструмента, ни вы при редактировании правил не застрахованы от ошибок.

Если предполагается что предопределённые правила нужны большим и зрелым security командам, то большинство из его детектов можно закрыть другими механизмами, встроенными в сам Kubernetes. Например, Admission Control, PodSecurityPolicy, NetworkPolicy + Logging. Есть конечно и прецеденты, кто использует его, но тут надо иметь очень зрелый цикл разработки, слаженное взаимодействие между командами + приличную security team, что могут позволить себе далеко не все. Так как иначе это поддерживать в актуальном состоянии будет очень-очень тяжело.

Также Falco позиционирует себя как детектор аномального поведения и при этом базируется на человека созданных предопределенных правилах... При этом абсолютно естественно, когда, например, в одном image запуск процесса bash это аномально, а для другого это нормально. Так что это будет в итоге? Или на этот случай надо модифицировать правила для каждого image?

Замечательная заметка "Impact of CVE-2020-14386 on Kubernetes and Containers (Docker)" лишний раз не дает забыть о том, что безопасность хоста, на котором работает Kubernetes это также часть безопасность Kubernetes инфраструктуры.

Здесь речь идет о критической уязвимости ядра Linux - CVE-2020-14386, благодаря которой можно поднять свои привилегии до root'а или сделать побег из контейнера на Node, на которой он работает. Атакующий способен эксплотировать данную уязвимость, выполняя свой код внутри Pod'а с CAP_NET_RAW capability.

Естественно, это далеко не первая и не последняя уязвимость в ядре Linux которая позволяет делать "container escape". И все это никакими правилами и сигнатурами заранее не описать, не предусмотреть.

Что в таком случае делать для защиты?
1) Можно/нужно мониторить аномальную активность внутри ваших контейнеров. Так или иначе атакующему придётся для побега из контейнера делать то, что ранее в контейнере у вас не происходило. Это позволит вам ловить не только попытки "container escape", но и другу. Вредоносную активность внутри контейнера (Lateral Movement, запуск манейров и т.д.)
2) Можно присмотреться к защищенным/усиленным вариантам Low-level Runtime (OCI Runtimes) о которых говорили ранее. Но стоит учитывать, что они, как и любое ПО сами не застрахованы от уязвимостей, а просто сильно уменьшают и усложняют attack surface. Так GKE Sandbox использует для этого gVisor.

Уже давно хочу написать о докладе "Advanced Persistence Threats: The Future of Kubernetes Attacks" и чтобы на него обратило как можно больше не равнодушных к безопасности Kubernetes людей.

Сразу стоит отметить, что все продемонстрированные атаки в докладе предполагают, что атакующий так или иначе стал администратором кластера. А возможно это вообще недовольный кластер админ перед своим увольнением =)

Основная суть не в том, чтобы стать кластер админом, а закрепиться на кластере - получить Persistence. В общем, это краткое пособие о том, как могут оставить backdoor в вашем кластере.
Сценарии:
- Вредоносный validating webhook - во время валидации все что надо отправляется атакующему
- Shadow API Server - теневой kubeapi server с отключенной безопасностью лазит в etcd и забирает все что надо.
- C2BERNETES - С2 на базе k3s
- Вредоносное использование фич 1.19 для возрождения kubelet-exploit

Отдельно стоит отметить, что для всех сценариев авторы использовали легальное ПО - никакой малвари.

По мне эти сценарии далеки от идеальных и могут сработать если вы вообще не смотрите что у вас происходит в кластере. Но мне нравится сам полет фантазии авторов в этих техниках - на их базе можно придумать вещи куда по интереснее =)

Многие думаю не особо следят за CNCF Special Interest Group on Security, но в ней сейчас кипит работа над очень интересным документом "Cloud-Native Security Whitepaper" для CISO, CSO, CTO, Architects, целью которого является безопасность Cloud Native приложений. Как говорят сами авторы: "Our perspective for operators, what they should be thinking when considering cloud native security. How to inject security into the pipeline, not as an afterthought."

Документ находится еще в статусе WIP, так что его более детальный анализ проведем по его релизу. Но пробежавшись по нему могу сказать, что это очень достойный документ. Отличная работа SIG Security Group!

В своих постах я не раз отмечал чрезвычайную важность безопасности etcd. Если у атакующего есть туда доступ, то это GAME OVER.

На страницах документации etcd в разделе Operations guide есть секции "Role-based access control" и "Transport security model", на которых и строится базовая безопасность данного компонента Kubernetes кластера.

В первой секции говорится о работе с пользователями, ролями и аутентификацией, а во второй насчет транспортной безопасности на основе 4 примеров:
1: Client-to-server transport security with HTTPS
2: Client-to-server authentication with HTTPS client certificates
3: Transport security & client certificates in a cluster
4: Automatic self-signed transport security

Все больше компаний начинают переходить на Kubernetes (не важно внутренний или managed в облаке) или по крайней мере присматриваться к нему. Логично что в начале возникает вопрос: а с чего необходимо начать формирование его безопасности?

Перво-наперво необходимо, чтобы в интернет не смотрело то, чего туда смотреть не должно). Данные misconfigurations чрезвычайно просто и быстро находятся удаленными злоумышленниками со всего Мира с помощью сканирования портов буквально в течение нескольких минут после деплоя.

Далее идут всем хорошо известные встроенные механизмы безопасности Kubernetes. НО нужно помнить, что в каждой компании Kubernetes уникален почти как снежинка, от компании к компании разные подходы к разработке, культура/процессы работы/разработки, в конце концов разные продукты/сервисы и, конечно, же уровень зрелости в вопросах информационной безопасности.

Поэтому чужие success story о использовании того или иного инструмента или подхода могут быть совершенно не эффективны или не применимы для вас.

Инструменты/подходы должны не латать дыры, а выстраивать правильный процесс (не забываем, что безопасность — это не состояние, а процесс!) внутри компании. Так на пример использование самого крутого инструмента поиска/анализа инцидентов будет совершенно не эффективным, если команда безопасности будет утопать в этих же инцидентах, не успевая их разбирать.

Подход при котором для решение проблемы "A", возьмем решение "X", для решения проблемы "B" возьмем решение "Z" и т.д. далеко не всем по карману и в условиях быстро трансформирующегося современного бизнеса не эффективен на длинных дистанциях.

Поэтому выстраивайте процессы, а не состояния безопасности и перед тем, как что-то внедрять разбирайтесь в том что и как у вас работает/устроено внутри. Иначе внедрением почти любого security механизма можно очень легко что-то сломать … А знакомство с безопасностью должно быть приятным, а не отталкивающим =)

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

Не все сразу задумываются о важности для безопасности культуры использования tags для images и labels для k8s ресурсов.

Хотя именно благодаря ним с помощью различных selector'ов и других механизмов можно очень гибко применять управлять и контролировать вопросы безопасности. Те же NetworkPolicy, PodSecurityPolicy без этого не взлетят.

Чем раньше вы продумаете стратегию/систему использования tags для images и labels для k8s ресурсов, тем проще вам будет потом использовать различные security и не security инструменты и подходы в будущем. Поэтому уделите время на обсуждение данного вопроса с вашими разработчиками, DevOps специалистами и это сэкономит вам много времени в будущем.

P.S. Не используйте tag latest ;)

Разрабатывая систему защиты для контейнеров, часто сталкиваюсь с вопросами по prevention угроз в них. Исследуя данный вопрос, я выделили 3 типа prevention, которые можно сегодня встретить на рынке:

1) Системный - seccomp, AppArmor, SeLinux в режиме prevention. В общем неувядающая классика. Стабильно и быстро, но не просто.
2) Реакционный - по сути это не prevention, а реакция на угрозу. То есть если что-то случается в контейнере, что там не должно быть, то container runtim’у отправляется команда на выключение контейнера или установку его на паузу. В общем тут не настоящий prevention, а сила маркетинга.
3) Самописный - тот случай, когда prevention реализуется не силами встроенных в ОС механизмами, а собственными силами. На текущий момент все что доводилось видеть на рынке использует различные грязные трюки и хаки. По сути, там инъекции собственных библиотек в системные процессы или процессы приложений. Опасно, медленно, но гибко.

Если вы с разбегу захотите использовать 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 и т.д.