В своих постах я не раз отмечал чрезвычайную важность безопасности 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 и т.д.

Продолжаем обсуждение темы о сканирование образов (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 (минимального, хорошо проверенного, эталонного и т.д.) для своих команд.