0 842 ru

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

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

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

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

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

Kubernetes Architecture

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

Kubernetes Architecture

Если для вас эта картинка новая, почитайте статью Что такое 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), сетью и хранилищем.

Self managed Kubernetes
Self-managed Kubernetes on cloud

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

Public cloud managed Kubernetes service
Public cloud-managed Kubernetes service

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

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

AWS shared responsibility model

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

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

API Server

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.

Google GKE

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

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

Google GKE

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

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

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

Microsoft AKS

Amazon EKS

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

Google GKE

Виртуальная машина (узел), ОС и контейнер 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

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

Общедоступные облачные приложения 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.

Kubernetes Ingress

Node Port

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

Node Port

Load Balancer

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

Load Balancer

Источник

Comments:

Please log in to be able add comments.