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

  • Статья
  • Чтение занимает 8 мин

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

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

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

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

Использование Azure Active Directory (Azure AD)

Общие рекомендации

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

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

Интегрировав кластеры AKS с Azure, вы создаете роли или роли кластера, которые определяют права доступа к ресурсам. Затем вы привязываете роли к пользователям или группам из Azure AD. Дополнительные сведения об управлении доступом на основе ролей Kubernetes см. в следующем разделе. Интеграция с Azure AD и управление доступом к ресурсам показаны на следующей схеме.

Аутентификация на уровне кластера для интеграции Azure Active Directory с AKS

  1. Разработчик выполняет аутентификацию с помощью Azure AD.
  2. Конечная точка выдачи маркера Azure AD выдает маркер доступа.
  3. Разработчик выполняет действие, используя маркер Azure AD, например kubectl create pod.
  4. Kubernetes проверяет маркер в Azure AD и извлекает информацию о членстве разработчика в группах.
  5. Применяются правила Kubernetes RBAC и кластерные политики.
  6. Запрос разработчика выполняется успешно на основе предыдущей проверки членства в группе Azure AD, а также RBAC и политик Kubernetes.

Чтобы создать кластер AKS, который использует Azure AD, ознакомьтесь с разделом Интеграция Azure Active Directory с AKS.

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

Общие рекомендации

Определите разрешения пользователей или групп для ресурсов кластера с помощью Kubernetes RBAC. Создайте роли и привязки, которые назначают минимальные разрешения. Настройте интеграцию с Azure AD для автоматического обновления состояния пользователя или членства в группе и поддержания доступа к ресурсам кластера в актуальном состоянии.

В 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 Azure AD, как показано в следующем манифесте 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. Таким образом, вы логически разделяете и контролируете доступ к ресурсам. Используйте Kubernetes RBAC с интеграцией Azure AD.

Сведения об использовании групп Azure AD для управления доступом к ресурсам Kubernetes с помощью Kubernetes RBAC см. в статье Управление доступом к ресурсам кластера с помощью управления доступом на основе ролей и удостоверений Azure Active Directory в 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 для автоматического запроса доступа с помощью Azure AD.

Примечание

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

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

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

Примечание

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

Открытый код Azure AD управляемое pod удостоверение (предварительная версия) в Служба Azure Kubernetes устарело с 24.10.2022 г.

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

  • Стандартный режим. В этом режиме в кластере AKS развертываются следующие 2 компонента:

    • Контроллер управляемых удостоверений (MIC): контроллер Kubernetes, который следит за изменениями в pod, AzureIdentity и AzureIdentityBinding, через сервер API в Kubernetes. Когда контроллер обнаруживает соответствующее изменение, MIC за необходимости добавляет или удаляет AzureAssignedIdentity. В частности, при планировании pod MIC назначает управляемое удостоверение в Azure базовому масштабируемому набору виртуальных машин, используемому пулом узлов на этапе создания. При удалении всех pod, использующих удостоверение, удостоверение удаляется из масштабируемого набора виртуальных машин пула узлов, если другие модули не используют одно и то же управляемое удостоверение. Контроллер управляемых удостоверений выполняет аналогичные действия при создании или удалении AzureIdentity или AzureIdentityBinding.

    • Node Managed Identity: это pod, который работает как DaemonSet на каждом узле кластера AKS. NMI перехватывает запросы маркеров безопасности к службе метаданных экземпляров Azure на каждом узле. Он перенаправляет запросы себе и проверяет, имеет ли модуль pod доступ к удостоверению, для которого запрашивает маркер, и получает маркер из клиента Azure Active Directory от имени приложения.

  • Управляемый режим. В этом режиме существует только NMI. Идентификатор следует назначать вручную. Им должен управлять пользователь. Дополнительные сведения см. в статье Удостоверение pod в управляемом режиме. В этом режиме при использовании команды az aks pod-identity add для добавления удостоверения pod в кластер Служба Azure Kubernetes (AKS) создаются AzureIdentity и AzureIdentityBinding в пространстве имен, указанном параметром--namespace, а поставщик ресурсов AKS назначает управляемое удостоверение, указанное параметром--identity-resource-id, масштабируемом набору виртуальных машин каждого пула узлов в кластере AKS.

Примечание

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

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

  • Назначение удостоверений в масштабируемом наборе виртуальных машин пула узлов может занять 40–60 с. Для cronjobs или приложений, которым требуется доступ к удостоверению и которые не допускают задержки назначения, лучше использовать managed режим , так как удостоверение предварительно назначено масштабируемому набору виртуальных машин пула узлов. Вручную или с помощью команды az aks pod-identity add .
  • В 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.

Когда модули pod запрашивают маркер безопасности из Azure Active Directory для доступа к ресурсу Azure, сетевые правила перенаправляют трафик на сервер NMI.

  1. Сервер NMI выполняет следующие действия:

    • Определяет модули pod, запрашивающие доступ к ресурсам Azure на основе их удаленного адреса.
    • выполняет запрос к поставщику ресурсов Azure.

  2. Поставщик ресурсов Azure проверяет сопоставления удостоверений Azure в кластере AKS.

  3. Сервер NMI запрашивает маркер доступа в Azure AD на основе сопоставления удостоверения pod.

  4. Azure AD предоставляет доступ к серверу NMI, который возвращается контейнерам pod.

    • Этот маркер доступа может использоваться модулем pod для последующего запроса доступа к ресурсам в Azure.

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

Удостоверения pod позволяют pod автоматически запрашивать доступ к другим ресурсам.

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

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

Дальнейшие действия

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

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