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

Статья
02/16/2024

Если вы развертываете и обслуживаете кластеры в службе Azure Kubernetes (AKS), необходимо реализовать способы управления доступом к ресурсам и службам. Без этих элементов управления:

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

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

Проверка подлинности пользователей кластера AKS с помощью идентификатора Microsoft Entra.
Управление доступом к ресурсам с помощью управления доступом на основе ролей Kubernetes (Kubernetes RBAC).
Использование Azure RBAC для детализированного управления доступом к ресурсу AKS, API Kubernetes в большом масштабе, а также к kubeconfig.
Используйте удостоверение рабочей нагрузки для доступа к ресурсам Azure из модулей pod.

Предупреждение

Управляемое модулем открытый код Microsoft Entra pod (предварительная версия) в Служба Azure Kubernetes устарело по состоянию на 10.24.2022.

Если в кластере AKS включено управляемое удостоверение Microsoft Entra pod или планируется реализовать его, рекомендуем ознакомиться со статьей обзора удостоверений рабочей нагрузки, чтобы понять наши рекомендации и параметры настройки кластера для использования Идентификация рабочей нагрузки Microsoft Entra (предварительная версия). Этот метод проверки подлинности заменяет управляемое pod удостоверение (предварительная версия), которое интегрируется с собственными возможностями Kubernetes для федерации с любыми внешними поставщиками удостоверений.

Использование идентификатора Microsoft Entra

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

Развертывание кластеров AKS с помощью интеграции Microsoft Entra. Использование идентификатора Microsoft Entra обеспечивает централизованный уровень управления удостоверениями. Любые изменения в статусе учетной записи пользователя или группы автоматически обновляются при доступе к кластеру AKS. Ограничьте пользователей и группы минимальным числом разрешений с помощью ролей, кластерных ролей или привязок.

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

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

Cluster-level authentication for Microsoft Entra integration with AKS

Разработчик выполняет проверку подлинности с помощью идентификатора Microsoft Entra.
Конечная точка выдачи маркера Microsoft Entra выдает маркер доступа.
Разработчик выполняет действие с помощью маркера Microsoft Entra, например kubectl create pod.
Kubernetes проверяет маркер с помощью идентификатора Microsoft Entra и получает членство в группах разработчика.
Применяются правила Kubernetes RBAC и кластерные политики.
Запрос разработчика успешно выполнен на основе предыдущей проверки членства в группе Microsoft Entra и RBAC и политик Kubernetes.

Чтобы создать кластер AKS, использующий идентификатор Microsoft Entra, см. статью "Интеграция идентификатора Microsoft Entra с AKS".

Использование управления доступом Kubernetes на основе ролей (Kubernetes RBAC)

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

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

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

Например, вы создаете роль с полным доступом к ресурсам в пространстве имен с именем finance-app, как показано в следующем примере манифеста YAML:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role
  namespace: finance-app
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]

Затем вы создадите RoleBinding и привязываете пользователя developer1@contoso.com Microsoft Entra к нему, как показано в следующем манифесте YAML:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role-binding
  namespace: finance-app
subjects:
- kind: User
  name: developer1@contoso.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: finance-app-full-access-role
  apiGroup: rbac.authorization.k8s.io

Когда developer1@contoso.com проходит аутентификацию в кластере AKS, он получает полный доступ к ресурсам в пространстве имен finance-app. Таким образом, вы логически разделяете и контролируете доступ к ресурсам. Используйте RBAC Kubernetes с интеграцией идентификатора Microsoft Entra.

Сведения об использовании групп Microsoft Entra для управления доступом к ресурсам Kubernetes с помощью Kubernetes RBAC см. в статье "Управление доступом к ресурсам кластера с помощью управления доступом на основе ролей" и удостоверений Microsoft Entra в AKS.

Использование Azure RBAC

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

Используйте Azure RBAC, чтобы определить минимально необходимые разрешения пользователей и групп для ресурсов AKS в одной или нескольких подписках.

Для полноценной работы кластера AKS требуется два уровня доступа:

Доступ к ресурсу AKS в подписке Azure.

Этот уровень доступа позволяет выполнять следующие задачи:
- управлять масштабированием и обновлением кластера с помощью API-интерфейсов AKS;
- извлекатьkubeconfig.
Сведения об управлении доступом к ресурсу AKS и kubeconfigфайлу конфигурации кластера см. в разделе "Ограничение доступа к файлу конфигурации кластера".
Доступ к API Kubernetes.

Этот уровень доступа управляется:
- Kubernetes RBAC (традиционный способ).
- Или с помощью интеграции Azure RBAC с AKS для авторизации Kubernetes.
Сведения о том, как детально предоставить разрешения API Kubernetes с помощью Azure RBAC, см. в статье "Использование Azure RBAC для авторизации Kubernetes".

Использование удостоверений, управляемых pod

Предупреждение

Не используйте фиксированные учетные данные в контейнерах pod или образах контейнеров из-за высокого риска раскрытия или применения не по назначению. Вместо этого используйте удостоверения pod для автоматического запроса доступа с помощью идентификатора Microsoft Entra.

Для доступа к другим ресурсам Azure, таким как Azure Cosmos DB, Key Vault или хранилище BLOB-объектов, pod требует учетных данных проверки подлинности. Вы можете определить учетные данные проверки подлинности с помощью образа контейнера или внедрить их в качестве секрета Kubernetes. В любом случае потребуется вручную создать и назначить их. Обычно эти учетные данные используются в разных контейнерах pod и не сменяются регулярно.

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

Управляемое удостоверение microsoft Entra pod (предварительная версия) поддерживает два режима работы:

Стандартный режим: в этом режиме развертываются следующие 2 компонента в кластере AKS:
- Контроллер управляемых удостоверений (MIC): контроллер Kubernetes, который следит за изменениями в pod, AzureIdentity и AzureIdentityBinding, через сервер API в Kubernetes. Когда контроллер обнаруживает соответствующее изменение, MIC за необходимости добавляет или удаляет AzureAssignedIdentity. В частности, при планировании pod MIC назначает управляемое удостоверение в Azure базовому масштабируемому набору виртуальных машин, используемому пулом узлов на этапе создания. При удалении всех pod, использующих удостоверение, удостоверение удаляется из масштабируемого набора виртуальных машин пула узлов, если другие модули не используют одно и то же управляемое удостоверение. Контроллер управляемых удостоверений выполняет аналогичные действия при создании или удалении AzureIdentity или AzureIdentityBinding.
- Node Managed Identity: это pod, который работает как DaemonSet на каждом узле кластера AKS. NMI перехватывает запросы маркера безопасности к службе метаданных экземпляра Azure на каждом узле. Он перенаправляет запросы на себя и проверяет, имеет ли модуль pod доступ к удостоверению, для него запрашивается маркер и извлекает маркер из клиента Microsoft Entra от имени приложения.
Управляемый режим: в этом режиме существует только NMI. Идентификатор следует назначать вручную. Им должен управлять пользователь. Дополнительные сведения см. в статье Удостоверение pod в управляемом режиме. В этом режиме при использовании команды az aks pod-identity add to add a pod identity to add a pod identity to a Служба Azure Kubernetes (AKS) cluster, он создает AzureIdentity и AzureIdentityBinding в пространстве имен, указанном параметром, а поставщик ресурсов AKS назначает управляемое удостоверение, указанное --namespace--identity-resource-id параметром для масштабируемого набора виртуальных машин каждого пула узлов в кластере AKS.

Примечание.

Если вы решили установить управляемое модулем microsoft Entra pod с помощью надстройки кластера AKS, программа установки использует managed режим.

Режим managed имеет следующие преимущества перед режимом standard:

Назначение удостоверений в масштабируемом наборе виртуальных машин пула узлов может занять до 40–60. При использовании cronjobs или приложений, требующих доступа к удостоверению и не допускающих задержку назначения, рекомендуется использовать managed режим, так как удостоверение предварительно назначено масштабируемой группе виртуальных машин пула узлов. Либо вручную, либо с помощью команды добавления az aks pod-identity.
В standard режиме MIC требуются разрешения на запись в масштабируемом наборе виртуальных машин, используемом кластером AKS и Managed Identity Operator разрешением на управляемые удостоверения, назначенные пользователем. При выполнении managed modeв , так как не существует MIC, назначения ролей не требуются.

Вместо ручного определения учетных данных для модулей pod управляемые pod удостоверения запрашивают маркер доступа в режиме реального времени, используя его для доступа только к назначенным ресурсам. В AKS есть два компонента, которые обрабатывают операции, позволяющие объектам pod использовать управляемые удостоверения:

Сервер Node Management Identity (NMI) — это контейнеры pod, которые работают как DaemonSet на каждом узле кластера AKS. Сервер NMI ожидает передачи запросов pod к службам Azure.
Поставщик ресурсов Azure запрашивает сервер API Kubernetes и проверяет сопоставление удостоверений Azure, соответствующее модулю pod.

При запросе маркера безопасности из идентификатора Microsoft Entra для доступа к ресурсу Azure правила сети перенаправляют трафик на сервер NMI.

Сервер NMI выполняет следующие действия:
- Определяет модули pod, запрашивающие доступ к ресурсам Azure на основе удаленного адреса.
- выполняет запрос к поставщику ресурсов Azure.
Поставщик ресурсов Azure проверяет сопоставления удостоверений Azure в кластере AKS.
Сервер NMI запрашивает маркер доступа из идентификатора Microsoft Entra на основе сопоставления удостоверений pod.
Идентификатор Microsoft Entra предоставляет доступ к серверу NMI, который возвращается в pod.
- Этот маркер доступа можно использовать модулем pod, чтобы затем запросить доступ к ресурсам в Azure.

В следующем примере разработчик создает объект pod, использующий управляемое удостоверение для запроса доступа к Базе данных SQL Azure:

Pod identities allow a pod to automatically request access to other resources.

Оператор кластера создает учетную запись службы для сопоставления удостоверений при запросе доступа pod к ресурсам.
Сервер NMI развертывается для ретрансляции всех запросов pod, а также поставщика ресурсов Azure для маркеров доступа к идентификатору Microsoft Entra.
Разработчик развертывает контейнеры pod с управляемым удостоверением, которые запрашивают маркер доступа через сервер NMI.
Маркер возвращается объектам pod и используется для доступа к Базе данных SQL Azure.

Сведения об использовании удостоверений, управляемых pod pod, см. в разделе "Использование управляемых модулем pod Microsoft Entra" удостоверений в Служба Azure Kubernetes (предварительная версия).

Следующие шаги

В этой статье с рекомендациями мы рассказали об аутентификации и авторизации для кластера и ресурсов. Чтобы реализовать некоторые из этих рекомендаций, ознакомьтесь со следующими статьями:

Дополнительную информацию об операциях кластера в AKS см. в рекомендациях на такие темы: