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

Для это есть отличная статья "What happens when ... Kubernetes edition!" (перевод). В ней рассматривается весь жизненный цикл от команды с kubectl до старта контейнера в Pod`е сквозь `kube-apiserver, etcd, различные controllers, kubelet, CRI, CNI и т.д.

С точки зрения безопасности тут поднимаются моменты связанные с:
- клиентской аутентификацией
- процессом авторизации
- назначением и работой admission controllers

Если вам не терпится сразу что-то вводить и пытаться поломать Kubernetes, то в достаточно популярном GitHub проекте PayloadsAllTheThings есть раздел и по Kubernetes. Там собраны самые базовые команды, ресурсы, что могут пригодиться при пентесте Kubernetes.

В открытом доступе появился PoC эксплоит для CVE-2020-10749 для проведения Kubernetes MitM атаки через отправку специального ICMPv6 Router Advertisement (RA) сообщения. О деталях данной проблемы я писал ранее.

Kubernetes Goat - это специально заготовленный Kubernetes кластер с классическими уязвимостями, слабостями и проблемами для обучающих целей. Серия Goat достаточно популярно в security сообществе - есть и web-приложения, mobile-приложения и т.д. И вот очередь дошла и до Kubernetes.

На текущий момент Kubernetes Goat содержит 11 уязвимых сценариев и 3 для знакомства с инструментами Docker CIS Benchmarks, Kubernetes CIS Benchmarks и Hacker Container. Видно, что проект новый и сценариев мало и они не блещут хорошим разнообразием. Но для самого старта сойдет. Уязвимые сценарии:
- Sensitive keys in code bases
- DIND(docker-in-docker) exploitation
- SSRF in K8S world
- Container escape to access host system
- Attacking private registry
- NodePort exposed services
- Helm v2 tiller to PwN the cluster
- Analysing crypto miner container
- Kubernetes Namespaces bypass
- Gaining environment information
- DoS the memory/cpu resources

29 июня состоится однодневная, виртуальная, бесплатная конференция `fwd:cloudsec`. Данная конференция специализируется на докладах про безопасность AWS, GCP, Azure и, конечно, Kubernetes.

При запуске kube-controller-manager убедитесь, что используется ключ --use-service-account-credentials. Он говорит о том, что будут использоваться специализированные service account credentials для каждого контроллера. Иначе все контроллеры будут запущены от service account, принадлежащему `kube-controller-manager` и включающему все права для всех контроллеров. В итоге это, при компрометации service account на каком-либо из контроллеров атакующий получит чрезвычайно мощный service account. Используйте --use-service-account-credentials, чтобы минимизировать возможные последствия при компрометации какого-либо контроллера.

Очень интересная статья/исследование на тему, которую мы уже тут поднимали, - сканирование образов контейнеров на известные уязвимости (1-day). Для этого автор взял 3 open-source сканера и натравил их на 4 базовых образа ОС с DockerHub.

Краткие выводы:
- Все сканеры дали разные результаты как по количеству, так и по уровню критичности
- Все сканеры поддерживают разные наборы базовых изображений
- Даже в полностью обновленном базовом образе все еще могут быть известные CVE

Kubernetes опубликовал "Pod Security Standards", где подробно объясняет какие настройки, когда, где и как использовать в Pod Security Policy. Для этого они все политики разделили на 3 типа:
- Privileged - неограниченная политика, предоставляющая большую свободу, позволяет проводить хорошо известные поднятия привилегий.
- Baseline/Default - минимально закручиваем гайки чтобы предотвратить хорошо известные поднятия привилегий.
- Restricted - максимально закручиваем гайки.

Конференция fwd:cloudsec 2020, о которой мы писали недавно, сейчас в прямом эфире!

Все больше сталкиваюсь с темой расследования инцидентов в облачной, контейнерной инфраструктуре. И несомненно окружение оказывает сильное влияние на данные процесс. Pod’s с контейнерами внутри живут не так долго как классические приложения, они много обновляются, скейлятся как в одну так и другую сторону и т.д. Ограниченный, достаточно малый промежуток времени жизни контейнера вводит расследование инцидентов в чрезвычайно жесткие рамки с одной стороны. А с другой стороны, подпирают ресурсы не позволяющие просто так висеть контейнерам, кушать место и ждать, когда кто-то из ИБ специалистов обратит на них внимание.
В итоге получаем, что скорость разработки, развертки, сопровождения приложения накладывают такие же требования по скорости и на стадии безопасности. Они должны друг другу соответствовать.
IMHO, выходом из ситуации является своевременное уведомление и обработка инцидентов по данным от RunTime решений, без перекладывания в долгий ящик.

Безопасность etcd это критически важный элемент безопасности Kubernetes. Доступ к etcd равноценен root правам на кластере!

Там хранится вся критичная информация. Все в Kubernets это YAML и весь YAML хранится там)

Обязательно нужно настроить и контролировать 2 основных аспекта работы etcd:
1) Жестко ограничить список клиентов, которые с ним могут взаимодействовать. В идеале должен быть только API сервер. Естественно, никакого доступ из общей сети компании или из сети интернет! Тут на помощь приходят правила firewall и фичи PKI инфраструктуры.
2) Настроить безопасное взаимодействие между ним и клиентами - HTTPS в помощь.

Запомните одно, что если атакующий получает доступ к etcd, то это game over.

По умолчанию role bindings позволяют аутентифицированным и не аутентифицированным пользователям читать информацию о доступном API, версиях, состоянии в кластере, включая CustomResourceDefinitions.

Это плохо, потому что анонимный не аутентифицированный атакующий, может использовать эту информацию как для подготовки к атаке (на пример, по версии понять как ему надо модифицировать/подготовить тот или иной эксплоит или на основании CustomResourceDefinitions понять что у вас вообще используется и крутится в кластере), так и для ее проведения (на пример, DoS).

Для отключения возможности анонимного не аутентифицированный доступа к этому необходимо добавить параметр --anonymous-auth=false к конфигурации API сервера.

Сегодня обратим внимание на один тонкий момент по работе с etcd с помощью kubeadm. Сразу отметим, что такое поведение исправлено с версии 1.16.

kubeadm делал общий CA для API сервера и etcd. А авторизации у etcd, как вы наверняка уже знаете нет, и получаем, что любой клиент с валидным сертом, считай любой юзер/атакующий даже с минимальными правами, мог ходить в etcd. К чему это может привести мы уже обсуждали ранее.

Суть исправления в том, что теперь kubeadm для API сервера и etcd генерирует разные CA. Но если вы это все делаете руками или самописными скриптами, то держите это в голове, не стреляйте себе в ногу. Подробнее можно почитать и про флаг --peer-trusted-ca-file для etcd

CVE-2020-8558: Node setting allows for neighboring hosts to bypass localhost boundary

Level:
1) MEDIUM (5.4) в обычном кластере.
2) HIGH (8.8) в кластере где API server insecure port не отключен.

В kube-proxy была обнаружена уязвимость, которая позволяет соседним хостам обращаться к TCP/UDP службам, связанным с 127.0.0.1, работающими на Node или в namespace сети Node. Например, если администратор кластера запускает TCP службу на Node, которая прослушивает 127.0.0.1:1234, то из-за этой ошибки эта служба будет потенциально доступна для других хостов в той же LAN, что и Node, или для контейнеров, работающих на той же Node, что и сервис. Спасти от этого может наличие аутентификации на данном сервисе. IPv6-only сервисы на localhost не подвержены данной проблеме.

Во вотором случае, злоумышленник, имеющий доступ к другой системе в той же LAN или контролирующий контейнер, работающий на master сервере, может выполнять произвольные API запросы без аутентификации к Kubernetes API (127.0.0.1:8080)!

Безопасность Harbor. В октябре 2019 года под эгидой CNCF проводился 3rd party security audit для Harbor v1.9.1-rc1 и Harbor Helm v1.2.0 (На момент написания актуальные версии v2.0.1 и v1.4.1). Весь аудит состоял из двух фаз:
1) Пентеста
2) Анализа исходного кода

Было найдено 6 security проблем, из них 4 классифицированы как уязвимости (2 High уровня и 1 как Critical):
- HAR-01-001 Web: Missing CSRF protection leads to privilege escalation (Critical, CVE-2019-19025)
- HAR-01-002 API: SQL Injection via project quotas (High, CVE-2019-19026)
- HAR-01-005 ACL: Unauthorized project-access through project name (Medium)
- HAR-01-006 Web: DOMXSS in outdated Swagger UI (High)
и 2 как слабости:
- HAR-01-003 API: Split-API Injections due to unsanitized input (Low)
- HAR-01-004 Auth: Potential SQL Injection via user-groups (High, CVE-2019-19029)

Для всех уязвимостей в отчете есть PoC'и.

При этом если посмотреть на страницу Security Advisories данного проекта, то там будет всего 7 уязвимостей и пересечения с данным отчетом всего 3. Почему отсутствуют другие уязвимости из отчета там непонятно...

Вчера на свет появился Kubernetes v1.19.0-rc.1 и там есть интересное изменение с точки зрения безопасности, направленное на уменьшение поверхности атаки (attack surface).

Теперь Pod sandbox всегда будет запушен с no-new-privileges и runtime/default seccomp профилем. Как побочный эффект, это позволяет конечным пользователям устанавливать seccomp профили на уровне Pod'ов такие же как и на уровне контейнеров. Естественно, при условии, что Pod имеет контейнеры только с настройкой AllowPrivilegeEscalation = false.

Обнаружено 2 новые уязвимости в Kubernetes:

CVE-2020-8557: Node-local denial of service via container /etc/hosts file

CVSS Rating: Medium (5.5)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H/CR:H/IR:H/AR:M

Суть в том что вредоносный Pod, в который смонтирован /etc/hosts файл с Node, может туда писать огромное количество данных и заполнить все место на Node и вызвать отказ в обсаживании там. Ошибка в расчете при использовании ephemeral storage. Актуально для Pods с контейнерами с возможностью писать туда или свойствами: CAP_DAC_OVERRIDE capabilities, UID 0 (root) правами или allowPrivilegeEscalation: true (по умолчанию).


CVE-2020-8559: Privilege escalation from compromised node to cluster

CVSS Rating: Medium (6.4)
CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:H

Если злоумышленник может перехватить определенные запросы к Kubelet, то он может отправить redirect response, по которому может последовать клиент, используя учетные данные из исходного запроса. Это может привести к компрометации других Node.
Данная уязвимость актуально для вас только в том случае, если вы рассматриваете Node как security boundary или если кластеры разделяет между собой certificate authorities и аутентификационные данные.

В недрах Gartner родился (новый монстр) концепция - куб киберугроз. Каждая из граней куба представляет определённое свойство: уровень/слой приложения/инфраструктуры (Cloud тут естественно присутствует), цель атакующего и стадию, на которой работает механизм защиты (до, во время и после инцидента). А внутри получившихся 27 более маленьких кубов отмечаются соответствующие уровни риска. В принципе, достаточно простая и понятная концепция, которую можно визуализировать что у вас есть чего нету и на каком уровне. По мне внутри можно расположить что конкретно у вас для этого сделано. Так, на пример, можно выписать какие настройки Kubernetes где и как помогают до инцидента (PodSecurityPolicy, Network Policy и т.д.), во время инцидента (run-time защита и т.д.) и после инцидента (Логи и т.д.).

Сегодня рассмотрим 2 простеньких, но полезных запроса на GitHub'е проекта Kubernetes:
- https://github.com/search?q=org%3Akubernetes+CVE&type=Issues
- https://github.com/kubernetes/kubernetes/issues?q=CVE

Суть их проста до безобразия - поиск сокращения CVE (Common Vulnerabilities and Exposures) в issue во всех проектах, что есть у организации Kubernetes и непосредственно в репозитарии Kubernetes. По такому сокращению (это часть идентификатора уязвимости) можно находить как обсуждения каких-то уже известных уязвимостей в сторонних пакетах, используемых в проекте, так и новые, что были выданы компонентам Kubernetes.