Используйте RBAC в Kubernetes с идентификатором Microsoft Entra в Azure Kubernetes Service (AKS).

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

Из этой статьи вы узнаете, как выполнять следующие задачи:

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

Предпосылки

У вас есть существующий кластер AKS с включенной интеграцией Microsoft Entra. Если вам нужен кластер AKS с этой конфигурацией, см. раздел Интеграции идентификатора Microsoft Entra с AKS.
Kubernetes RBAC включен по умолчанию во время создания кластера AKS. Сведения об обновлении существующего кластера с интеграцией Microsoft Entra и Kubernetes RBAC см. в статье "Включение интеграции Microsoft Entra" в существующем кластере AKS.
Убедитесь, что Azure CLI версии 2.0.61 или более поздней версии установлен и настроен. Чтобы узнать версию, выполните команду az --version. Чтобы выполнить установку или обновление, см. сведения в статье Установка Azure CLI.
При использовании Terraform установите Terraform версии 2.99.0 или более поздней.

Используйте портал Azure или Azure CLI для проверки интеграции Microsoft Entra с Kubernetes RBAC.

Портал Azure
Azure CLI

Чтобы проверить использование портал Azure, выполните следующие действия.

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

Вы можете проверить, используя команду Azure CLI az aks show . Замените значение myResourceGroup именем группы ресурсов, на котором размещен ресурс кластера AKS, и замените myAKSCluster фактическим именем кластера AKS.

az aks show --resource-group myResourceGroup --name myAKSCluster

Если вы используете проверку подлинности Microsoft Entra с Kubernetes RBAC (а не Azure RBAC), то выходное значение для enableAzureRbac будет false.

Создание групп в идентификаторе Microsoft Entra

В этом разделе описано, как создать две роли пользователей, чтобы показать, как Kubernetes RBAC и Microsoft Entra ID управляют ресурсами кластера доступа. Ниже приведены два примера ролей:

Разработчик приложения
- Пользователь с именем aksdev , который входит в группу appdev .
Инженер надежности сайта (SRE)
- Пользователь с именем akssre , который входит в группу opssre .

В рабочих средах можно использовать существующих пользователей и групп в клиенте Microsoft Entra.

Разработка приложений
SRE

Сначала получите идентификатор ресурса кластера AKS с помощью az aks show команды. Затем назначьте идентификатор ресурса переменной с именем AKS_ID , чтобы ее можно было ссылаться в других командах.
```
AKS_ID=$(az aks show \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --query id -o tsv)
```
Создайте первую группу в Microsoft Entra ID для разработчиков приложений с помощью команды az ad group create. В следующем примере создается группа appdev:
```
APPDEV_ID=$(az ad group create --display-name appdev --mail-nickname appdev --query id -o tsv)
```
Создайте назначение ролей Azure для группы appdev с помощью az role assignment create команды. Это назначение позволяет любому члену группы использовать kubectl для взаимодействия с кластером AKS, предоставляя им роль пользователя кластера службы Kubernetes Azure.
```
az role assignment create \
  --assignee $APPDEV_ID \
  --role "Azure Kubernetes Service Cluster User Role" \
  --scope $AKS_ID
```
Это важно

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

Совет

Если возникает ошибка, например Principal 35bfec9328bd4d8d9b54dea6dac57b82 doesn't exist in the directory a5443dcd-cd0e-494d-a387-3039b419f0d5., подождите несколько секунд, пока идентификатор объекта группы Microsoft Entra будет распространяться по каталогу, а затем повторите az role assignment create команду.

Создайте пример группы для SREs с именем opssre.

OPSSRE_ID=$(az ad group create --display-name opssre --mail-nickname opssre --query id -o tsv)

Создайте назначение роли Azure, чтобы предоставить участникам группы роль пользователя кластера Azure Kubernetes Service.
```
az role assignment create \
  --assignee $OPSSRE_ID \
  --role "Azure Kubernetes Service Cluster User Role" \
  --scope $AKS_ID
```

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

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

Перед началом работы необходимо задать имя участника-пользователя (UPN) и пароль для разработчиков приложений. UPN должно включать проверенное доменное имя вашего арендатора. Например, пользователь разработчика приложений. [email protected] Чтобы выяснить (или задать) проверенные доменные имена в клиенте, см. статью "Управление именами пользовательских доменов" в идентификаторе Microsoft Entra.

Следующая команда запрашивает вас ввести UPN и устанавливает его в AAD_DEV_UPN, чтобы его можно было использовать в последующей команде:

echo "Please enter the UPN for application developers: " && read AAD_DEV_UPN

Следующая команда запрашивает у вас пароль и устанавливает его как AAD_DEV_PW для использования в последующей команде.

echo "Please enter the secure password for application developers: " && read AAD_DEV_PW

Создайте первую учетную запись пользователя в идентификаторе Microsoft Entra с помощью az ad user create команды. В следующем примере создается пользователь с отображаемым именем AKS Dev, upN и безопасным паролем с помощью значений в AAD_DEV_UPN и AAD_DEV_PW:
```
AKSDEV_ID=$(az ad user create \
  --display-name "AKS Dev" \
  --user-principal-name $AAD_DEV_UPN \
  --password $AAD_DEV_PW \
  --query id -o tsv)
```
Добавьте пользователя в группу appdev , созданную в предыдущем разделе с помощью az ad group member add команды:
```
az ad group member add --group appdev --member-id $AKSDEV_ID
```

Задайте имя входа и пароль для инженеров SRE. UPN должно включать проверенное доменное имя вашего арендатора. Например, пользователь SRE. [email protected] В следующей команде вас попросят указать UPN и установить его как AAD_SRE_UPN для использования в поздней команде.
```
echo "Please enter the UPN for SREs: " && read AAD_SRE_UPN
```
Следующая команда запросит у вас пароль и установит его как AAD_SRE_PW для последующего использования в другой команде.
```
echo "Please enter the secure password for SREs: " && read AAD_SRE_PW
```
Создайте вторую учетную запись пользователя. В следующем примере создается пользователь с отображаемым именем AKS SRE и UPN и защищенный пароль с помощью значений в AAD_SRE_UPN и AAD_SRE_PW:
```
# Create a user for the SRE role
AKSSRE_ID=$(az ad user create \
  --display-name "AKS SRE" \
  --user-principal-name $AAD_SRE_UPN \
  --password $AAD_SRE_PW \
  --query id -o tsv)

# Add the user to the opssre Entra ID group
az ad group member add --group opssre --member-id $AKSSRE_ID
```

Создание ресурсов кластера AKS

У нас созданы группы Microsoft Entra, пользователи и назначения ролей Azure. Теперь вы настроите кластер AKS, чтобы разрешить этим различным группам доступ к определенным ресурсам.

Разработка приложений
SRE

Получите учетные данные администратора кластера с помощью az aks get-credentials команды. В одном из следующих разделов вы получите данные авторизации кластера пользователей по умолчанию , чтобы увидеть поток аутентификации Microsoft Entra в действии.
```
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --admin
```
Создайте пространство имен в кластере AKS с помощью kubectl create namespace команды. В следующем примере создается пространство имен dev:
```
kubectl create namespace dev
```
Примечание.

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

Если пользователь, которому предоставлена привязка Kubernetes RBAC, находится в том же клиенте Microsoft Entra, разрешения необходимо назначить на основе UPN. Если пользователь находится в другом клиенте Microsoft Entra, выполните запрос и используйте свойство objectId .
Создайте роль для dev пространства имен, которая предоставляет полные разрешения этому пространству имен. В рабочей среде можно указать более детализированные разрешения для разных пользователей или групп. Создайте файл 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: ["*"]
```
Создайте роль с помощью kubectl apply команды и укажите имя файла манифеста YAML.
```
kubectl apply -f role-dev-namespace.yaml
```
Получите идентификатор ресурса для группы appdev с помощью az ad group show команды. Эта группа устанавливается в качестве объекта RoleBinding на следующем шаге.
```
az ad group show --group appdev --query id -o tsv
```
Создайте RoleBinding для группы appdev, чтобы использовать ранее созданную роль для доступа к пространству имен. Создайте файл rolebinding-dev-namespace.yaml и вставьте в него следующий манифест YAML. В последней строке замените groupObjectId идентификатором объекта группы из предыдущей команды.
```
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
  # Replace the placeholder below with the group's objectId (GUID)
  name: groupObjectId
```
Совет

Если вы хотите создать ролевую привязку (RoleBinding) для одного пользователя, укажите тип: User и замените groupObjectId на имя пользователя (UPN) в предыдущем примере.
Создайте RoleBinding с помощью kubectl apply команды и укажите имя файла манифеста YAML:
```
kubectl apply -f rolebinding-dev-namespace.yaml
```

Создайте пространство имен для SRE с помощью kubectl create namespace команды:
```
kubectl create namespace sre
```

Создайте файл role-sre-namespace.yaml и вставьте в него следующий манифест YAML:

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

Создайте роль с помощью kubectl apply команды и укажите имя файла манифеста YAML:
```
kubectl apply -f role-sre-namespace.yaml
```
Получите идентификатор ресурса для группы opssre с помощью команды az ad group show :
```
az ad group show --group opssre --query id -o tsv
```
Создайте RoleBinding для группы opssre, чтобы использовать ранее созданную роль для получения доступа к пространству имен. Создайте файл rolebinding-sre-namespace.yaml и вставьте в него следующий манифест YAML. В последней строке замените groupObjectId идентификатором объекта группы из предыдущей команды:
```
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: sre-user-access
  namespace: sre
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: sre-user-full-access
subjects:
- kind: Group
  # Replace the placeholder below with the group's objectId (GUID)
  name: groupObjectId
```
Создайте RoleBinding с помощью kubectl apply команды и укажите имя файла манифеста YAML:
```
kubectl apply -f rolebinding-sre-namespace.yaml
```

Доступ к ресурсам кластера AKS с помощью удостоверений Microsoft Entra

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

Сбросите контекст kubeconfig с помощью az aks get-credentials команды. В предыдущем разделе вы настроили контекст с помощью учетных данных администратора кластера. Пользователь администратора пропускает запросы на вход в Microsoft Entra. --admin Без параметра применяется контекст пользователя, требующий проверки подлинности всех запросов с помощью идентификатора Microsoft Entra.
```
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --overwrite-existing
```
Запланируйте базовый pod NGINX с помощью kubectl run команды в пространстве имен разработки :
```
kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
```
Введите учетные данные для учетной записи группы appdev (введите собственные учетные данные) в командной строке входа. После успешного входа маркер учетной записи кэшируется для будущих kubectl команд. NGINX успешно запланирован, как показано в следующем примере выходных данных:
```
$ kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev

To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code B24ZD6FP8 to authenticate.

pod/nginx-dev created
```
kubectl get pods Используйте команду для просмотра pod-модулей в пространстве имен dev:
```
kubectl get pods --namespace dev
```
Убедитесь, что статус пода NGINX в состоянии Running. Выходные данные выглядят следующим образом:
```
$ kubectl get pods --namespace dev

NAME        READY   STATUS    RESTARTS   AGE
nginx-dev   1/1     Running   0          4m
```

Проверка доступа SRE к ресурсам кластера AKS

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

Сбросите контекст kubeconfig с помощью az aks get-credentials команды, которая очищает ранее кэшированный маркер проверки подлинности для пользователя aksdev.
```
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --overwrite-existing
```
Запланируйте и просматривайте pod в назначенном пространстве имен SRE. При появлении запроса войдите с помощью учетных данных учетной записи группы opssre (введите собственные учетные данные).
```
kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace sre
kubectl get pods --namespace sre
```
Как показано в следующем примере, вы можете успешно создавать и просматривать поды:
```
$ kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace sre
```
Чтобы войти, используйте веб-браузер, чтобы открыть страницу https://microsoft.com/devicelogin и ввести код BM4RHP3FD для проверки подлинности.
```
pod/nginx-sre created

$ kubectl get pods --namespace sre

NAME        READY   STATUS    RESTARTS   AGE
nginx-sre   1/1     Running   0
```
Попробуйте просмотреть или запланировать pods за пределами назначенного пространства имен SRE.
```
kubectl get pods --all-namespaces
kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
```
Эти командыkubectl завершаются ошибкой, как показано в следующем примере выходных данных. Членство в группах пользователя и роль Kubernetes и RoleBindings не предоставляют разрешения на создание или управление ресурсами в других пространствах имен.
```
$ kubectl get pods --all-namespaces
Error from server (Forbidden): pods is forbidden: User "[email protected]" cannot list pods at the cluster scope

$ kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
Error from server (Forbidden): pods is forbidden: User "[email protected]" cannot create pods in the namespace "dev"
```

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

Просмотр pods за пределами пространства имен dev. Используйте команду kubectl get pods с помощью --all-namespaces:

kubectl get pods --all-namespaces

Членство в группе пользователя не имеет роли Kubernetes, которая разрешает это действие, как показано в следующем примере выходных данных:

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

Таким же образом запланируйте pod в другом пространстве имен, например, в пространстве имен SRE. Членство в группе пользователя не сопряжено с ролью Kubernetes и RoleBinding для получения данных разрешений, как показано в следующем примере выводимых данных:

$ kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace sre

Error from server (Forbidden): pods is forbidden: User "[email protected]" cannot create resource "pods" in API group "" in the namespace "sre"

Очистка ресурсов кластера

Чтобы очистить все ресурсы, выполните следующие команды:

# Get the admin kubeconfig context to delete the necessary cluster resources.

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --admin

# Delete the dev and SRE namespaces. This also deletes the pods, Roles, and RoleBindings.

kubectl delete namespace dev
kubectl delete namespace sre

# Delete the Microsoft Entra ID user accounts for aksdev and akssre.

az ad user delete --upn-or-object-id $AKSDEV_ID
az ad user delete --upn-or-object-id $AKSSRE_ID

# Delete the Microsoft Entra ID groups for appdev and opssre. This also deletes the Azure role assignments.

az ad group delete --group appdev
az ad group delete --group opssre

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

Дополнительные сведения о защите кластеров Kubernetes см. в разделе "Параметры доступа и удостоверения" для AKS.
Рекомендации по управлению удостоверениями и ресурсами см. в статье Рекомендации по аутентификации и авторизации в службе Azure Kubernetes (AKS).

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2025-12-16