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

В этой статье поговорим о проблемах в безопасности K8s и как их избегать.

Tesla была взломана, потому что их админ консоль k8s не была защищена паролем. В другом случае Capital One оставила свои настройки AWS firewall слишком слабыми, и было раскрыто 30 ГБ данных (затронутых 106 миллионами клиентов). Помимо реализации самого Kubernetes, самым важным фактором является безопасность.

~60% проблем безопасности Kubernetes связаны с неправильной настройкой - информация с статьи Состояние безопасности Kubernetes в 2021 г.

В большей степени, чем в любой другой технологической области, общедоступные клауды всегда было подвержены "невидимым уязвимостям", особенно за счет "Shadow IT" и простоты доступных сервисов для использования командами разработчиков и конечными пользователями.

Kubernetes Architecture

На высоком уровне архитектура k8s выглядит следующим образом:

Если для вас эта картинка новая, почитайте статью Что такое Pods, Nodes, Containers и Clusters в Kubernetes.

Public Cloud Kubernetes vs Kubernetes Distributions

Kubernetes можно использовать: в общедоступном облаке, в приватном центре обработки данных, на периферии и тд. Однако при использовании Kubernetes в общедоступном облаке необходимо различать. У нас есть два варианта использования Kubernetes: Cloud managed или self managed Kubernetes.

С self managed Kubernetes мы юзаем проект Kubernetes с открытым исходным кодом в качестве стартового или взять сторонний дистрибутив Kubernetes, такой, как Red Hat OpenShift или VMWare Tanzu, и развернуть его в облаке. В качестве альтернативы мы можем использовать собственные сервисы Kubernetes в облаке.

В чем разница?

Opensource, OpenShift и Tanzu дают вам полный контроль над созданием кластеров Kubernetes и управлением ими. Вы сами можете устанавливать, управлять и поддерживать все компоненты вашей платформы и инфраструктуры, из которых состоит Kubernetes. Вы отвечаете за управление вычислительными ресурсами (серверами), control plane (основными службами, необходимыми для запуска кластеров Kubernetes), сетью и хранилищем.

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

Security и compliance считаются общими обязанностями при использовании клауд сервисов, таких как AKS/EKS/GKE. Облачный провайдер отвечает за безопасность «облака», тогда как вы отвечаете за безопасность «внутри» облака.

Например, в AWS модель общей ответственности выглядит так:

Основные проблемные области безопасности паблик k8s клауда:

API Server

API сервер предоставляет entry point для управления кластером Kubernetes .API server endpoint защищен с помощью паблик облака IAM, а также Kubernetes RBAC — однако он открыт для Интернета, если не настроен правильно и, следовательно, представляет собой вектор атаки.

• Защитите API Server endpoint с помощью приватных кластеров или с помощью white/black lists IP
• Защитите доступ к API server с помощью эффективных средств управления IAM.
• Определите эффективное разделение обязанностей в кластере элементов управления RBAC.

Microsoft AKS

Защитите API сервер с помощью элементов управления Azure AD IAM.

• Используйте ограничения белого списка IP-адресов.
• Рекомендации по безопасности кластера и обновлениям

Google GKE

• Защитите API сервер с помощью приватных кластеров.
• Отключение общедоступных эндпоинтов.
• Используйте  whitelist IP-адресов.
• Усильте безопасность вашего кластера

Amazon EKS

• Защитите API сервер с помощью приватных кластеров.
• Отключение общедоступных эндпоинтов.
• Cluster endpoint access control

ETCD

etcd — это примитивное, но при этом высоконадёжное распределённое хранилище для пар ключ-значение. «Примитивное» не значит, что тупое. Это просто значит что etcd фокусируется только на хранении и связанными с этим задачами. Ну и «высоконадёжный» и «распределённый» подразумевает, что если даже одна из кластера машин с etcd упадёт, то данными и кластером всё будет в порядке. По сравнению с тем же Consul фич тут будет поменьше, но в реальных задачах для того, чтобы забить гвоздь, отбойный молоток и не нужен.

AKS, EKS и GKE обеспечивают шифрование в ETCD для защиты хранимой информации, однако "секреты" Kubernetes по умолчанию имеют только кодировку base64 (plaintext).

• Kubernetes Secrets доступны для ВСЕХ pods в одном namespace.
• По умолчанию secret будет смонтирован в pod в виде plaintext (в кодировке base 64).
• Защитите конфиденциальную информацию, зашифровав secret и заменив сертификаты
• Используйте общедоступные облачные службы шифрования (например, AWS KMS, Azure Key Vault).
• Используйте сторонний инструмент управления secret'ами(например, Hashicorp Vault).

Google GKE

• Secrets зашифрованы (по умолчанию).
• Рекомендуется использовать стороннее хранилище или шифрование секретов на уровне приложения.
• Шифровать секреты на application layer

Microsoft AKS

• Secrets зашифрованы (по умолчанию).
• Рекомендация - Azure Key Vault.
• Best practices for pod security

Amazon EKS

• Secrets зашифрованы (в зависимости от хранилища ETCD, требуется настройка)
• Настраиваемый аудит секретов (когда секреты использовались для просмотра в облаке).
• Data encryption and secrets management

Control plane network/worker network

Как у потребителя у вас нет доступа к сети control plane, которая управляется и защищается облачным провайдером.

При защите кластеров необходимо учитывать точку доступа между двумя сетями. У провайдеров есть разные механизмы устранения пробелов в безопасности:

Microsoft AKS

• AKS предоставляет возможность общедоступным и приватных endpoint'ов для worker нод взаимодействовать с control plane. AKS также предоставляет white/black listing  при использовании публичных эндпоинтов  или частных интерфейсов для поддержания связи в VPN.
• Используйте Network Security Groups
• Security concepts for applications and clusters

Amazon EKS

• Использует группы безопасности AWS VPC для управления трафиком между Kubernetes control plane и воркерами клауд нод.
• Сетевая безопасность

Google GKE

• Добавьте Authorized Networks и  используйте IP whitelisting.

Сетевая политика для pod network

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

Эти угрозы должны быть решены с помощью конструкций сетевой безопасности, существующих в кластере. Сетевые политики — это ресурсы Kubernetes, которые контролируют трафик между pod\ами и/или сетевыми эндпоинтами.

Microsoft AKS

• Рекомендуется использовать сетевого провайдера Calico для включения сетевой политики.
• Сетевая безопасность

Amazon EKS

• Рекомендуется использовать сетевого провайдера Calico для включения сетевой политики.
• Network security

Google GKE

• Сетевая политика автоматически включается при использовании GKE Dataplane V2.
• Ограничение трафика между подами с помощью сетевой политики

Виртуальная машина (узел), ОС и контейнер runtime

Приложения в кластере Kubernetes запускаются в контейнерах на виртуальном сервере, называемом 'node'. node имеет хост-операционную систему и среду выполнения контейнера (которая запускает контейнер). Оба этих компонента требуют внимания со стороны вашей системы безопасности Kubernetes, поскольку брешь в хосте поставит под угрозу все, что вы там используете, включая Kubernetes и рабочие нагрузки внутри.

Public cloud провайдеры сервисов проделывают большую работу по устранению нарушений безопасности на этом уровне, в том числе проводят тесты CIS для операционной системы хоста, а также регулярно устанавливают исправления и обновления. Однако вы, как конечный пользователь, по-прежнему несете ответственность за внедрение облачных исправлений и обновлений.

Microsoft AKS

• Использует оптимизированную Ubuntu для Linux или Windows 2019 (managed nodes).
• Containerd по умолчанию, Docker как вариант.
• Безопасность узла

Amazon EKS

• Managed или self-managed nodы  имеют разные секрьюрити ишью  — читайте документацию.
• Containerd по умолчанию от EKS 1.23.
• EKS Nodes

Google GKE

• Используйте Shielded GKE Nodes.
• Containerd по умолчанию.
• Container node choices

Доступ приложений в кластер

Общедоступные облачные приложения Kubernetes, которым необходимо предоставлять общедоступные endpoint'ы, обычно могут быть реализованы 3мя способами:

• Ingress
• Node Port
• Load Balancer

Kubernetes Ingress

Kubernetes ingress законфигурежен двумя объектами: ingress controller и ingress object.

ingress controller — это часть программного обеспечения, которое обеспечивает обратный прокси-сервер, настраиваемую маршрутизацию трафика и терминацию TLS для сервисов Kubernetes. Входящие ресурсы Kubernetes используются для настройки входящих правил и маршрутов для отдельных сервисов Kubernetes. С помощью ingress controllerа и ingress рулов один IP-адрес можно использовать для маршрутизации трафика к нескольким сервисами в кластере Kubernetes.

Node Port

Создает маппинг портов на базовом узле, что позволяет напрямую обращаться к приложению с помощью IP-адреса и порта nod'ы.

Load Balancer

Использует Load Balancer с внешним IP-адресом, который подключается к запрошенным подам. Чтобы трафик клиентов мог достигать приложения, на нужных портах создаются правила в load balancer.

Источник