Обзор уязвимостей приложений на платформе Kubernetes.

Рассмотрим основные риски приложений, построенные на платформе Kubernetes, в соответствии с OWASP Kubernetes Top 10.

1. Небезопасные конфигурации рабочей нагрузки
Параметры безопасности Kubernetes-приложений предоставляют широкие полномочия для конфигурации, что может привести к серьезным проблемам с безопасностью. Как следствие, имели место инциденты, связанные с неверной конфигурацией в средах Kubernetes.
Примеры конфигураций, которые могут повлиять на надежность, безопасность и масштабируемость рабочей нагрузки:
процессы приложений не должны запускаться от имени root-пользователя. Если контейнер будет скомпрометирован, злоумышленник сможет запустить вредоносные процессы, которые не были бы разрешены для других пользователей в системе;
следует использовать файловые системы только для чтения. Это предотвращает обратную запись вредоносного процесса или приложения в хост-систему;
привилегированные контейнеры следует запретить. Эти модули могут получить доступ к дополнительным ресурсам и возможностям ядра самого хоста и полностью удалить многие встроенные механизмы изоляции контейнеров.
Как предотвратить. Чтобы предотвратить неправильные конфигурации, их необходимо сначала обнаружить как во время выполнения, так и в коде. Для этого можно использовать такие инструменты, как Open Policy Agent. Отправной точкой может быть тест CIS Benchmark для Kubernetes.

2. Уязвимости цепочек поставок
Один контейнер Kubernetes может полагаться на сотни сторонних компонентов и зависимостей. В результате появляются проблемы целостности образа, уязвимости стороннего ПО и так далее.
Большинство команд используют ту или иную форму автоматизации, чтобы создавать образы контейнеров и отправлять их в центральный реестр. Затем образ извлекается из Kubernetes, как указано в манифесте объекта. Если эта система сборки будет скомпрометирована и вредоносный пакет будет внедрен как часть сборки, Kubernetes загрузит образ в кластер и запустит его. Таким образом может быть запущено вредоносное ПО, установлены майнеры криптовалюты или бэкдор.
Как предотвратить. Образы контейнеров можно рассматривать как набор программных артефактов и метаданных, которые производитель передает потребителю. На каждом этапе этого пути необходимо контролировать целостность ПО. Отправной точкой для проверок безопасности может служить Software Bill of Materials (SBOM) – документ, в котором перечислены все программные элементы, составляющие продукт.
Первой линией защиты должно стать сканирование уязвимостей, например Clair-ом. Образы следует быстро исправлять, заменяя слой, содержащий уязвимость, и перестраивая контейнер для использования актуальных фиксированных пакетов.
Образы контейнеров следует создавать с использованием минимального количества пакетов ОС и зависимостей, чтобы в случае компрометации уменьшить поверхность атаки. Также важно убедиться, что базовые образы обновлены до последних версий. Такие инструменты, как Docker Slim, помогают оптимизировать размер образа из соображений производительности и безопасности.
Чтобы неутвержденные образы не попали в боевую среду, необходимо использовать средства управления доступом Kubernetes и контроля политик наподобие Open Policy Agent и Kyverno. Они будут отклонять образы рабочих нагрузок, которые не прошли проверку на наличие уязвимостей, не включают утвержденный SBOM, созданы из ненадежных реестров.

3. Чрезмерно свободные конфигурации доступа (RBAC)
Управление доступом на основе ролей (Role-based access control, RBAC) является основным механизмом авторизации в Kubernetes, отвечающим за права доступа к ресурсам. При правильной настройке это отличный механизм для обеспечения безопасности.
Как предотвратить. Чтобы снизить риск злоупотребления конфигурациями RBAC, важно постоянно анализировать конфигурации. Основные рекомендации от экспертов OWASP:
по возможности сокращайте прямой доступ пользователей к кластеру;
не используйте токены служебной учетной записи за пределами кластера;
избегайте автоматического подключения дефолтного служебного токена;
проверяйте RBAC сторонних компонентов;
разворачивайте централизованные политики, чтобы блокировать рискованные разрешения RBAC;
используйте RoleBindings, чтобы ограничить разрешения отдельным неймспейсам;
следуйте официальным рекомендациям по использованию RBAC в документации Kubernetes.

4. Отсутствие централизованного применения политик
Применение политик Kubernetes может и должно происходить на протяжении жизненного цикла поставки программного обеспечения. Принудительное применение политик дает специалистам по комплаенсу и безопасности возможность применять требования управления, соответствия и безопасности во всей мультикластерной/мультиоблачной инфраструктуре.
Как предотвратить. Неправильно настроенные объекты Kubernetes должны быть заблокированы на старте. Обычно этим занимается Admission Controller в самом Kubernetes API. В этом API есть встроенная функциональность под названием Pod Security Standards, которая обеспечивает соблюдение политик в качестве части контроллера доступа Pod Security в самом кластере. Он предлагает три режима - привилегированный, базовый и ограниченный. Альтернативные варианты: Open Policy Agent Gatekeeper, Kyverno, Kubewarden также позволяют применять политики и блокируют доступ к кластеру при некорректных настройках модулей.

5. Ошибки логирования и мониторинга
Среда Kubernetes может вести логи на самых разных уровнях из множества различных компонентов. Если компания пренебрегает логами, злоумышленники могут использовать уязвимости, оставаясь практически незамеченными.
Неверное логирование может способствовать следующему:
неудачные попытки аутентификации, доступ к конфиденциальным ресурсам, ручное удаление или изменение ресурсов Kubernetes остаются незамеченными;
логи и трейсы запущенных рабочих нагрузок не проверяются на подозрительную активность;
не поступают уведомления о превышении пороговых значений – растет риск падения производительности и сбоев.
Как предотвратить. Kubernetes умеет записывать для последующего анализа действия, предпринятые API. Журналы аудита помогают ответить на вопросы, касающиеся событий, происходящих на самом сервере API.
События Kubernetes могут указывать на любые изменения состояния ресурсов и ошибки вроде превышения квоты ресурсов. Самый простой способ сохранения этих журналов - убедиться, что выходные данные записываются в стандартный поток вывода stdout и стандартный поток ошибок stderr.
Надежная архитектура логирования должна не только фиксировать соответствующие события безопасности, но и быть централизованной. Тогда к ней можно будет обращаться, сохранять на длительную перспективу, отслеживать целостность.

6. Сломанные механизмы аутентификации
На платформе Kubernetes реализована чрезвычайно гибкая аутентификация. Это создает определенные проблемы, когда речь идет о состоянии безопасности кластера и облака. Например, разработчик проверяет свой файл .kubeconfig с личного ноутбука, который содержит учетные данные для доступа к рабочим кластерам Kubernetes. При сканировании Github злоумышленник находит их и воспроизводит в целевом API, которое, к сожалению, доступно из интернета. Поскольку кластер настроен на аутентификацию с использованием сертификатов, утекший файл содержит всю информацию для успешной аутентификации в целевом кластере.
Как предотвратить. Избегайте использования сертификатов для аутентификации конечных пользователей. В настоящее время у API нет возможности отзывать сертификаты, что позволяет восстановить ключ кластера при компрометации закрытого ключа.
Используйте то, что поддерживается и широко применяется. По возможности применяйте мультифакторную аутентификацию.
Не используйте токены сервисной учетной записи из-за пределов кластера. Они не могут быть привязаны к группам, и срок их действия никогда не истекает. Все токены аутентификации должны быть настолько недолговечными, насколько это допустимо.

7. Отсутствуют элементы управления сегментацией сети
Сеть Kubernetes по умолчанию плоская. Это означает, что при отсутствии дополнительных элементов управления любая рабочая нагрузка может без ограничений взаимодействовать с другой. Злоумышленники могут использовать это, чтобы прощупать внутреннюю сети, перейти к другим работающим контейнерам или вызвать частные API.
Как предотвратить. Сегментация сети в Kubernetes минимизирует негативные последствия при компрометации контейнера и блокирует перемещения, позволяя при этом легитимному трафику маршрутизироваться.
Один из способов по-настоящему обеспечить сетевую изоляцию в Kubernetes - использовать отдельные кластеры, когда это уместно. Сетевые политики действуют наподобие файрвола и контролируют взаимодействие модулей. Определять их следует таким образом, чтобы поды могли взаимодействовать только с определенными активами, а все остальное было запрещено.
Сетевой интерфейс контейнеров (Container Network Interface, CNI) - это спецификация с открытым исходным кодом, которая используется для настройки доступа к сетевым ресурсам. Этот механизм открывает или запрещает доступ к сети внутри Kubernetes. Такие решения, как Project Calico и Cilium, предлагают разные механизмы изоляции сетевого трафика. При выборе CNI очень важно понимать набор функций, который вы ищете с точки зрения безопасности, а также накладные расходы на ресурсы и обслуживание.
8. Ошибки управления секретами
В Kubernetes секрет - это отдельный объект API в Kubernetes, используемый для хранения конфиденциальных данных вроде паролей или токенов. Необходимо контролировать, как хранятся учетные данные, ключи и прочие подобные элементы.
Как предотвратить. Шифруйте секреты в состоянии покоя. База данных etcd в целом содержит любую информацию, доступную через Kubernetes API, и может предоставить злоумышленнику значительную информацию о состоянии вашего кластера.
Всегда шифруйте свои резервные копии, используя хорошо проверенное решение. Чтобы обеспечить безопасность и защиту секретов, важно начать с надежной конфигурации во всех ваших кластерах.
Предоставьте минимальные привилегии всем сервисным учетным записям и конечным пользователям, особенно когда речь идет о доступе к секретам. Всегда проверяйте конфигурацию RBAC сторонних подключаемых модулей и установленного в кластере ПО, чтобы доступ к секретам Kubernetes не открывался без необходимости.

9. Неправильно настроенные компоненты кластера
Неправильная конфигурация основных компонентов Kubernetes может привести к полной компрометации кластера. Примеры критически важных модулей:
kubelet: агент, который запускается на каждом ноде кластера и обеспечивает работоспособность контейнеров. При взаимодействии с Kubelets следует всегда выполнять проверки авторизации;
etcd: высокодоступное хранилище ключей и значений, которое Kubernetes использует для централизованного хранения всех данных кластера;
kube-apiserver: сервер API - это внешний интерфейс для контрольной плоскости Kubernetes.
Как предотвратить. Начать следует с регулярного сканирования и аудита CIS Benchmark. Это поможет выявить неправильные конфигурации компонентов. Подход Infrastructure-as-Code также может помочь централизовать настройку и исправление Kubernetes, предоставляя группам безопасности информацию о том, как создаются и обслуживаются кластеры.

10. Устаревшие и уязвимые компоненты Kubernetes
Кластер Kubernetes - это чрезвычайно сложная программная экосистема, которая может создавать проблемы, когда речь идет о традиционном управлении исправлениями и уязвимостями. Администраторы должны внимательно следить за базами данных, раскрытием и обновлениями CVE, иметь план управления исправлениями.
Как предотвратить. Прежде всего, нельзя исключить Kubernetes и связанные с ним компоненты из существующего процесса сканирования уязвимостей CVE. Такие инструменты, как OPA Gatekeeper, можно использовать для написания пользовательских правил, которые обнаруживают уязвимые компоненты в кластере.
Сведите к минимуму сторонние зависимости. Все стороннее ПО должно проходить аудит перед развертыванием: ищите чрезмерно разрешающие RBAC, низкоуровневый доступ к ядру, записи о ранее обнаруженных уязвимостях.