Используйте контроль доступа на основе ролей Kubernetes с Microsoft Entra ID в Службе Azure Kubernetes.

2024-08-02

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

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

Управление доступом с помощью RBAC Kubernetes в кластере AKS на основе членства в группе Microsoft Entra.
Создание примеров групп и пользователей в идентификаторе Microsoft Entra.
Создайте роли и связывания ролей в кластере 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

Если этот параметр включен, на выходе отображается значение для enableAzureRbac: false.

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

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

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

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

Сначала получите идентификатор ресурса кластера 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
```
Совет

Если возникает ошибка, например 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, вы создадите два примера пользователей. Чтобы проверить интеграцию RBAC Kubernetes в конце статьи, выполните вход в кластер AKS с помощью этих учетных записей.

Задайте имя главного пользователя и пароль для разработчиков приложений.

Задайте имя участника-пользователя (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 должно быть указано проверенное доменное имя арендатора, например [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, чтобы разрешить этим различным группам доступ к определенным ресурсам.

Получите учетные данные администратора кластера с помощью 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, назначьте разрешения на основе userPrincipalName (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
  namespace: dev
  name: groupObjectId
```
Совет

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

Создание ресурсов кластера AKS для группы SRE

Теперь повторите предыдущие шаги, чтобы создать пространство имен, Роль и RoleBinding для SREs.

Создайте пространство имен для 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
  namespace: sre
  name: groupObjectId
```
Создайте RoleBinding с помощью kubectl apply команды и укажите имя файла манифеста YAML.
```
kubectl apply -f rolebinding-sre-namespace.yaml
```

Взаимодействуйте с ресурсами кластера с помощью удостоверений 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 команды в пространстве имен dev.
```
kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
```
Введите учетные данные для собственной [email protected] учетной записи, созданной в начале статьи, в качестве запроса на вход. После успешного входа маркер учетной записи кэшируется для будущих 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 для просмотра подов в пространстве имен 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
```

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

Попробуйте просмотреть поды за рамками пространства имен 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 в другом namespace, например 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"

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

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

Сбросите контекст kubeconfig с помощью az aks get-credentials команды, которая очищает ранее кэшированный маркер проверки подлинности для пользователя aksdev.
```
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --overwrite-existing
```
Попытайтесь запланировать и просмотреть объекты Pod в назначенном пространстве имен sre. При появлении запроса войдите с собственными [email protected] учетными данными, созданными в начале статьи.
```
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"
```

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

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

# 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 Azure AD 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 Azure AD 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).