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

Статья
08/02/2024

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

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

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

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

Создание демонстрационных групп в идентификаторе 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 для разработчиков приложений 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.
```
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) и пароль для разработчиков приложений. В качестве имени участника-пользователя необходимо указать проверенное доменное имя клиента, например aksdev@contoso.com.

В следующей командной строке вы используете имя участника-пользователя и задаете его 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. В качестве имени участника-пользователя необходимо указать проверенное доменное имя клиента, например akssre@contoso.com. В следующей командной строке вы используете имя участника-пользователя и задаете его 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 Azure AD 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) определяют выдаваемые разрешения, а Привязки ролей (RoleBinding) применяют их к желаемым пользователям. Эти назначения могут применяться для определенного пространства имен или в масштабах всего кластера. Дополнительные сведения см. в разделе Использование авторизации RBAC Kubernetes.

Если пользователь, которому предоставлена привязка Kubernetes RBAC, находится в том же клиенте Microsoft Entra, назначьте разрешения на основе имени пользователя UserPrincipalName (UPN). Если пользователь находится в другом клиенте Microsoft Entra, выполните запрос и используйте свойство objectId .

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

Теперь мы повторим предыдущие шаги, чтобы создать пространство имен, role и 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 команды в пространстве имен разработки.

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

Введите учетные данные для собственной appdev@contoso.com учетной записи, созданной в начале статьи, в качестве запроса на вход. После успешного входа маркер учетной записи кэшируется для будущих 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 в пространстве имен разработки.

kubectl get pods --namespace dev

Убедитесь, что состояние модуля POD NGINX выполняется. Выходные данные будут выглядеть примерно так:

$ kubectl get pods --namespace dev

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

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

Попробуйте просмотреть модули pod за пределами пространства имен разработки . kubectl get pods Используйте команду еще раз, чтобы увидеть--all-namespaces.

kubectl get pods --all-namespaces

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

Error from server (Forbidden): pods is forbidden: User "aksdev@contoso.com" 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 "aksdev@contoso.com" 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. При появлении запроса войдите с собственными opssre@contoso.com учетными данными, созданными в начале статьи.

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

Как показано в следующем примере выходных данных, можно успешно создавать и просматривать объекты Pod:

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

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

pod/nginx-sre created

$ kubectl get pods --namespace sre

NAME        READY   STATUS    RESTARTS   AGE
nginx-sre   1/1     Running   0

Попробуйте просмотреть или запланировать модули pod за пределами назначенного пространства имен 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 "akssre@contoso.com" 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 "akssre@contoso.com" cannot create pods in the namespace "dev"

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

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

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

Поделиться через