[Системное администрирование, Серверное администрирование, DevOps, Kubernetes] Проблемные поды: эскалация привилегий подов в Kubernetes (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Что будет, если разрешить лишнее при создании подов в Kubernetes? Зависит от того, какие неймспейсы хоста и контексты безопасности разрешены. Здесь мы поговорим о восьми небезопасных конфигурациях подов и методах эскалации привилегий. Эта статья и созданный для нее репозиторий помогут пентестерам и администраторам разобраться в распространенных ошибках конфигурации.
Администраторы смогут увереннее применять ограничения по умолчанию для создания подов. Возможно, поды с доступом к ресурсам хоста нужно ограничить неймспейсом, который доступен только администраторам, — по принципу наименьших привилегий.
Пентестеры получат представление о том, как показать последствия слишком либеральной политики безопасности подов. В репозитории вы найдете для этого готовые манифесты и инструкции.
Краткий обзор
Один из главных принципов информационной безопасности — принцип наименьших привилегий. Это значит, что мы даем каждому пользователю, системному процессу и приложению только те разрешения, без которых им не обойтись. Если разрешить слишком многое, кто-то может воспользоваться ситуацией, чтобы похитить конфиденциальные данные, нарушить работу систем или эскалировать привилегии и осуществить перемещение внутри периметра сети.
Слишком большие привилегии — это вообще частая проблема Kubernetes и других технологий DevOps. В нашем исследовании «Проблемные поды» мы показали, что при использовании Kubernetes в инфраструктуре нужно выяснить у разработчиков, как они настраивают и защищают эту среду.
Защита подов: что может натворить один атрибут?
Любой эксперт по безопасности Kubernetes скажет, что при подготовке подов нужно использовать принцип наименьших привилегий. Но как выполнить детальную настройку и оценить риск каждого атрибута?
Администратор Kubernetes может реализовать принцип наименьших привилегий с помощью контроллеров допуска. Это может быть, допустим, встроенный контроллер PodSecurityPolicy или популярный сторонний контроллер OPA Gatekeeper. Контроллеры допуска запрещают поду доступ в кластер, если у него больше разрешений, чем предписано политикой.
Определить и применить политику, конечно, можно, но не всегда понятно, какие атрибуты безопасны, а какие — нет. В итоге разрешений часто бывает больше, чем положено.
Пентестеры часто получают доступ к созданию подов на кластере, где не действует никакая политика. Это я называю легким уровнем сложности. Используем этот манифест от Рори МакКьюна (Rory McCune) (@raesene), эту команду от Даффи Кули (Duffie Cooley) (@mauilion) или плагин node-shell krew — и вот уже можно интерактивно выполнять код в привилегированном режиме на хосте. Проще уже не придумаешь.
А что если создавать поды можно только с hostNetwork, hostPID, hostIPC, hostPath или privileged? Что будет в каждом случае? Сейчас узнаем.
Проблемные поды: атрибуты и их худшие последствия
Я расположил проблемные поды по мере убывания рисков. Атаки, которым подвержены любые поды Kubernetes (например, проверка доступа пода к сервису метаданных облачного провайдера или поиск неправильно настроенного Kubernetes RBAC) описаны в разделе Проблемный под 8: все запрещено.
Проблемные поды:
Поды
Проблемный под 1: все разрешено
Проблемный под 2: Privileged и hostPid
Проблемный под 3: только Privileged
Проблемный под 4: только hostPath
Проблемный под 5: только hostPid
Проблемный под 6: только hostNetwork
Проблемный под 7: только hostIPC
Проблемный под 8: все запрещено.
Проблемный под 1: все разрешено
Что произойдет в худшем случае?
Много всего.
Как?
Созданный под монтирует файловую систему хоста к поду. Проще всего будет создать под в ноде control-plane с помощью селектора nodeName в манифесте. Потом можно выполнить в поде exec и сделать chroot для каталога, где примонтирована файловая система хоста. Теперь у нас есть права root в ноде, где запущен наш под.
- Читаем секреты из etcd. Если мы запускаем под на ноде control-plane с помощью селектора nodeName в спецификации пода, мы легко получаем доступ к базе данных etcd, где хранится вся конфигурация кластера, включая секреты.
- Ищем токены привилегированных учеток сервисов. Даже если удалось запустить под только на рабочей ноде, мы все равно можем получить доступ к секретам всех подов на этой ноде. В продакшен-кластере даже на рабочей ноде всегда есть хотя бы один под с токеном, который привязан к учетке сервиса, связанной с clusterrolebinding, так что мы можем, например, создавать поды или просматривать секреты во всех неймспейсах.
Больше схем эскалации привилегий см. в файле README (ниже) и в разделе Проблемный под 4: hostPath.
Примеры использования
https://github.com/BishopFox/badPods/tree/main/manifests/everything-allowed
Дополнительные материалы
- Самая бестолковая команда Kubernetes на свете
- Защита Kubernetes — KubeCon NA 2019 CTF
- Подробный обзор угроз для Kubernetes в реальном мире
- Компрометация кластера Kubernetes с помощью разрешений RBAC (слайды)
- Неизведанный путь: атака на Kubernetes с параметрами по умолчанию с репозиторием
Проблемный под 2: privileged и hostpid
Что произойдет в худшем случае?
Много всего.
Как?
Единственное отличие от предыдущего варианта — способ получения root-доступа к хосту. Там мы делали chroot для файловой системы хоста, а здесь используем nsenter, чтобы получить права root для ноды, где запущен наш под.
Почему это работает?
- Privileged. Контекст безопасности privileged: true на уровне контейнера ломает почти любые преграды, которые по идее должен давать контейнер для защиты от атак. Остается разве что неймспейс PID. Без hostPID nsenter сможет входить только в неймспейсы процесса, который запущен в контейнере. Больше примеров действий, которые можно совершить с privileged: true, см. в следующем разделе — Проблемный под 3: только Privileged.
- Privileged + hostPID. Если одновременно задать hostPID: true и privileged: true, поду будут доступны все процессы на хосте, и мы сможем войти в систему init (PID 1) на хосте. А там уже можно запустить shell на ноде.
С root-доступом на хосте у нас есть те же пути эскалации привилегий, о которых мы говорили в разделе Проблемный под 1: все разрешено.
Примеры использования
https://github.com/BishopFox/badPods/tree/main/manifests/priv-and-hostpid
Дополнительные материалы
- Твит Даффи Кули (Duffie Cooley) про Nsenter Pod
- Неизведанный путь: атака на Kubernetes с параметрами по умолчанию с репозиторием
- Node-shell Krew Plugin
Проблемный под 3: только privileged
Что произойдет в худшем случае?
Много всего.
Как?
С privileged: true у нас два пути:
- Примонтировать файловую систему хоста. В привилегированном режиме /dev на хосте будет доступен нашему поду. Мы можем примонтировать к нашему поду диск с файловой системой хоста командой mount. По моему опыту, полной свободы действий нам это не даст. Некоторые файлы и пути эскалации привилегий недоступны из привилегированного пода, если только мы не эскалируем его до полноценной shell. Зато можно легко примонтировать диск и посмотреть, что мы там увидим.
- Использовать уязвимость cgroup в user mode с помощью специальных программ. Лучше всего получить интерактивный root-доступ к ноде, но тут придется повозиться. Можем использовать прототип эксплойта Феликса Уилхелма (Felix Wilhelm) undock.sh, чтобы выполнять по команде за раз, или вариант, который Брэндон Эдвадрс (Brandon Edwards) и Ник Фриман (Nick Freeman) предложили в своем выступлении Краткое руководство по выходу из контейнера. В этом варианте мы заставляем хост подключиться к listener на поде для эскалации до интерактивного root-доступа на хосте. Еще один вариант — взять модуль Metasploit Docker Privileged Container Escape, где используется тот же эксплойт для апгрейда shell на контейнере до shell на хосте.
При любом варианте пути эскалации привилегий в Kubernetes во многом похожи на те, которые мы описали для проблемного пода 1, где все разрешено.
Примеры использования
https://github.com/BishopFox/badPods/tree/main/manifests/priv
Дополнительные материалы
- Экслойт Феликса Уилхелма Cgroup Usermode Helper
- Обзор Container Escape в Docker
- Краткое руководство по выходу из контейнера
- Модуль Metasploit Docker Privileged Container Escape
Проблемный под 4: только hostpath
Что произойдет в худшем случае?
Много всего.
Как?
Допустим, у нас нет доступа к хостовым process- и network- неймспейсам, но администраторы не ограничили возможности монтирования. Тогда можно примонтировать всю файловую систему хоста к поду и получить к ней доступ на чтение и запись. Теперь можем использовать те же пути эскалации привилегий, что и раньше. Этих путей столько, что Иен Колдуотер (Ian Coldwater) и Даффи Кули (Duffie Cooley) посвятили им целое выступление на Black Hat 2019: «Неизведанный путь: атака на Kubernetes с параметрами по умолчанию».
Вот несколько путей эскалации привилегий, которые можно использовать, когда у нас есть доступ к файловой системе ноды Kubernetes:
- Ищем файлы kubeconfig в файловой системе хоста. Если повезет, можно даже найти конфигурацию cluster-admin с полным доступом вообще ко всему.
- Ищем токены во всех подах на ноде. Возьмем что-то типа kubectl auth can-i --list или access-matrix и посмотрим, есть ли в подах токены, которые дадут нам больше разрешений. Ищем токены, с которыми можно получать секреты или создавать поды, деплойменты и т. д. в kube-system или создавать clusterrolebinding.
- Добавляем свой SSH-ключ. Если у нас есть сетевой доступ к SSH-соединению с нодой, добавим к ноде свой публичный ключ и подключимся к ней по SSH, чтобы получить полный интерактивный доступ.
- Ломаем хэшированные пароли. Взламываем хэши в /etc/shadow и пытаемся использовать их для доступа к другим нодам.
Примеры использования
https://github.com/BishopFox/badPods/tree/main/manifests/hostpath
Дополнительные материалы
- Неизведанный путь: атака на Kubernetes с параметрами по умолчанию с репозиторием
- Защита Kubernetes — KubeCon NA 2019 CTF
- Подробный обзор угроз для Kubernetes в реальном мире
- Компрометация кластера Kubernetes с помощью разрешений RBAC (слайды)
Проблемный под 5: только hostpid
Что произойдет в худшем случае?
При неправильной настройке приложения в кластере можно добраться до учетных данных приложения или кластера. Произойдет отказ в обслуживании из-за завершения процесса.
Как?
С одним только hostPID не так просто получить root-доступ к ноде, но кое-что натворить можно.
- Смотрим процессы на хосте. Если запустим ps в поде с hostPID: true, увидим все процессы на хосте, включая процессы на каждом поде.
- Ищем пароли, токены, ключи и тому подобное.Если повезет, найдем что-нибудь для эскалации привилегий и доберемся до кластера, до сервисов, поддерживаемых кластером, или до сервисов, которые общаются с приложениями на кластере. Придется повозиться, но можно найти токен для учетки сервиса в Kubernetes или что-то подобное, чтобы раздобыть доступ к другим пространствам имен и в итоге получить привилегии cluster-admin.
- Завершаем процессы. Можно завершить на ноде любой процесс, чтобы вызвать отказ в обслуживании (не советую пентестерам экспериментировать с этим пунктом).
Примеры использования
https://github.com/BishopFox/badPods/tree/main/manifests/hostpid
Проблемный под 6: только hostnetwork
Что произойдет в худшем случае?
Риск компрометации кластера.
Как?
Если у нас есть только hostNetwork: true, напрямую выполнить код в привилегированном режиме на хосте мы не можем, но если сильно повезет, шанс добраться до cluster-admin все же есть. Путей эскалации может быть три:
- Прослушиваем трафик. С tcpdump можно прослушивать незашифрованный трафик на любом интерфейсе хоста. Если звезды сложатся, нам попадутся токены учетки сервиса или другая конфиденциальная информация, которая передается по незашифрованным каналам.
- Получаем доступ к сервисам, связанным с localhost. Мы можем получить доступ к сервисам, которые принимают трафик только через loopback интерфейс хоста или как-то еще ограничены сетевыми политиками. Оттуда можно найти какие-нибудь интересные пути эскалации привилегий.
- Обходим сетевую политику. Если пространство имен ограничено сетевой политикой, можно задеплоить под с атрибутом hostNetwork: true, чтобы обойти эти ограничения. Суть в том, что мы привязываемся к сетевым интерфейсам хоста, а не подам.
Примеры использования
https://github.com/BishopFox/badPods/tree/main/manifests/hostnetwork
Проблемный под 7: только hostipc
Что произойдет в худшем случае?
Можно получить доступ к данным, к которым обращаются поды, использующие пространство имен хоста IPC.
Как?
Если какой-то процесс на хосте или процессы в поде используют механизмы межпроцессного взаимодействия (IPC) хоста (общая память, массивы семафоров, очереди сообщений и т. д.), можно использовать эти механизмы для чтения/записи. Сначала ищем /dev/shm, общий для всех подов с атрибутом hostIPC: true и хоста. Можно проверить и другие механизмы IPC с помощью ipcs.
- Проверяем /dev/shm. Ищем файлы в общей памяти.
- Проверяем существующие объекты IPC. С помощью /usr/bin/ipcs можно узнать, используются ли какие-нибудь объекты IPC.
Примеры использования
https://github.com/BishopFox/badPods/tree/main/manifests/hostipc
Проблемный под 8: все запрещено
Что произойдет в худшем случае?
Много всего.
Как?
Даже если все атрибуты запрещены, мы все равно можем найти множество путей атак, если можно создать под или хотя бы получить к нему доступ. Имея доступ к поду Kubernetes, обращаем внимание на следующее:
- Доступные облачные метаданные. Если под размещен в облаке, пытаемся получить доступ к облачному сервису метаданных. Там можно найти учетные данные IAM, связанные с нодой, или хотя бы облачные учетные данные IAM, созданные специально для этого пода. В обоих случаях можно добраться до кластера, до облачной среды или и туда, и туда.
- Учетки сервисов с лишними разрешениями. Если учетка сервиса по умолчанию в пространстве имен примонтирована к /var/run/secrets/kubernetes.io/serviceaccount/token в поде и позволяет слишком многое, с этим токеном можно эскалировать привилегии в кластере.
- Компоненты Kubernetes с неправильной конфигурацией. Если у apiserver или kubelet'ов для anonymous-auth задано true и никакие сетевые политики нам не мешают, можно взаимодействовать с ними напрямую без аутентификации.
- Эксплойты в ядре, движке контейнера или Kubernetes. Эксплойт в этих компонентах можно использовать для выхода из контейнера или доступа к кластеру Kubernetes без дополнительных разрешений.
- Уязвимые сервисы. Если смотреть на сетевые сервисы кластера через под, скорее всего, мы увидим больше, чем с машины, где создали этот под. Можем поискать уязвимые сервисы и приложения, направляя трафик через под.
Примеры использования
https://github.com/BishopFox/badPods/tree/main/manifests/nothing-allowed
Дополнительные материалы
Защита Kubernetes — KubeCon NA 2019 CTF
Kubernetes Goat
Атака на Kubernetes через Kubelet
Подробный обзор угроз для Kubernetes в реальном мире
Краткое руководство по выходу из контейнера
CVE-2020-8558 POC
Заключение
Если не считать проблемный под номер 8, где все и так запрещено, все пути эскалации привилегий в этом посте (и репозитории к нему) можно перекрыть политиками безопасности.
Администраторы Kubernetes могут использовать и другие методы глубокой защиты, чтобы снизить или полностью устранить риски некоторых путей атак, даже если у злоумышленника есть доступ к некоторым или ко всем неймспейсам и возможностям на хосте (отключить автоматическое монтирование токенов учеток сервисов или запретить подам запуск с правами root, указав MustRunAsNonRoot=trueи allowPrivilegeEscalation=false). Как это обычно и бывает с пентестами, для взлома может потребоваться больше или меньше усилий.
Админам часто приходится применять методы защиты без примеров последствий, к которым может привести та или иная рискованная конфигурация. Надеюсь, примеры в этом посте и манифестах в репозитории Bad Pods помогут вам применять принцип наименьших привилегий при создании подов Kubernetes в вашей компании.
От редакции: подробнее о безопасности в K8s можно узнать на интенсиве Kubernetes Мега. Интенсив пройдет в онлайн-формате с 17 по 19 мая 2021.
===========
Источник:
habr.com
===========
===========
Автор оригинала: Seth Art
===========Похожие новости:
- [Системное администрирование, Системное программирование, DevOps] Упаковка любого python пакета в rpm пакет с возможностью offline установки
- [Настройка Linux, Системное администрирование, *nix, Сетевые технологии] Укрощение строптивого HAPROXY. Работаем ssl <--> ssl с генерацией сертификатов отдельно на каждом сервере
- [Информационная безопасность, Open source, DevOps] Автоматизируем поиск секретов в git и ansible
- [Информационная безопасность, Системное администрирование] Обнаружена 0day уязвимость повышения привилегий в Windows 7-10
- [Настройка Linux, Системное администрирование, Серверное администрирование, Резервное копирование] Настраиваем Restic с systemd на Linux
- [Системное администрирование, IT-инфраструктура, DevOps] Изучаем ELK. Часть II — Установка Kibana и Logstash
- [Настройка Linux, Системное администрирование] Настраиваем домашний почтовый сервер и уходим с «бесплатной» почты
- [Разработка веб-сайтов, Open source, Тестирование IT-систем, Тестирование веб-сервисов] Callisto. Зачем мы придумали замену Selenium Grid
- [Настройка Linux, Системное программирование, Серверное администрирование] Релиз серверного дистрибутива Zentyal 7.0 на пакетной базе Ubuntu 20.04 LTS
- [Настройка Linux, Системное администрирование, Софт, Накопители] Самый актуальный гайд по установке Linux на SSD-накопители в 2021 году
Теги для поиска: #_sistemnoe_administrirovanie (Системное администрирование), #_servernoe_administrirovanie (Серверное администрирование), #_devops, #_kubernetes, #_kubernetes, #_k8s, #_pod, #_pods, #_bezopasnost_v_kubernetes (безопасность в kubernetes), #_blog_kompanii_southbridge (
Блог компании Southbridge
), #_sistemnoe_administrirovanie (
Системное администрирование
), #_servernoe_administrirovanie (
Серверное администрирование
), #_devops, #_kubernetes
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 15:25
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Что будет, если разрешить лишнее при создании подов в Kubernetes? Зависит от того, какие неймспейсы хоста и контексты безопасности разрешены. Здесь мы поговорим о восьми небезопасных конфигурациях подов и методах эскалации привилегий. Эта статья и созданный для нее репозиторий помогут пентестерам и администраторам разобраться в распространенных ошибках конфигурации. Администраторы смогут увереннее применять ограничения по умолчанию для создания подов. Возможно, поды с доступом к ресурсам хоста нужно ограничить неймспейсом, который доступен только администраторам, — по принципу наименьших привилегий. Пентестеры получат представление о том, как показать последствия слишком либеральной политики безопасности подов. В репозитории вы найдете для этого готовые манифесты и инструкции. Краткий обзор Один из главных принципов информационной безопасности — принцип наименьших привилегий. Это значит, что мы даем каждому пользователю, системному процессу и приложению только те разрешения, без которых им не обойтись. Если разрешить слишком многое, кто-то может воспользоваться ситуацией, чтобы похитить конфиденциальные данные, нарушить работу систем или эскалировать привилегии и осуществить перемещение внутри периметра сети. Слишком большие привилегии — это вообще частая проблема Kubernetes и других технологий DevOps. В нашем исследовании «Проблемные поды» мы показали, что при использовании Kubernetes в инфраструктуре нужно выяснить у разработчиков, как они настраивают и защищают эту среду. Защита подов: что может натворить один атрибут? Любой эксперт по безопасности Kubernetes скажет, что при подготовке подов нужно использовать принцип наименьших привилегий. Но как выполнить детальную настройку и оценить риск каждого атрибута? Администратор Kubernetes может реализовать принцип наименьших привилегий с помощью контроллеров допуска. Это может быть, допустим, встроенный контроллер PodSecurityPolicy или популярный сторонний контроллер OPA Gatekeeper. Контроллеры допуска запрещают поду доступ в кластер, если у него больше разрешений, чем предписано политикой. Определить и применить политику, конечно, можно, но не всегда понятно, какие атрибуты безопасны, а какие — нет. В итоге разрешений часто бывает больше, чем положено. Пентестеры часто получают доступ к созданию подов на кластере, где не действует никакая политика. Это я называю легким уровнем сложности. Используем этот манифест от Рори МакКьюна (Rory McCune) (@raesene), эту команду от Даффи Кули (Duffie Cooley) (@mauilion) или плагин node-shell krew — и вот уже можно интерактивно выполнять код в привилегированном режиме на хосте. Проще уже не придумаешь. А что если создавать поды можно только с hostNetwork, hostPID, hostIPC, hostPath или privileged? Что будет в каждом случае? Сейчас узнаем.  Проблемные поды: атрибуты и их худшие последствия Я расположил проблемные поды по мере убывания рисков. Атаки, которым подвержены любые поды Kubernetes (например, проверка доступа пода к сервису метаданных облачного провайдера или поиск неправильно настроенного Kubernetes RBAC) описаны в разделе Проблемный под 8: все запрещено. Проблемные поды: Поды Проблемный под 1: все разрешено Проблемный под 2: Privileged и hostPid Проблемный под 3: только Privileged Проблемный под 4: только hostPath Проблемный под 5: только hostPid Проблемный под 6: только hostNetwork Проблемный под 7: только hostIPC Проблемный под 8: все запрещено. Проблемный под 1: все разрешено  Что произойдет в худшем случае? Много всего. Как? Созданный под монтирует файловую систему хоста к поду. Проще всего будет создать под в ноде control-plane с помощью селектора nodeName в манифесте. Потом можно выполнить в поде exec и сделать chroot для каталога, где примонтирована файловая система хоста. Теперь у нас есть права root в ноде, где запущен наш под.
Больше схем эскалации привилегий см. в файле README (ниже) и в разделе Проблемный под 4: hostPath. Примеры использования https://github.com/BishopFox/badPods/tree/main/manifests/everything-allowed Дополнительные материалы
Проблемный под 2: privileged и hostpid  Что произойдет в худшем случае? Много всего. Как? Единственное отличие от предыдущего варианта — способ получения root-доступа к хосту. Там мы делали chroot для файловой системы хоста, а здесь используем nsenter, чтобы получить права root для ноды, где запущен наш под. Почему это работает?
С root-доступом на хосте у нас есть те же пути эскалации привилегий, о которых мы говорили в разделе Проблемный под 1: все разрешено. Примеры использования https://github.com/BishopFox/badPods/tree/main/manifests/priv-and-hostpid Дополнительные материалы
Проблемный под 3: только privileged  Что произойдет в худшем случае? Много всего. Как? С privileged: true у нас два пути:
При любом варианте пути эскалации привилегий в Kubernetes во многом похожи на те, которые мы описали для проблемного пода 1, где все разрешено. Примеры использования https://github.com/BishopFox/badPods/tree/main/manifests/priv Дополнительные материалы
Проблемный под 4: только hostpath  Что произойдет в худшем случае? Много всего. Как? Допустим, у нас нет доступа к хостовым process- и network- неймспейсам, но администраторы не ограничили возможности монтирования. Тогда можно примонтировать всю файловую систему хоста к поду и получить к ней доступ на чтение и запись. Теперь можем использовать те же пути эскалации привилегий, что и раньше. Этих путей столько, что Иен Колдуотер (Ian Coldwater) и Даффи Кули (Duffie Cooley) посвятили им целое выступление на Black Hat 2019: «Неизведанный путь: атака на Kubernetes с параметрами по умолчанию». Вот несколько путей эскалации привилегий, которые можно использовать, когда у нас есть доступ к файловой системе ноды Kubernetes:
Примеры использования https://github.com/BishopFox/badPods/tree/main/manifests/hostpath Дополнительные материалы
Проблемный под 5: только hostpid  Что произойдет в худшем случае? При неправильной настройке приложения в кластере можно добраться до учетных данных приложения или кластера. Произойдет отказ в обслуживании из-за завершения процесса. Как? С одним только hostPID не так просто получить root-доступ к ноде, но кое-что натворить можно.
Примеры использования https://github.com/BishopFox/badPods/tree/main/manifests/hostpid Проблемный под 6: только hostnetwork  Что произойдет в худшем случае? Риск компрометации кластера. Как? Если у нас есть только hostNetwork: true, напрямую выполнить код в привилегированном режиме на хосте мы не можем, но если сильно повезет, шанс добраться до cluster-admin все же есть. Путей эскалации может быть три:
Примеры использования https://github.com/BishopFox/badPods/tree/main/manifests/hostnetwork Проблемный под 7: только hostipc  Что произойдет в худшем случае? Можно получить доступ к данным, к которым обращаются поды, использующие пространство имен хоста IPC. Как? Если какой-то процесс на хосте или процессы в поде используют механизмы межпроцессного взаимодействия (IPC) хоста (общая память, массивы семафоров, очереди сообщений и т. д.), можно использовать эти механизмы для чтения/записи. Сначала ищем /dev/shm, общий для всех подов с атрибутом hostIPC: true и хоста. Можно проверить и другие механизмы IPC с помощью ipcs.
Примеры использования https://github.com/BishopFox/badPods/tree/main/manifests/hostipc Проблемный под 8: все запрещено  Что произойдет в худшем случае? Много всего. Как? Даже если все атрибуты запрещены, мы все равно можем найти множество путей атак, если можно создать под или хотя бы получить к нему доступ. Имея доступ к поду Kubernetes, обращаем внимание на следующее:
Примеры использования https://github.com/BishopFox/badPods/tree/main/manifests/nothing-allowed Дополнительные материалы Защита Kubernetes — KubeCon NA 2019 CTF Kubernetes Goat Атака на Kubernetes через Kubelet Подробный обзор угроз для Kubernetes в реальном мире Краткое руководство по выходу из контейнера CVE-2020-8558 POC Заключение Если не считать проблемный под номер 8, где все и так запрещено, все пути эскалации привилегий в этом посте (и репозитории к нему) можно перекрыть политиками безопасности. Администраторы Kubernetes могут использовать и другие методы глубокой защиты, чтобы снизить или полностью устранить риски некоторых путей атак, даже если у злоумышленника есть доступ к некоторым или ко всем неймспейсам и возможностям на хосте (отключить автоматическое монтирование токенов учеток сервисов или запретить подам запуск с правами root, указав MustRunAsNonRoot=trueи allowPrivilegeEscalation=false). Как это обычно и бывает с пентестами, для взлома может потребоваться больше или меньше усилий. Админам часто приходится применять методы защиты без примеров последствий, к которым может привести та или иная рискованная конфигурация. Надеюсь, примеры в этом посте и манифестах в репозитории Bad Pods помогут вам применять принцип наименьших привилегий при создании подов Kubernetes в вашей компании. От редакции: подробнее о безопасности в K8s можно узнать на интенсиве Kubernetes Мега. Интенсив пройдет в онлайн-формате с 17 по 19 мая 2021.
=========== Источник: habr.com =========== =========== Автор оригинала: Seth Art ===========Похожие новости:
Блог компании Southbridge ), #_sistemnoe_administrirovanie ( Системное администрирование ), #_servernoe_administrirovanie ( Серверное администрирование ), #_devops, #_kubernetes |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 15:25
Часовой пояс: UTC + 5