Если вы считали, что стать жертвой вымогательства или взлома вашей рабочей станции — это кошмар, то представьте себе потенциальную угрозу в случае захвата вашего кластера Kubernetes (k8s). Это может стать настоящей катастрофой, умноженной на миллион.
Kubernetes набирает огромную популярность среди предприятий в последние годы благодаря оркестрации и управлении контейнеризированными приложениями. Он объединяет ваш исходный код, учетные записи в облаке и секреты в единый хаб. Однако в неправильных руках доступ к кластеру k8s компании может оказаться не просто вредным, но и потенциально катастрофическим.
В ходе исследования лаборaтория Aqua Nautilus обнаружила кластеры Kubernetes, принадлежащие более чем 350 организациям, проектам с открытым исходным кодом, которые были общедоступными и в большей части не защищены. По крайней мере, 60% из них были скомпрометированы и использовались для развертывания вредоносных программ и bot-net.
Большинство этих кластеров были связаны с небольшими и средними организациями, а также с заметной частью огромных конгломератов, некоторые из которых входят в список Fortune 500. Организации, которые выявила лаборaтория Aqua Nautilus, представляют различные секторы, включая финансовый, аэрокосмический, автомобильный, промышленный, область безопасности и многие другие.
Aqua Nautilus отмечает, что в ходе исследования были обнаружен две основные конфигурационные ошибки настроек Kubernetes. Самой распространенной из них является предоставление анонимного доступа с привилегиями. Второй проблемой, выделяющейся среди остальных, является запуск kubectl proxy с некоторыми параметрами, что приводит к непреднамеренному разглашению кластера в сети Интернет.
Ошибка конфигурации 1 – анонимный пользователь с высокими привилегиями
Во многих случаях неаутентифицированные запросы к кластеру по умолчанию разрешены. Это означает, что любой может отправлять запросы и понимать, что происходит общение с кластером k8s, но это не означает, что любой может получить доступ к кластеру. Это верно как в среде native k8s, так и на некоторых управляемых кластерах некоторых облачных провайдеров.
По умолчанию анонимному пользователю не предоставляются никакие права. Однако бывают случаи, когда администраторы K8 связывают роль анонимного пользователя с другими ролями, часто с административными ролями, что представляет опасность для их кластеров. Смешение таких конфигурационных ошибок может позволить злоумышленникам получить несанкционированный доступ к кластеру Kubernetes, что потенциально может поставить под угрозу все работающие на нем приложения, а также другие среды.
Это означает, что ошибка только в одном YAML-файле отделяет организацию от катастрофы. Простая конфигурационная ошибка может привести к тому, что любой злоумышленник может получить доступ к Вашему кластеру K8. Пример присвоения анонимному пользователю прав администратора приведен на картинке ниже.
Ошибка конфигурации 2 – открытый прокси
Еще одной распространенной конфигурационной ошибкой, которая была широко документирована в исследовании Aqua Nautilus, является ошибка конфигурации в команде ‘kubectl proxy’. Как показано ниже, при выполнении ‘kubectl proxy’ вы перенаправляете авторизованные и аутентифицированные запросы на сервер API.
Если вы выполните ту же команду с следующими флагами ‘—address=0.0.0.0 —accept-hosts .*‘, то прокси на вашей рабочей станции теперь будет прослушивать и перенаправлять авторизованные и аутентифицированные запросы к серверу API с любого хоста, который имеет доступ HTTP к вашей рабочей станции. Обратите внимание, что привилегии будут такими же, как у пользователя, который запустил команду ‘kubectl proxy’.
Имейте в виду, что некоторые публикации поддерживают использование команды ‘kubectl proxy’ практикующими для различных целей. Например, различные учебные материалы, посвященные установке панели управления Kubernetes, советуют пользователям запускать команду прокси и не предупреждают явно о возможных последствиях, как можно видеть по этим ссылкам:
https://zjor.medium.com/how-to-deploy-a-dashboard-to-your-kubernetes-cluster-96c926793b80%C2%A0
https://sysaix.com/installing-kubernetes-dashboard-on-kubernetes-cluster%C2%A0
https://janrock.medium.com/kubernetes-dashboard-token-issue-solved-6df37893bef6%C2%A0
Практические советы по повышению безопасности Kubernetes
Обучение сотрудников: Организации должны инвестировать в обучение своего персонала относительно потенциальных рисков, лучших практик и правильных конфигураций. Это поможет уменьшить человеческие ошибки, приводящие к таким конфигурационным ошибкам.
Защита kubectl proxy: Убедитесь, что kubectl proxy не имеет доступа в Интернете. Он должен быть настроен в безопасной сетевой среде и доступен только аутентифицированным и авторизованным пользователям.
Кроме того, вы можете использовать платформу Aqua для дополнительных мер смягчения:
Управление доступом на основе ролей (RBAC): RBAC — это встроенная функция Kubernetes, которая может ограничивать, кто имеет доступ к API-серверу Kubernetes и какие у них есть разрешения. Избегайте присвоения административной роли анонимному пользователю. Убедитесь, что каждому пользователю назначены соответствующие разрешения и строго соблюдайте принцип минимальных привилегий.
Внедрение политик admission control: Контроллеры Kubernetes могут перехватывать запросы к серверу API Kubernetes перед их сохранением, позволяя вам определить и соблюдать политики, усиливающие безопасность. Aqua рекомендуем использовать контроль приема, который предотвращает привязку какой-либо роли к анонимной роли, что укрепит безопасность ваших кластеров Kubernetes. Платформа Aqua позволяет устанавливать такие политики для более эффективной защиты ваших кластеров.
Регулярный аудит: Внедрение регулярного аудита ваших кластеров Kubernetes. Это позволяет отслеживать каждое действие, выполненное в кластере, идентифицировать аномалии и быстро принимать меры по их устранению. Сканер Aqua для облачных сред, включая контейнеры, репозитории кода, виртуальные машины, кластеры Kubernetes, обнаруживать уязвимости и конфигурационные ошибки, конфиденциальную информацию и секреты. Вы можете сканировать ваши кластеры Kubernetes на предмет избыточных разрешений RBAC и разглашенных нагрузок, как рекомендовалось ранее.
Кроме того, вы можете сканировать вашу среду выполнения, чтобы получить доступ к сотням событий, которые помогут вам понять, как ваши системы и приложения ведут себя. Aqua может отслеживать активность на низком уровне системы и обнаруживать аномалии на более высоком уровне безопасности. Используйте Aqua для мониторинга ваших кластеров Kubernetes на предмет подозрительных действий.
Автоматизированный инструмент для тестирования Kube-hunter может использоваться для поиска уязвимостей в безопасности вашего кластера Kubernetes. Регулярно планируйте сканирование Kube-hunter и применяйте корректирующие меры на основе результатов.
Как показано на скриншоте ниже, платформа Aqua позволяет выполнять Kube Hunter для поиска конфигурационных ошибок, которые могут поставить кластер под угрозу. Например, на приведенном ниже скриншоте сервер API возвращает информацию о состоянии кластера анонимному пользователю.
Применяя эти стратегии смягчения, организации могут значительно улучшить безопасность своих кластеров Kubernetes. Важно помнить, что безопасность Kubernetes — это не задача однократной проверки, а непрерывный процесс обучения, адаптации и улучшения с учетом развития технологий и угроз.
Источник: https://blog.aquasec.com/kubernetes-exposed-one-yaml-away-from-disaster