Kubernetes продолжает развиваться и расширятся. Так концепция Ingress постепенно эволюционирует в Gateway API (Alpha стадия). Данной теме и посвящена последняя запись в официальном блоге.

Если оставить за скобками введение для этого новых типов ресурсов (HTTP/TCP/UDP/TLSRoute, BackendPolicy, Gateway, GatewayClass), возможности по манипуляции HTTP заголовками, возможности по пропорциональному управлению трафиком и вообще расширяемости в независимости от используемо Gateway провайдера (реализаций Gateway controller множество, как и для Ingress). То с точки зрения управления и безопасности в глаза бросается старание авторов реализовать в данной концепции Role-oriented design.

Это предполагает удобное разделение ответственности между разными членами команды или департаментами в вопросах маршрутизации и взаимодействия Kubernetes сервисов. По сути, это должно дать возможность безопасно, совместно управлять маршрутизацией несколькими командами, даже в условиях multi-tenant инфраструктур.

Реализация NetworkPolicy лежит на плечах разработчиков CNI. У разных CNI своя реализация, что приводит к различиям и, конечно, ошибкам. Kubernetes сообществу же хотелось, чтобы это везде работало одинаково - давало один результат в независимости от реализации.

Для этого было разработано 2 инструмента для тестирования сетевых политик в различных CNI:
1) e2e framework
2) Cyclonus

За время тестов ошибки уже были найдены в OVN Kubernetes,Antrea, Calico, Cilium.

Помимо этого, SIG Network сейчас работает над следующими нововведениями в NetworkPolicy:
- Поддержка диапазона портов [в v1.21 alpha]
- Автоматический лейблинг для namespace [в v1.21 beta] (необходимо и удобно для меж namespace политик)
- Поддержка Fully Qualified Domain Names(FQDNs) в политиках - есть прототип от Google и его можно уже попробовать как CRD FQDNNetworkPolicies.
- Поддержка политик для всего кластера

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

В Kubernetes самой маленькой вычислительной единицей, которую он создает и управляет, является Pod (отдельной сущностью еще выделяют StaticPod). Но практически никто и никогда Pod'ы сами по себе не создает, а используют вышестоящие ресурсы/контроллеры - хорошо всем известные стандартные: Deployment, ReplicaSet, ReplicationController,StatefulSet, DaemonSet, CronJob и Job. И правильно настраивать PodSecurityContext внутри них, чтобы в дальнейшем Pod это все унаследовал.

Но время идет, подходы к разработке, выкатке приложений начинают выдвигать новые требования к работе и возможностей данных контроллеров становится недостаточно. На пример, для удобных canary или blue-green развертываний. Тем самым сторонние проекты разрабатывают новые контроллеры, которые такое начинают поддерживать. На пример, Rollout из Argo Rollout или Workflow из Argo Workflow. И вот в таких новых ресурсах также стоит не забывать о PodSecurityContext (если, конечно, сами авторы не забыли это учесть в своей реализации) - вот пример из одной документации.

В комментариях хотелось бы собрать какие вы знаете проекты и их ресурсы, которые способны создать и управлять Pod'ами. А так я уверен, что со временем такого будет появляться все больше и больше.

Как-то это прошло мимо меня, но 2 месяца назад в Istio закрыли забавную, но при этом классическую уязвимость для подобных механизмов (Подобное можно было видеть и в случаях с saml/oauth.), в проверке JWT токена. Суть: "If a JWT token is presented with an issuer that does not match the issuer field specified in JwtProvider, then the request is mistakenly accepted". Подвержена была версия 1.17, а более младшие версии нет (1.16 и младше). Уязвимость получила идентификатор CVE-2021-21378 и высокий CVSS рейтинг 8.2 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N.

P.S. Не очень понятно почему авторы во всех переписках это публикуют как "fix for zero day"... Может они видели использование данной уязвимости в реальном мире ?!

Сегодня с 10:00 CEST стартует KubeCon + CloudNativeCon Europe 2021 и продлится до 7 мая включительно. Полное расписание можно посмотреть тут.

А завтра будет специальная секция Cloud Native Security Day от CNCF - программу этой секции можно посмотреть тут. Там, как всегда, много всего интересного (будет даже CTF), но этого не значит, что в остальные дни на конференции нет докладов затрагивающий тему безопасности.

По данным анализа прошлой конференции - тема security одна из самых популярных и обсуждаемых - думаю, что и в этом году эта тенденция останется.

Совсем недавно компания Google на одной из страниц своей официальной документации опубликовала/обновила раздел "Compare AWS and Azure services to Google Cloud". То есть она сопоставила свои облачные сервисы с сервисами своих основных конкурентов. Это может быть полезно как при выборе облачного провайдера, так и при миграции из одного в другой или при создании Multi-cloud.
Отдельно стоит обратить внимание (применить фильтр) на следующие моменты:
- "No equivalent alternative" - так как таблица строится от сервисов Google, то это свойственно только конкурентам. Так что у конкурентов тоже могут быть сервисы, которым нет альтернативы в Google.
- "Security" - быстро посмотреть, что позиционируется как механизм безопасности
- "Kubernetes" - быстро посмотреть, что на прямую связывают с k8s

До этого я встречал только вот такое сравнение "Mapping of On-Premises Security Controls vs. Major Cloud Providers Services" (не со всеми пунктами я там согласен) для решений ON-PREMISES, AWS, AZURE, GOOGLE, ORACLE, IBM и ALIBABA.

Определенно было бы здорово иметь подобное сопоставление/сравнение и с участием российских облачных провайдеров.

https://doc.crds.dev/ - очень удобный online сервис по работе с CRD (Custom Resource Definition). Он очень прост и полезен в использовании - достаточно вбить только github адрес проекта, CRD которого вас интересуют. А далее проект самостоятельно выделит версии проекта и для каждой из них имеющийся там набор CRD с описанием. По сути, это такая автоматическая генерилка документации на CRD сторонних проектов.

Это очень может быть полезно при знакомстве, разбирательстве с чужим проектом, оператором и т.д. до его непосредственной установки. В одном из своих прошлых постов я уже писал о проблеме, которую они привносят и потенциально могут понизить уровень безопасности и сыграть на руку атакующему. А благодаря данному проекта можно очень просто, удобно и быстро ознакомиться с внутренностями любых CRD на просторах github.

ELF внутри YAML ресурса Pod или x86 assembler внутри ConfigMap ?) Вот такие кейсы [1,2] можно найти на просторах сети... И при этом это также может использовать атакующий, но уже не в ваших интересах.

Вот и прошел KubeCon + CloudNativeCon Europe 2021 - на нем было много интересного и полезного. Мы обязательно отдельно рассмотрим доклады, что затрагивали тему security, а их было прям предостаточно. Но уже сейчас большинство слайдов докладов доступно на сайте, внутри расписания: основная программа и Cloud Native Security Day.

Сегодня речь пойдет об атаке Terminal escape injection в сервисе AWS CloudShell, обнаруженной командой Google Project Zero в феврале 2021 года.
Суть уязвимости в возможности RCE, из-за ошибки компонента библиотеки aceterm, приводящей к некорректной обработке последовательности символов xterm rewrite терминала javanoscript, при использовании AWS CloudShell. Это может привести к возможности удаленного выполнения кода на EC2 серверах, доступ к которым осуществлялся с помощью консоли CloudShell.

Сервис AWS CloudShell предоставляет возможность доступа к терминалу сервера любых сервисов на AWS c помощью браузера, прямо из веб интерфейса консоли управления AWS.

Поскольку AWS CloudShell имеет полный доступ к учетным данным, используемым для входа в веб интерфейс консоли управления AWS,
успешная эксплуатация данной уязвимости могла бы дать злоумышленнику очень мощную точку входа в инфраструктуру AWS, включая сервисы managed k8s: EKS, ESC. Уязвимость была опубликована в рамках сроков responsible disclosure и в настоящее время устранена.

PS: Примечательно, что 2 года назад такой же баг, приводящий к RCE (CVE-2019-0542) был найден в аналогичном сервисе Azure Cloud Shell/VSCode.

Сегодня открою "страшную" тайну хорошо известную в "узких" кругах о Falco - он легко обходится и трудно настраивается. Но обо всем по порядку:
1) Если вы используете Falco, то срочно обновитесь до последней версии 0.28.1
2) В данной версии закрыли несколько Security Advisories уровня critical и high
3) Сritical позволяла незаметно уронить модуль и отключить Falco
4) High говорит о множественных обходах default правил из falco_rules.yaml (закрыто не все)
5) Об этом всем известно в открытом доступе уже 17 месяцев
6) Все это доступно вместе с PoC из стороннего публичного аудита безопасности опубликованного в репозитории Falco

Также аудиторы отмечают сложность написания хороших правил, а разработчики отмечают необходимость кастомизации default правил во избежание обходов.

Запомните: Правила, созданные человеком, хороши ровно на столько на сколько хорошо их автор знает систему в конкретный момент создания правила. А ОС Linux совсем не простая ОС + ваши микросервисы развиваются ...

Во время последнего KubeCon + CloudNativeCon Europe 2021 была опубликована первая версия Cloud Native Glossary. Если вы или ваши коллеги только начинаете свой путь в Cloud Native мир, то это будет хорошей отправной точкой, чтобы получить общее представление о базовых терминах и определениях.

В первой версии 25 терминов (список будет расширяться) в 3-х категориях:
1) technology
2) property
3) concept

При описании каждой technology объясняют, что это такое, зачем это надо и как помогает. От сюда вы узнаете и что такое Kubernetes и что такое DevOps c DevSecOps и многое другое ;)

Компания Amazon опубликовала серию постов "Policy-based countermeasures for Kubernetes" [1,2].
По сути, это свежий (от 31 марта 2021) обзор и сравнение policy engines, который поможет вам выбрать наиболее подходящий для вашей компании. Среди рассматриваемых кандидатов:
- OPA
- Gatekeeper
- MagTape
- Kyverno
- k-rail

К сожалению, на момент публикации Kubewarden еще не был выпущен, и он тут не рассматривается.

Все решения описываются по следующим пунктам:
1) Создание политик
2) Реакция на недоступность webhook (fail open vs. fail closed)
3) Возможность фонового сканирования
4) Расширяемость кода и данных
5) Архитектура и развитие используемых политик
6) Возможность работы вне Kubernetes кластера (встраивание в CI\CD)

Материал просто MUST READ, а policy engine уже должен быть неотъемлемой частью вашего Kubernetes кластера!

Если вы планировали провести эти выходные с пользой, то как раз для вас CNCF выложил записи докладов с недавно прошедших своих сессий:
- KubeCon + CloudNativeCon Europe 2021
- ServiceMeshCon EU 2021
- Kubernetes on Edge Day EU 2021
- Crossplane Community Day EU 2021
- Cloud Native Security Day EU 2021
- Kubernetes AI Day EU 2021
- Cloud Native Wasm Day EU 2021
- FluentCon: Cloud Native Logging Day with Fluent Bit and Fluentd EU 2021
- Cloud Native Rust Day EU 2021
- PromCon Online EU 2021
- Magma Day EU 2021


Обратите внимание, что доклады на тему security были не только на Cloud Native Security Day, но и в основной программе, и в других сессиях ;)

От версии к версии Kubernetes приобретает все новые и новые возможности для повышения уровня безопасности.

Так в версии 1.22 в alpha стадии будет добавлен "KEP-2413: Enable seccomp by default". Данный KEP позволит, через feature gate под именем SeccompDefault для kubelet, запускать все рабочие нагрузки (`workloads`) c seccomp профилем по умолчанию, который будет разрешать только определенный набор системных вызовов. На текущий момент никаких ограничений НЕТ, если вы, конечно, не создали и назначили seccomp профиль вручную. По сути, это сузит для атакующих перечень системных вызовов через, которые они могли бы сделать побег из контейнера через уязвимости ядра хостовой ОС.

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

Кстати, по такому белому списку можно будет проще отслеживать какие уязвимости ядра для вас критичны в плане возможности побега из контейнера, а сейчас по факту любая CVE связанная с поднятием привилегий.

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

И он подсветил для меня один очень интересный момент, о котором лично я никогда не задумывался, не рассматривал и сейчас хотел бы поделится им с вами. Общий смысл его посыла был примерно следующий: "Мало обновить весь софт до актуальных версий, также необходимо убедиться, что закрытые уязвимости не были проэксплотированы до их закрытия". И все очень логично, если подумать - патчи нас защищают от будущих атак на эти 1-day уязвимости, но совершенно ничего не говорят о прошлом этих уязвимостей в нашей инфраструктуре, когда они для нас, по сути, были 0-day. То есть инцидент уже был, но мы о нем просто не знаем ...

Никто не застрахован от того, что кто-то раньше разработчика нашел эту уязвимость и использует ее в злонамеренных целях, никто не может мгновенно обновить весь код в продуктивном окружение - всегда есть окно между выходом патча (информация становится известна широкой публике) и непосредственным обновлением и все это время вы под большой угрозой. А с учетом того, что сейчас в разработке используется огромное количество open source кода из публичных репозитариев, то плохим парням достаточно внимательно следить за тикетами, фиксами в этих проектах. На моей памяти так уже делают, на пример, следя за изменениями в кодовой базе Chromium.

Для тех кто хочет поглубже разобраться в теме, посмотреть на нее с разных сторон советую ознакомится с документом "ENCOURAGING VULNERABILITY TREATMENT: Responsible management, handling and disclosure of vulnerabilities".

И напоследок вопрос: многие ли из нас помимо обновления ПО, убеждаются в том, что инцидента до этого не было?)

Поговорим о kube2iam - инструменте для настройки конфигурации IAM roles кластера k8s, запущенного в облачной инфраструктуре AWS. Часто бывает, что внутри кластера разрешено взаимодействие через IMDSv1 (о котором мы уже писали). Относительно k8s конфигурация доступа контейнеров/pod's напрямую к сервисам IMDS приведет угрозам безопасности, в случае успешной компрометации одного из контейнеров злоумышленник может обратиться к IMDS для получения значений temporary credentials для дальнейшего продвижения.
kube2iam предлагает решение для проксирования трафика IMDS всех контейнеров/pod's в составе k8s на основе arn, при настройке IAM roles кластера на AWS, которое может быть запущенно как kube2iam daemonset на каждой ноде кластера.
За проксирование API IMDS отвечает iptables --to-destination curl 169.254.169.254/latest/meta-data/local-ipv4:8181
Внимательный читатель может заметить ряд пересечений по функциональности с GKE Workload identity, только это утилита с открытым исходным кодом.

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

Предварительно хотелось отметить несколько моментов:
1) У моего знакомого NDA и то, что они используют в компании, полностью рассказать не может
2) У них в компании очень высокий уровень зрелости в вопросах безопасности (Blue/Red/Purple team, обучение сотрудников и т.д.) - комплексный подход

Так что далее будет мое понимание и догадки на основе общения с ним по данному вопросу:
1) 0day это обыденная вещь в их модели угроз и рисков
2) Не делают отличий между 0day и 1day уязвимостями - то и то приносит одинаковый ущерб бизнесу
3) Используют deception подход - для поимки атакующего на какой-либо из стадии kill chain (достаточно 1 ошибки злоумышленника)
4) Смотрят за аномальными событиями в инфраструктуре - взаимодействие с SRE командой, ретроспективный анализ и т.д.
5) Threat hunting - делают постоянно и с появлением информации о патчах, PoC обогащают контекст и за чем-то могут посмотреть внимательнее

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

CVE-2021-30465: runc are vulnerable to a symlink exchange attack

CVSS Score: 7.6 High
CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N

В описании уязвимости (как по мне) вы увидите более запутанное название "mount destinations can be swapped via symlink-exchange to cause mounts outside the rootfs", за которым скрывается time-of-check-to-time-of-use (TOCTTOU) проблема и специфика работы с symlink.

При успешной эксплуатации уязвимости атакующий получит container escape. При этом если даже на системе используются LSMs (AppArmor/SELinux) и user namespaces, то они никак не остановят эксплотацию, а лишь помогут минимизировать возможный ущерб.

В первую очередь это критично для тех инфраструктур, где недоверенные пользователи могут запускать собственные контейнеры. Так как для успешной эксплотации атакующий должен контролировать конфигурацию volumes и иметь возможность выполнить свой вредоносный код внутри этого контейнера. Как мы знаем Kubernetes дает возможность при описании workload такое сконфигурировать - точки монтирования из хоста в контейнер. И в k8s данную уязвимость уже воспроизвели! При этом внешне данная конфигурация подозрительной не является, сигнатурами/правилами не описать. Это не как прямое монтирование / внутрь контейнера, но эффект тот же ;)

Чисто мое IMHO - некоторые априорные знания о системе и/или немного перебора могут позволить это провернуть и в контейнерах, которые созданы/подготовлены не злоумышленником, но имеют точки монтирования, и где у злоумышленника есть RCE - но это еще нужно проверить...

В runc уязвимость исправили в версии 1.0.0-rc95, а в containerd, который его использует, в версиях 1.4.6 и 1.5.2.