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

Некоммерческая организация Open Web Application Security Project описала типичные проблемы безопасности, которые угрожают современным облачным приложениям. Портал Cyber Media изучил новый рейтинг и собрал мнения экспертов о том, насколько он будет полезным.

Open Web Application Security Project (OWASP) — это открытое интернет-сообщество специалистов, которое разрабатывает методологии, документацию, инструменты и технологии в области безопасности веб-приложений.

OWASP Kubernetes Top 10 представляет собой логичное продолжение рейтинга OWASP Top Ten, который выходит с 2003 года и объединяет угрозы безопасности веб-приложений.

По словам экспертов OWASP, новый рейтинг призван помочь специалистам по безопасности, системным администраторам и разработчикам программного обеспечения определить приоритеты рисков в экосистеме Kubernetes. Список рисков основан на данных, которые были собраны в десятках организаций разной степени зрелости и сложности ИТ-процессов.

K01:2022 Небезопасные конфигурации рабочей нагрузки

Контекст безопасности Kubernetes-приложений поддается глубокой настройке, что может привести к серьезным проблемам безопасности, которые будут распространяться по всей организации. Эксперты OWASP ссылаются на исследование безопасности Kubernetes, которое в 2021 году провела Redhat. Почти 60% респондентов сталкивались с инцидентом, связанным с неправильной конфигурацией в средах Kubernetes.

Примеры конфигураций, которые могут повлиять на надежность, безопасность и масштабируемость рабочей нагрузки:

• Процессы приложений не должны запускаться от имени root-пользователя. Если контейнер будет скомпрометирован, злоумышленник сможет запустить вредоносные процессы, которые не были бы разрешены для других пользователей в системе.

• Следует использовать файловые системы только для чтения. Это предотвращает обратную запись вредоносного процесса или приложения в хост-систему.

• Привилегированные контейнеры следует запретить: эти модули могут получить доступ к дополнительным ресурсам и возможностям ядра самого хоста и полностью удалить многие встроенные механизмы изоляции контейнеров.
  

Как предотвратить

«Хотя многие конфигурации безопасности часто задаются в securityContext самого манифеста, неправильные конфигурации могут скрываться в других местах, – указывают эксперты OWASP. – Чтобы предотвратить неправильные конфигурации, их необходимо сначала обнаружить как во время выполнения, так и в коде. Для этого можно использовать такие инструменты, как Open Policy Agent. Отправной точкой может быть тест CIS Benchmark для Kubernetes».

K02:2022 Уязвимости цепочек поставок

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

«Образ контейнера состоит из слоев, каждый из которых может влиять на общую безопасность. Правильно созданный образ контейнера не только уменьшает поверхность атаки, но и может повысить эффективность развертывания».

Большинство команд используют ту или иную форму автоматизации, чтобы создавать образы контейнеров и отправлять их в центральный реестр. Затем образ извлекается из Kubernetes, как указано в манифесте объекта. Если эта система сборки будет скомпрометирована и вредоносный пакет будет внедрен как часть сборки, Kubernetes загрузит образ в кластер и запустит его. Таким образом может быть запущено вредоносное ПО, установлены майнеры криптовалюты или бэкдор.

Один из недавних примеров, чем может грозить скомпрометированная целостность образа, является взлом Solarwinds.

Как предотвратить

Образы контейнеров можно рассматривать как набор программных артефактов и метаданных, которые производитель передает потребителю. На каждом этапе этого пути необходимо контролировать целостность ПО.

Отправной точкой для проверок безопасности может служить Software Bill of Materials (SBOM) – документ, в котором перечислены все программные элементы, составляющие продукт. В этот список должны входить все пакеты ПО, лицензий и библиотек, которые содержатся в том или ином артефакте.

Первой линией защиты должно стать сканирование уязвимостей. Образы следует быстро исправлять, заменяя слой, содержащий уязвимость, и перестраивая контейнер для использования актуальных фиксированных пакетов. Инструменты с открытым исходным кодом, такие как Clair, статически анализируют контейнеры на наличие известных уязвимостей.

Образы контейнеров следует создавать с использованием минимального количества пакетов ОС и зависимостей, чтобы в случае компрометации уменьшить поверхность атаки. Эксперты OWASP рекомендуют использовать альтернативные базовые образы (Distroless, Scratch), чтобы не только улучшить состояние безопасности, но и значительно уменьшить шум, создаваемый сканерами уязвимостей.

Также важно убедиться, что базовые образы обновлены до последних версий. Такие инструменты, как Docker Slim, помогают оптимизировать размер образа из соображений производительности и безопасности.

Атаки и прочие неожиданные последствия могут появиться на каждом шаге процесса DevOps. Чтобы обнаружить подделку самих артефактов, производители и потребители должны использовать пары криптографических ключей для подписи и проверки ПО на каждом этапе цепочки поставок. Для этого существуют open source проекты наподобие Cosign, который обеспечивает проверку образов.

Чтобы неутвержденные образы не попали в боевую среду, необходимо использовать средства управления доступом Kubernetes и контроля политик наподобие Open Policy Agent и Kyverno. Они будут отклонять образы рабочих нагрузок, которые не прошли проверку на наличие уязвимостей, не включают утвержденный SBOM, созданы из ненадежных реестров.

K03:2022 Чрезмерно свободные конфигурации доступа (RBAC)

Управление доступом на основе ролей (Role-based access control, RBAC) — это основной механизм авторизации в Kubernetes, отвечающий за права доступа к ресурсам. При правильной настройке это отличный механизм для обеспечения безопасности. Однако чрезмерная свобода быстро становится серьезной угрозой для кластера.

«Например, злоумышленник находит открытый веб-интерфейс, через который он получает shell работающего в кластере контейнера. Далее представим, что веб-интерфейс использует дефолтный токен служебной учетной записи в пространстве имен prd. Это позволяет злоумышленнику может выдать себя за этот сервис, чтобы вызвать API Kubernetes и выполнить действия с повышенными правами, такие как описать секреты в неймспейсе kube-system. Все это – потому что roleRef дает этой учетной записи права администратора во всем кластере».

Чтобы снизить риск злоупотребления конфигурациями RBAC, важно постоянно анализировать конфигурации. Основные рекомендации от экспертов OWASP:

• По возможности сокращайте прямой доступ пользователей к кластеру.

• Не используйте токены служебной учетной записи за пределами кластера.

• Избегайте автоматического подключения дефолтного служебного токена.

• Проверяйте RBAC сторонних компонентов

• Разворачивайте централизованные политики, чтобы блокировать рискованные разрешения RBAC.

• Используйте RoleBindings, чтобы ограничить разрешения отдельным неймспейсам.

• Следуйте официальным рекомендациям по использованию RBAC в документации Kubernetes.

K04:2022 Отсутствие централизованного применения политик

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

Как предотвратить

Командам требуется уверенность в том, что неправильно настроенные объекты Kubernetes будут заблокированы на старте. Обычно этим занимается Admission Controller в самом Kubernetes API. В этом API есть встроенная функциональность под названием Pod Security Standards, которая обеспечивает соблюдение политик в качестве части контроллера доступа Pod Security в самом кластере. Он предлагает три режима — привилегированный, базовый и ограниченный.

Другие open source проекты (Open Policy Agent Gatekeeper, Kyverno, Kubewarden) также позволяют применять политики и блокируют доступ к кластеру при некорректных настройках модулей.

K05:2022 Ошибки логирования и мониторинга

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

Чем грозит неправильное логирование в контексте Kubernetes:

• Неудачные попытки аутентификации, доступ к конфиденциальным ресурсам, ручное удаление или изменение ресурсов Kubernetes остаются незамеченными.

• Логи и трейсы запущенных рабочих нагрузок не проверяются на подозрительную активность.

• Не поступают уведомления о превышении пороговых значений – растет риск падения производительности и сбоев.

• И так далее.
  

Как предотвратить

Kubernetes умеет записывать для последующего анализа действия, предпринятые API. Журналы аудита помогают ответить на вопросы, касающиеся событий, происходящих на самом сервере API.

«Убедитесь, что журналы отслеживают аномальные или нежелательные вызовы API, особенно любые сбои авторизации, которые могут означать, что злоумышленник пытается злоупотребить украденными учетными данными».

События Kubernetes могут указывать на любые изменения состояния ресурсов и ошибки вроде превышения квоты ресурсов. Приложения внутри Kubernetes также создают полезные с точки зрения безопасности логи. Самый простой способ сохранения этих журналов — убедиться, что выходные данные записываются в стандартный поток вывода stdout и стандартный поток ошибок stderr.

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

K06:2022 Сломанные механизмы аутентификации

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

«Например, разработчик проверяет свой файл .kubeconfig с личного ноутбука, который содержит учетные данные для доступа к рабочим кластерам Kubernetes. При сканировании Github злоумышленник находит их и воспроизводит в целевом API, которое, к сожалению, доступно из интернета. Поскольку кластер настроен на аутентификацию с использованием сертификатов, утекший файл содержит всю информацию для успешной аутентификации в целевом кластере.

Как предотвратить

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

Сертификаты также сложнее настраивать, подписывать и распространять. Их можно использовать в экстренного механизма, но не для первичной аутентификации.

Никогда не используйте собственную аутентификацию – как с криптографией, не нужно создавать что-то новое без крайней необходимости. Используйте то, что поддерживается и широко применяется.

По возможности применяйте мультифакторную аутентификацию.

Не используйте токены сервисной учетной записи из-за пределов кластера. Они не могут быть привязаны к группам, и срок их действия никогда не истекает. Использование долгосрочного SA из-за пределов кластера создает значительные риски.

Все токены аутентификации должны быть настолько недолговечными, насколько это допустимо. Таким образом, если (когда) происходит утечка учетных данных, возможно, что их не получится использовать за отведенное время.

K07:2022 Отсутствуют элементы управления сегментацией сети

Сеть Kubernetes по умолчанию плоская. Это означает, что при отсутствии дополнительных элементов управления любая рабочая нагрузка может без ограничений взаимодействовать с другой. Злоумышленники могут использовать это, чтобы прощупать внутреннюю сети, перейти к другим работающим контейнерам или вызвать частные API.

Как предотвратить

Сегментация сети в Kubernetes минимизирует негативные последствия при компрометации контейнера и блокирует перемещения, позволяя при этом легитимному трафику маршрутизироваться, как ожидалось.

Один из способов по-настоящему обеспечить сетевую изоляцию в Kubernetes — использовать отдельные кластеры, когда это уместно. Это усложняет работу с тесно связанными микросервисами, но зато помогает разделить тенантов на основе риска.

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

Сетевой интерфейс контейнеров (Container Network Interface, CNI) — это спецификация с открытым исходным кодом, которая используется для настройки доступа к сетевым ресурсам. Этот механизм открывает или запрещает доступ к сети внутри Kubernetes. Такие решения, как Project Calico и Cilium, предлагают разные механизмы изоляции сетевого трафика.

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

K08:2022 Ошибки управления секретами

В Kubernetes секрет — это отдельный объект API в Kubernetes, используемый для хранения конфиденциальных данных вроде паролей или токенов. Необходимо контролировать, как хранятся учетные данные, ключи и прочие подобные элементы.

Как предотвратить

Шифруйте секреты в состоянии покоя. База данных etcd в целом содержит любую информацию, доступную через Kubernetes API, и может предоставить злоумышленнику значительную информацию о состоянии вашего кластера.

Всегда шифруйте свои резервные копии, используя хорошо проверенное решение. Рассмотрите вариант полного шифрования диска, где это возможно.

Kubernetes поддерживает шифрование в состоянии покоя — функция, представленная в версии 1.7 и в качестве бета-версии с 1.13. Это не позволит сторонам, получившим доступ к вашим резервным копиям etcd, просматривать содержимое секретов. Хотя эта функция в настоящее время находится в стадии бета-тестирования, она предлагает дополнительный уровень защиты, когда резервные копии не зашифрованы или злоумышленник получает доступ для чтения к etcd.

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

Конфигурация RBAC также должна быть заблокирована. Предоставьте минимальные привилегии всем сервисным учетным записям и конечным пользователям, особенно когда речь идет о доступе к секретам. Всегда проверяйте конфигурацию RBAC сторонних подключаемых модулей и установленного в кластере ПО, чтобы доступ к секретам Kubernetes не открывался без необходимости.

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

K09:2022 Неправильно настроенные компоненты кластера

Неправильная конфигурация основных компонентов Kubernetes может привести к полной компрометации кластера или даже к худшему. Несколько примеров критически важных модулей:

• kubelet: агент, который запускается на каждом ноде кластера и обеспечивает работоспособность контейнеров. При взаимодействии с Kubelets следует всегда выполнять проверки авторизации.

• etcd: высокодоступное хранилище ключей и значений, которое Kubernetes использует для централизованного хранения всех данных кластера.

• kube-apiserver: сервер API — это внешний интерфейс для контрольной плоскости Kubernetes.
  

Как предотвратить

Начать следует с регулярного сканирования и аудита CIS Benchmark. Это поможет выявить неправильные конфигурации компонентов. Подход Infrastructure-as-Code также может помочь централизовать настройку и исправление Kubernetes, предоставляя группам безопасности информацию о том, как создаются и обслуживаются кластеры.

K10:2022 Устаревшие и уязвимые компоненты Kubernetes

Кластер Kubernetes — это чрезвычайно сложная программная экосистема, которая может создавать проблемы, когда речь идет о традиционном управлении исправлениями и уязвимостями. Администраторы должны внимательно следить за базами данных, раскрытием и обновлениями CVE, иметь план управления исправлениями.

Как предотвратить

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

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

Сведите к минимуму сторонние зависимости. Все стороннее ПО должно проходить аудит перед развертыванием: ищите чрезмерно разрешающие RBAC, низкоуровневый доступ к ядру, записи о ранее обнаруженных уязвимостях.

Что говорят эксперты

Виктор Чащин

Операционный директор «МУЛЬТИФАКТОР»

Сам рейтинг составлен достаточно хорошо и правильно.

Для российских разработчиков сегодня больше всего головной боли доставляют две проблемы: K02:2022 Supply Chain Vulnerabilities и K10:2022 Outdated and Vulnerable Kubernetes Components. Это обусловлено тем, что где-то в сторонних компонентах могут появиться закладки, связанные с ситуацией в геополитике. Поэтому многие стараются без лишней необходимости не обновляться.

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

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

Дмитрий Евдокимов

Founder, CTO в Luntry

Как и в любом рейтинге (ничем не подкрепленным) любая позиция в нем – дискуссионная. Так что на порядок, в котором расставлены риски, я бы не обращал внимания – хорошо смотреть на картину в целом.

Хотя позиция K01:2022 Insecure Workload Configurations тут явно непоколебима – потому что это касается любого YAML. При этом, на мой взгляд, первая позиция неразрывно связанна с K04:2022 Lack of Centralized Policy Enforcement, ведь этот риск решается (как вариант) с помощью Policy Enforcement (PolicyEngine). Нужно ли было это выносить в отдельный пункт, не знаю. Притом, что упоминание PolicyEngine есть почти в каждом из пунктов.

Удивило полное отсутствие упоминаний Runtime Security. Даже вскользь этого нет в K05:2022 Inadequate Logging and Monitoring... Хотя почти во всех примерах приводят ситуации, когда атакующий что-то выполняет в контейнерах. Таким образом авторы как-то взяли и выкинули всеми любимый кейс с запуском майнеров.

Также на мой взгляд сейчас остро стоит вопрос с Multitenancy в Kubernetes и в качестве одного из рисков, когда один тенант нарушает изоляцию другого. Это куда распространеннее, чем тот же K06:2022 Broken Authentication Mechanisms.

Я бы K04:2022 и K06:2022 заменил бы на Runtime Security (точнее, Malware activity) и Multitenancy (точнее, Isolation missing).

Все это можно встретить в любой Kubernetes-инфраструктуре как в России, так и на Западе. Реальные случаи также есть, но компании, естественно, не горят желанием их афишировать.

Появление рейтинга от такой уважаемой организации, как OWASP, должно еще раз напомнить заняться безопасностью Kubernetes.