Управление доступом с помощью идентификатора Microsoft Entra и RBAC Kubernetes

Область применения: AKS в локальной среде Azure, версия 23H2

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

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

Необходимые компоненты

Перед настройкой Kubernetes RBAC с помощью идентификатора Microsoft Entra необходимо иметь следующие предварительные требования:

• AkS, включенный кластером Azure Arc. Если вам нужно настроить кластер, ознакомьтесь с инструкциями по использованию портал Azure или Azure CLI.
• Azure CLI установлен и настроен. Если вам нужно установить ИНТЕРФЕЙС командной строки или обновление, см. статью "Установка Azure CLI".
• Azure CLI и расширение connectedk8s. Интерфейс командной строки (Azure CLI) — это набор команд для создания ресурсов Azure и управления ими. Чтобы проверить наличие Azure CLI, откройте программу командной строки и введите: az -v Кроме того, установите расширение connectedk8s, чтобы открыть канал в кластере Kubernetes. Инструкции по установке см. в статье "Установка Azure CLI".
• Kubectl. Средство командной строки Kubernetes kubectl позволяет выполнять команды, предназначенные для кластеров Kubernetes. Чтобы проверить, установлен ли kubectl, откройте программу командной строки и введите: kubectl version --client Убедитесь, что версия клиента kubectl не менее v1.24.0. Инструкции по установке см. в kubectl.
• Вы можете получить доступ к кластеру Kubernetes с указанными разрешениями в режиме прямого или прокси-сервера.
  • Чтобы получить доступ к кластеру Kubernetes непосредственно с помощью az aksarc get-credentials команды, вам потребуется разрешение microsoft.HybridContainerService/provisionedClusterInstances/listUserKubeconfig/action, которое входит в разрешение на роль пользователя кластера Arc Служба Azure Kubernetes
  • Чтобы получить доступ к кластеру Kubernetes из любого места с помощью команды прокси-сервераaz connectedk8s proxy, вам потребуется разрешение на роль пользователя кластера Kubernetes с поддержкой Microsoft.Kubernetes/connectedClusterUserCredential/action с поддержкой Azure Arc. Между тем необходимо убедиться, что агенты и компьютер, выполняющие процесс подключения, соответствуют требованиям сети в требованиях к сети с поддержкой Azure Arc Kubernetes.

Необязательные первые шаги

Если у вас еще нет группы Microsoft Entra, содержащей участников, может потребоваться создать группу и добавить некоторых участников, чтобы следовать инструкциям в этой статье.

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

Создание демонстрационной группы в идентификаторе Microsoft Entra

Сначала создайте группу в идентификаторе Microsoft Entra в клиенте для разработчиков приложений az ad group create с помощью команды. В следующем примере показано, как войти в клиент Azure, а затем создать группу с именем appdev:

az login
az ad group create --display-name appdev --mail-nickname appdev

Добавление пользователей в группу

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

Добавьте пользователя в группу appdev , созданную в предыдущем разделе с помощью az ad group member add команды. При выходе из сеанса повторно подключитесь к Azure с помощью az login.

$AKSDEV_ID = az ad user create --display-name <name> --password <strongpassword> --user-principal-name <name>@contoso.onmicrosoft.com
az ad group member add --group appdev --member-id $AKSDEV_ID

Создание пользовательской привязки роли RBAC Kubernetes в ресурсе кластера AKS для группы Microsoft Entra

Настройте кластер AKS, чтобы разрешить группе Microsoft Entra доступ к кластеру. Если вы хотите добавить группу и пользователей, см. статью "Создание демонстрационных групп" в идентификаторе Microsoft Entra.

1. az aksarc get-credentials Используйте команду, чтобы получить учетные данные администратора кластера:

   az aksarc get-credentials --name "$aks_cluster_name" --resource-group "$resource_group_name" --admin
   

2. Создайте пространство имен в кластере Kubernetes с помощью kubectl create namespace команды. В следующем примере создается пространство имен с именем dev:

   kubectl create namespace dev
   

В Kubernetes роли определяют разрешения для предоставления, а RoleBindings применяют разрешения для нужных пользователей или групп. Эти назначения можно применять к заданному пространству имен или всему кластеру. Дополнительные сведения см. в разделе Использование авторизации RBAC Kubernetes.

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

1. Создайте файл с именем role-dev-namespace.yaml и скопируйте и вставьте следующий манифест YAML:

   kind: Role
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: dev-user-full-access
     namespace: dev
   rules:
   - apiGroups: ["", "extensions", "apps"]
     resources: ["*"]
     verbs: ["*"]
   - apiGroups: ["batch"]
     resources:
     - jobs
     - cronjobs
     verbs: ["*"]
   

2. Создайте роль с помощью kubectl apply команды и укажите имя файла манифеста YAML:

   kubectl apply -f role-dev-namespace.yaml
   

3. Получите идентификатор ресурса для группы appdev с помощью az ad group show команды. Эта группа задана в качестве субъекта RoleBinding на следующем шаге:

   az ad group show --group appdev --query objectId -o tsv
   

   Команда az ad group show возвращает значение, которое вы используете в качестве groupObjectId:

   38E5FA30-XXXX-4895-9A00-050712E3673A
   

4. Создайте файл с именем rolebinding-dev-namespace.yaml и скопируйте и вставьте следующий манифест YAML. Вы устанавливаете привязку роли, которая позволяет группе appdev использовать роль для доступа к пространству role-dev-namespace имен. В последней строке замените groupObjectId идентификатор объекта группы, созданный командой az ad group show :

   kind: RoleBinding
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: dev-user-access
     namespace: dev
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: dev-user-full-access
   subjects:
   - kind: Group
     namespace: dev
     name: groupObjectId
   

   Совет

   Если вы хотите создать RoleBinding для одного пользователя, укажите kind: User и замените groupObjectId его именем участника-пользователя (UPN) в примере.

5. Создайте RoleBinding с помощью kubectl apply команды и укажите имя файла манифеста YAML:

   kubectl apply -f rolebinding-dev-namespace.yaml
   

   rolebinding.rbac.authorization.k8s.io/dev-user-access created
   

Использование встроенных ролей RBAC Kubernetes для ресурса кластера AKS

Kubernetes также предоставляет встроенные роли, доступные для пользователей. К этим встроенным ролям относятся следующие:

• Роли суперпользоваемых пользователей (cluster-admin)
• Роли, предназначенные для предоставления кластеру на уровне кластера с помощью ClusterRoleBindings
• Роли, предназначенные для предоставления в определенных пространствах имен с помощью RoleBindings (администратор, изменение, просмотр)

Дополнительные сведения о встроенных ролях RBAC Kubernetes см. в статье о ролях, доступных для пользователей Kubernetes RBAC.

Роли, доступные для пользователей

ClusterRole по умолчанию	ClusterRoleBinding по умолчанию	Description
администратор кластера	system:master group	Позволяет суперпользовательскому доступу выполнять любое действие в любом ресурсе. При использовании в ClusterRoleBinding эта роль обеспечивает полный контроль над каждым ресурсом в кластере и во всех пространствах имен. При использовании в RoleBinding он обеспечивает полный контроль над каждым ресурсом в пространстве имен привязки роли, включая само пространство имен.
администрирование	нет	Разрешает администратору доступ, предназначенный для предоставления в пространстве имен с помощью привязки роли. При использовании в привязке ролей разрешает доступ на чтение и запись к большинству ресурсов в пространстве имен, включая возможность создания ролей и привязок ролей в пространстве имен. Эта роль не разрешает доступ на запись к квоте ресурса или пространству имен. Эта роль также не разрешает доступ на запись к конечным точкам в кластерах, созданных с помощью Kubernetes версии 1.22+. Дополнительные сведения см. в разделе "Доступ на запись для конечных точек".
изменить	нет	Разрешает доступ для чтения и записи к большинству объектов в пространстве имен. Эта роль не позволяет просматривать или изменять роли или привязки ролей. Однако эта роль позволяет получать доступ к секретам и запускать pod как любой ServiceAccount в пространстве имен, поэтому его можно использовать для получения уровней доступа к API любого ServiceAccount в пространстве имен. Эта роль также не разрешает доступ на запись к конечным точкам в кластерах, созданных с помощью Kubernetes версии 1.22+. Дополнительные сведения см. в разделе "Доступ на запись для конечных точек".
view	нет	Разрешает доступ только для чтения, позволяя просматривать большинство объектов в пространстве имен. Оно не позволяет просматривать роли или привязки ролей. Эта роль не позволяет просматривать секреты, так как чтение содержимого секретов обеспечивает доступ к учетным данным ServiceAccount в пространстве имен, что позволит API получить доступ как к любому ServiceAccount в пространстве имен (форма эскалации привилегий).

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

Чтобы использовать встроенную роль Kubernetes RBAC с идентификатором Microsoft Entra, выполните следующие действия:

1. Примените встроенную view роль Kubernetes RBAC к группе Microsoft Entra:

   kubectl create clusterrolebinding <name of your cluster role binding> --clusterrole=view --group=<Azure AD group object ID>
   

2. Примените встроенную view роль RBAC Kubernetes к каждому из пользователей Microsoft Entra:

   kubectl create clusterrolebinding <name of your cluster role binding> --clusterrole=view --user=<Azure AD user object ID>
   

Доступ к кластеру Kubernetes

Теперь вы можете получить доступ к кластеру Kubernetes с указанными разрешениями с помощью прямого или прокси-режима.

Доступ к кластеру с помощью kubectl (прямой режим)

Чтобы получить доступ к кластеру Kubernetes с указанными разрешениями, оператор Kubernetes требует microsoft Entra kubeconfig, который можно получить с помощью az aksarc get-credentials команды. Эта команда предоставляет доступ к kubeconfig на основе администратора, а также пользовательскому kubeconfig. Файл kubeconfig на основе администратора содержит секреты и должен безопасно храниться и периодически поворачиваться. С другой стороны, пользовательский идентификатор Microsoft Entra ID kubeconfig не содержит секреты и может распространяться пользователям, подключающимся с клиентских компьютеров.

Чтобы выполнить эту команду Azure CLI, вам потребуется microsoft.HybridContainerService/provisionedClusterInstances/listUserKubeconfig/action, который включен в разрешения роли пользователя кластера Arc Служба Azure Kubernetes:

az aksarc get-credentials -g $resource_group_name -n $aks_cluster_name --file <file-name>

Теперь вы можете использовать kubectl для управления кластером. Например, можно перечислить узлы в кластере с помощью kubectl get nodes. При первом запуске необходимо выполнить вход, как показано в следующем примере:

kubectl get nodes

Доступ к кластеру с клиентского устройства (режим прокси-сервера)

Чтобы получить доступ к кластеру Kubernetes из любого места с помощью команды прокси-сервераaz connectedk8s proxy, вам потребуется разрешение на роль пользователя кластера Kubernetes с поддержкой Microsoft.Kubernetes/connectedClusterUserCredential/action с поддержкой Azure Arc.

Выполните следующие действия на другом клиентском устройстве:

1. Войдите с помощью проверки подлинности Microsoft Entra.

2. Получите подключение kubeconfig кластера, необходимое для взаимодействия с кластером из любого места (даже вне брандмауэра, окружающего кластер):

   az connectedk8s proxy -n $aks_cluster_name -g $resource_group_name
   

   Примечание.

   Эта команда открывает прокси-сервер и блокирует текущую оболочку.

3. В другом сеансе оболочки используйте для kubectl отправки запросов в кластер:

   kubectl get pods -A
   

Вы увидите ответ от кластера с полным списком pod в пространстве имен default.

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

Создание и просмотр ресурсов кластера за пределами назначенного пространства имен

Чтобы попытаться просмотреть модули pod за пределами пространства имен разработки , используйте kubectl get pods команду с флагом --all-namespaces :

kubectl get pods --all-namespaces

Членство в группе пользователя не имеет роли Kubernetes, которая разрешает это действие. Без разрешения команда создает ошибку:

Error from server (Forbidden): pods is forbidden: User cannot list resource "pods" in API group "" at the cluster scope

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

• Управление доступом на основе ролей в Azure (Azure RBAC).