Использование управление привилегированными пользователями (PIM) для управления доступом к кластерам Служба Azure Kubernetes (AKS)

Статья
09/04/2024

При настройке разрешений для разных команд может потребоваться задать разрешения по умолчанию для указанных команд, а затем предоставить привилегированный доступ определенным пользователям при необходимости. Использование Служба Azure Kubernetes (AKS) с идентификатором Microsoft Entra позволяет настроить управление привилегированными пользователями (PIM) для JIT-запросов.

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

Задайте роли по умолчанию, например группы для доступа к кластерам AKS или выполнения операций на основе членства в группах Microsoft Entra.
Настройте основные роли для доступа к кластерам AKS.
Самостоятельная активация ролей для получения JIT-доступа к кластерам AKS.
Задайте утверждающие утверждения, чтобы утвердить или запретить запросы на утверждение для JIT-доступа.

Примечание.

Microsoft Entra управление привилегированными пользователями (PIM) имеет возможности Microsoft Entra ID P2 или Управление идентификацией Microsoft Entra, требующие номера SKU уровня "Премиум P2". Дополнительные сведения см. в разделе Управление идентификацией Microsoft Entra основы лицензирования и руководство по ценообразованию.

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

В этой статье предполагается, что у вас есть существующий кластер AKS с интеграцией идентификатора Microsoft Entra ID. Если у вас его нет, см. статью "Создание кластера AKS" с интеграцией идентификатора Microsoft Entra ID.

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

В этом разделе мы создадим три группы в идентификаторе Microsoft Entra ID:

По умолчанию: эта группа имеет доступ только для чтения (Azure Kubernetes Service RBAC Reader) к ресурсам в кластере AKS.
Администратор. Эта группа имеет доступ администратора (Azure Kubernetes Service RBAC Admin) к ресурсам в кластере AKS.
Утверждающий: эта группа имеет разрешения на утверждение или запрет запросов для JIT-доступа к кластеру AKS.

Вместо создания отдельной группы утверждающего можно использовать только группы администраторов по умолчанию и администраторов. Однако при включении разрешений на утверждение в группу администрирования участник, получающий JIT-доступ, может утвердить свои собственные запросы и запросы других пользователей. Мы не рекомендуем использовать эту конфигурацию в рабочей среде, но это полезно для тестирования.

Создание группы по умолчанию

Получите идентификатор ресурса кластера AKS с помощью az aks show команды.

AKS_ID=$(az aks show \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --query id \
    --output tsv)

Получите идентификатор группы ресурсов кластера AKS с помощью az group show команды.
```
RG_ID=$(az group show \
    --resource-group <resource-group-name> \
    --query id \
    --output tsv)
```

Создайте группу по умолчанию с помощью az ad group create команды.

DEFAULT_ID=$(az ad group create \
    --display-name default \
    --mail-nickname default \
    --query id \
    --output tsv)

Создайте назначение ролей Azure для группы по умолчанию с помощью az role assignment create команды.

Существует три роли, которые можно назначить группе по умолчанию в зависимости от ваших требований:
- Azure Kubernetes Service RBAC Reader: назначено в области кластера AKS и предоставляет базовый доступ только для чтения к большинству ресурсов в кластере.
- Reader: назначено в области группы ресурсов и предоставляет доступ только для чтения к ресурсам в группе ресурсов.
- Azure Kubernetes Service Cluster User Role: назначено в области кластера AKS и предоставляет доступ к контексту kubeconfig для кластера AKS.
```
# Assign the Azure Kubernetes Service RBAC Reader role to the default group
az role assignment create \
    --role "Azure Kubernetes Service RBAC Reader" \
    --assignee $DEFAULT_ID \
    --scope $AKS_ID

# Assign the Reader role to the default group
az role assignment create \
    --role "Reader" \
    --assignee $DEFAULT_ID \
    --scope $RG_ID

# Assign the Azure Kubernetes Service Cluster User Role to the default group
az role assignment create \
    --role "Azure Kubernetes Service Cluster User Role" \
    --assignee $DEFAULT_ID \
    --scope $AKS_ID
```

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

Создайте группу администрирования с помощью az ad group create команды.

ADMIN_ID=$(az ad group create \
    --display-name admin \
    --mail-nickname admin \
    --query id \
    --output tsv)

Azure Kubernetes Service RBAC Admin Назначьте роль группе администрирования с помощью az role assignment create команды.
```
az role assignment create \
    --role "Azure Kubernetes Service RBAC Admin" \
    --assignee $ADMIN_ID \
    --scope $AKS_ID
```

Примечание.

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

az role assignment create \
   --role "Contributor" \
   --assignee $ADMIN_ID \
   --scope $AKS_ID/nodepools/<node-pool-name>

Помните, что это дает разрешение только на масштабирование из ресурса AKS. Если вы хотите разрешить масштабирование из ресурса масштабируемого набора виртуальных машин, необходимо создать назначение на уровне масштабируемого набора виртуальных машин.

Создание группы утверждающего

Создайте группу утверждающего с помощью az ad group create команды.

APPROVER_ID=$(az ad group create \
    --display-name approver \
    --mail-nickname approver \
    --query id \
    --output tsv)

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

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

Создайте обычного пользователя с помощью az ad user create команды.

DOMAIN=contoso.com
PASSWORD=Password1

NUSER_ID=$(az ad user create \
    --display-name n01 \
    --password ${PASSWORD} \
    --user-principal-name n01@${DOMAIN} \
    --query id \
    --output tsv)

Добавьте обычного пользователя в группу по умолчанию с помощью az ad group member add команды.
```
az ad group member add \
    --group $DEFAULT_ID \
    --member-id $NUSER_ID
```

Создайте привилегированного пользователя с помощью az ad user create команды.

PUSER_ID=$(az ad user create \
    --display-name p01 \
    --password ${PASSWORD} \
    --user-principal-name p01@${DOMAIN} \
    --query id \
    --output tsv)

Добавьте привилегированного пользователя в группу утверждающего с помощью az ad group member add команды.
```
az ad group member add \
    --group $APPROVER_ID \
    --member-id $PUSER_ID
```

Включение управление привилегированными пользователями (PIM) для группы администрирования

На домашней странице портал Azure выберите идентификатор Microsoft Entra.
В меню службы в разделе "Управление" выберите "Группы" и выберите группу администрирования .
В меню службы в разделе "Действие" выберите управление привилегированными пользователями, а затем выберите "Включить PIM" для этой группы.

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

На домашней странице портал Azure найдите и выберите управление привилегированными пользователями.
В меню службы в разделе "Управление" выберите "Группы" и выберите группу администрирования .
В меню службы в разделе "Управление" выберите "Назначения>" "Добавить назначения".
На вкладке "Членство " на странице "Добавление назначений " выберите "Участник " в качестве выбранной роли и по умолчанию в качестве выбранного элемента, а затем нажмите кнопку "Далее".
На вкладке "Параметры" выберите "Допустимый " в качестве типа назначения и нажмите кнопку "Назначить".
В меню службы в разделе "Управление" выберите "Параметры>" "Изменить участника>".
На странице "Изменение роли" выберите флажок "Требовать утверждение" и добавьте группу утверждающего в качестве выбранного утверждающего.

Примечание.

Если флажок "Требовать утверждение" не установлен, пользователи в группе по умолчанию могут самостоятельно активировать роль, чтобы получить JIT-доступ к кластеру AKS без утверждения. Пользователь в группе утверждающих должен быть членом группы. Даже если пользователь задан как владелец, они по-прежнему не могут просматривать запросы jit-time, так как владелец группы имеет права администратора только на группу, а не назначение роли. Пользователь может быть членом и владельцем той же группы без конфликта.
Внесите другие необходимые изменения и нажмите кнопку "Обновить".

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

Взаимодействие с ресурсами кластера с помощью роли по умолчанию

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

Войдите в портал Azure как обычный пользователь с помощью az login команды.
```
az login --username n01@$DOMAIN --password ${PASSWORD}
```
Получите учетные данные пользователя для доступа к кластеру az aks get-credentials с помощью команды.
```
az aks get-credentials --resource-group <resource-group-name> --name <cluster-name>
```

Попробуйте получить доступ к модулям pod кластера с помощью kubectl get команды.

kubectl get pods --namespace kube-system

Выходные данные должны выглядеть примерно так, как в следующем примере выходных данных, в котором показаны модули pod в kube-system пространстве имен:

NAME                                   READY   STATUS    RESTARTS   AGE
azure-ip-masq-agent-2rdd9              1/1     Running   0          30h
azure-policy-767c9d9d9d-886rf          1/1     Running   0          31h
cloud-node-manager-92t6h               1/1     Running   0          30h
coredns-789789675-b2dhg                1/1     Running   0          31h
coredns-autoscaler-77bbc46446-pgt92    1/1     Running   0          31h
csi-azuredisk-node-lnzrf               3/3     Running   0          30h
csi-azurefile-node-lhbxr               3/3     Running   0          31h
konnectivity-agent-7645d94b-9wqct      1/1     Running   0          30h
kube-proxy-lkx4w                       1/1     Running   0          31h
metrics-server-5955767688-lpbjb        2/2     Running   0          30h

Попробуйте получить доступ к секретам кластера с помощью kubectl get команды.
```
kubectl get secrets --namespace kube-system
```
Выходные данные должны выглядеть примерно так, как в следующем примере выходных данных, в котором отображается сообщение об ошибке, так как у пользователя нет разрешения на доступ к секретам:
```
Error from server (Forbidden): secrets is forbidden: User "[email protected]" cannot list resource "secrets" in API group "" in the namespace "kube-system": User does not have access to the resource in Azure. Update role assignment to allow access.
```
Роль Azure Kubernetes Service RBAC Reader не имеет разрешения на доступ к секретам, поэтому эта ошибка ожидается.

Запрос JIT-доступа к кластеру AKS

На этот раз мы можем запросить JIT-доступ в качестве временногоAzure Kubernetes Service RBAC Admin, используя шаги, описанные в разделе "Активация членства в группе или владение" в управление привилегированными пользователями. Сведения о том, как утвердить или запретить запросы в качестве утверждающего, см. в статье "Утверждение запросов на активацию" для членов группы и владельцев.

Взаимодействие с ресурсами кластера с помощью роли администратора

После временного добавления Azure Kubernetes Service RBAC Admin роли вы можете получить доступ к ресурсам кластера, которым требуются разрешения администратора.

Удалите существующие сохраненные маркеры с помощью следующей kubelogin команды:
```
kubelogin remove-tokens
```
Примечание.

При возникновении ошибки из-за отсутствия разрешений войдите в систему, чтобы обновить разрешения с помощью az login команды.
Повторите попытку доступа к секретам кластера с помощью kubectl get secrets команды.
```
kubectl get secrets --namespace kube-system
```
Выходные данные должны выглядеть примерно так, как в следующем примере выходных данных, в котором показаны секреты в kube-system пространстве имен:
```
NAME                     TYPE                            DATA   AGE
bootstrap-token-sw3rck   bootstrap.kubernetes.io/token   4      35h
konnectivity-certs       Opaque                          3      35h
```
Теперь пользователь может получить доступ к секретам, так как у них есть Azure Kubernetes Service RBAC Admin роль.

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

Дополнительные сведения см. в следующих статьях:

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