Поделиться через

Рекомендации по безопасности и обновлениям кластера в службах Azure Kubernetes (AKS)

  • Статья

При управлении кластерами в Azure Kubernetes Service (AKS) безопасность рабочих нагрузок и данных является ключевым фактором. Особенно важно обеспечить безопасный доступ к ресурсам и рабочим нагрузкам при запуске мультитенантных кластеров с использованием логической изоляции. Минимизируйте риск атаки, устанавливая новейшие обновления безопасности для Kubernetes и ОС узла.

Эта статья посвящается вопросам, связанным с безопасностью кластера AKS. Узнайте следующие темы:

  • Используйте идентификатор Microsoft Entra и управление доступом на основе ролей Kubernetes (Kubernetes RBAC) для защиты доступа к серверу API.
  • защищать доступ контейнера к ресурсам узла;
  • обновлять кластер AKS до последней версии Kubernetes;
  • поддерживать актуальность узлов и автоматически применять исправления системы безопасности.

Вы также можете изучить рекомендации по управлению образами контейнеров и обеспечению безопасности pod.

Включение защиты от угроз

Рекомендации по рекомендациям

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

Безопасный доступ к серверу API и узлам кластера

Рекомендации по рекомендациям

Одним из наиболее важных способов защиты кластера является обеспечение безопасности доступа к серверу API Kubernetes. Чтобы управлять доступом к серверу API, интегрируйте Kubernetes RBAC с идентификатором Microsoft Entra. Эти элементы управления позволяют защитить AKS так же, как и доступ к подпискам Azure.

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

Идентификатор Microsoft Entra id предоставляет решение для управления удостоверениями, готовое для предприятия, которое интегрируется с кластерами AKS. Поскольку Kubernetes не предоставляет решения для управления идентификацией, вам может быть сложно детально ограничить доступ к серверу API. С помощью интегрированных кластеров Microsoft Entra в AKS вы используете существующие учетные записи пользователей и групп для проверки подлинности пользователей на сервере API.

Интеграция Microsoft Entra для кластеров AKS

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

Для предоставления доступа к файлам и папкам рекомендуется использовать группы, а не отдельных пользователей. Например, используйте членство в группе идентификаторов Microsoft Entra для привязки пользователей к ролям Kubernetes, а не отдельным пользователям. При изменении членства в группах пользователей их права доступа в кластере AKS будут меняться соответственно.

С другой стороны, вы, например, привязали отдельного пользователя непосредственно к роли, а затем у него поменялись должностные обязанности. Хотя членство в группах Microsoft Entra обновляется, их разрешения в кластере AKS не будут. В таком случае пользователю предоставляется больше разрешений, чем ему требуется.

Дополнительные сведения об интеграции Microsoft Entra, Kubernetes RBAC и Azure RBAC см. в рекомендациях по проверке подлинности и авторизации в AKS.

Ограничение доступа к API метаданных экземпляра

Рекомендации по рекомендациям

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

Примечание.

Чтобы реализовать политику сети, включите атрибут --network-policy azure при создании кластера AKS. Чтобы создать кластер, используйте следующую команду: az aks create -g myResourceGroup -n myManagedCluster --network-plugin azure --network-policy azure --generate-ssh-keys

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-instance-metadata
spec:
  podSelector:
    matchLabels: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 10.10.0.0/0#example
        except:
        - 169.254.169.254/32

Обеспечение безопасного доступа контейнера к ресурсам

Рекомендации по рекомендациям

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

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

Для еще более детального управления действиями контейнера можно также использовать встроенные функции безопасности Linux, такие как AppArmor и seccomp. Дополнительные сведения см. в руководстве по защите доступа контейнера к ресурсам.

Регулярное обновление до последней версии Kubernetes

Рекомендации по рекомендациям

Для своевременного получения новых функций и исправлений ошибок регулярно обновляйте версию Kubernetes в своем кластере AKS.

Kubernetes выпускает новые функции быстрее, чем традиционные платформы инфраструктуры. Обновления Kubernetes включают:

  • Новые возможности
  • исправления ошибок и проблем безопасности.

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

AKS поддерживает три младшие версии Kubernetes. Когда выпускается новая дополнительная версия с исправлениями, самая старая поддерживаемая дополнительная версия и выпуски исправлений удаляются. Незначительные изменения в Kubernetes происходят периодически. Чтобы остаться в рамках поддержки, убедитесь, что у вас настроен процесс управления для проверки наличия необходимых обновлений. Дополнительные сведения см. в статье Поддерживаемые версии Kubernetes в Службе Azure Kubernetes (AKS).

Чтобы проверить версии, доступные для кластера, используйте команду az aks get-upgrades, как показано в следующем примере.

az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster --output table

Затем вы можете обновить кластер AKS с помощью команды az aks upgrade. Процесс обновления безопасно выполняет следующие операции.

  • Блокирует и останавливает по одному узлу за раз.
  • Планирует модули pod на оставшихся узлах.
  • Развертывает новый узел с последней версией ОС и Kubernetes.

Внимание

Тестируйте новые дополнительные версии в тестовой среде разработки и убедитесь, что ваша рабочая нагрузка остается работоспособной с новой версией Kubernetes.

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

az aks upgrade --resource-group myResourceGroup --name myAKSCluster --kubernetes-version KUBERNETES_VERSION

Дополнительные сведения об обновлении в AKS см. в статьях Поддерживаемые версии Kubernetes в Службе Azure Kubernetes (AKS) и Обновление кластера службы Azure Kubernetes (AKS).

Обработка обновлений узлов Linux

Каждый вечер узлы Linux AKS получают исправления проблем безопасности по каналам распространения обновлений. Это поведение настраивается автоматически, так как узлы развернуты в кластере AKS. Чтобы свести к минимуму нарушения и возможные последствия для рабочих нагрузок, узлы не перезагружается автоматически, если исправление или обновление ядра этого требуют. Дополнительные сведения о том, как обрабатывать перезагрузки узла, см. в статье Применение обновлений безопасности и ядра для узлов в Службе Azure Kubernetes (AKS).

Обновления образов узлов

Автоматическое обновление применяет обновления к ОС узлов Linux, но образ, используемый для создания узлов для кластера, не изменяется. Если в кластер добавляется новый узел Linux, для его создания используется исходный образ. Этот новый узел получит все обновления безопасности и ядра, доступные в ходе автоматической проверки (запускается каждую ночь), но обновления не будут установлены, пока не будут выполнены все проверки и перезапуск. С помощью обновления образа узла можно проверить наличие образов узла, используемых кластером, и обновить их. Дополнительные сведения об обновлении образа узла см. в статье об обновлении образа узла Служба Azure Kubernetes (AKS).

Обработка обновления узла Windows Server

При использовании узлов Windows Server регулярно выполняйте операции обновления образа узла для безопасной защиты pods и развертывания обновленных узлов.