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

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

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

В этой статье описывается, как защитить кластер AKS. Вы узнаете, как:

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

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

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

Руководство по передовым практикам

Вы можете включить 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 в конечную точку метаданных.

Note

Чтобы реализовать политику сети, включите атрибут --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

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

Руководство по передовым практикам

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

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

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

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

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

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

Руководство по передовым практикам

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

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

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

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

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

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

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

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

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

Important

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

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

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

Дополнительные сведения об обновлениях в AKS см. в статье "Поддерживаемые версии Kubernetes" в AKS и обновление кластера AKS.

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

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

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

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

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

Для узлов Windows Server регулярно выполняйте операцию обновления образа узла для безопасного кордона и очистки модулей pod и развертывания обновленных узлов.

  • Last updated on