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

Используйте управление привилегированными идентификационными данными (PIM) для контроля доступа к вашим кластерам Azure Kubernetes Service (AKS).

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

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

  • Установите роли по умолчанию для примеров групп, чтобы получить доступ к кластерам AKS или выполнять операции на основе членства в группах Microsoft Entra.
  • Настройте основные роли для доступа к кластерам AKS.
  • Активируйте роли самостоятельно, чтобы получить доступ 'just-in-time' к кластерам AKS.
  • Настройте утверждающих для одобрения или отклонения запросов на предоставление доступа по требованию.

Примечание.

Microsoft Entra Privileged Identity Management (PIM) имеет функции Microsoft Entra ID P2 или Microsoft Entra ID Governance, требующие SKU уровня 'Премиум P2'. Для получения дополнительной информации см. Основы лицензирования Microsoft Entra ID Governance и Руководство по ценообразованию.

Требования

В этой статье предполагается, что у вас есть существующий кластер 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.

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

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

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

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

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

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

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

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

  4. Создайте назначение ролей 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

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

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

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

  2. 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 ID: обычный пользователь с ролью по умолчанию и привилегированный пользователь, который может утвердить или отклонить JIT-запросы от обычного пользователя.

  1. Создайте обычного пользователя с помощью 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)

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

    az ad group member add \
    --group $DEFAULT_ID \
    --member-id $NUSER_ID

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

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

  4. Добавьте привилегированного пользователя в группу утверждающего с помощью az ad group member add команды.

    az ad group member add \
    --group $APPROVER_ID \
    --member-id $PUSER_ID

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

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

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

  1. На домашней странице портал Azure найдите и выберите управление привилегированными пользователями.

  2. В меню службы в разделе "Управление" выберите "Группы" и выберите группу администрирования .

  3. В меню службы в разделе "Управление" выберите "Назначения>" "Добавить назначения".

  4. На вкладке "Членство " на странице "Добавление назначений " выберите "Участник " в качестве выбранной роли и по умолчанию в качестве выбранного элемента, а затем нажмите кнопку "Далее".

  5. На вкладке "Параметры" выберите "Допустимый " в качестве типа назначения и нажмите кнопку "Назначить".

  6. В меню службы в разделе Управление выберите Параметры>Участник>Изменить.

  7. На странице Изменение настроек роли - Участник выберите флажок "Требовать утверждение для активации" и добавьте группу утверждения в качестве выбранного утверждающего.

    Примечание.

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

  8. Внесите другие необходимые изменения и нажмите кнопку "Обновить".

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

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

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

  1. Войдите в портал Azure как обычный пользователь с помощью команды az login.

    az login --username n01@$DOMAIN --password ${PASSWORD}

  2. Получите учетные данные пользователя для доступа к кластеру az aks get-credentials с помощью команды.

    az aks get-credentials --resource-group <resource-group-name> --name <cluster-name>

  3. Попробуйте получить доступ к подам кластера с помощью команды 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

  4. Попробуйте получить доступ к секретам кластера с помощью 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 не имеет разрешения на доступ к секретам, поэтому эта ошибка ожидается.

Запрос доступа к кластеру AKS в режиме "just-in-time"

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

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

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

  1. Удалите существующие сохраненные маркеры с помощью следующей kubelogin команды:

    kubelogin remove-tokens

    Примечание.

    При возникновении ошибки из-за отсутствия разрешений войдите в систему, чтобы обновить разрешения с помощью az login команды.

  2. Повторите попытку доступа к секретам кластера с помощью 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.

Соображения о времени существования токена

Из-за конструктивных особенностей времени жизни токена, если вы предоставляете роли пользователям, использующим инструменты CLI, например, kubectl или kubelogin, продолжительность активации технически не может быть менее 60 минут. Даже если длительность не превышает 60 минут, фактический действующий период остается в диапазоне от 60 до 75 минут.

Когда kubelogin пытается получить токены из платформы удостоверений Microsoft, access_token и refresh_token возвращаются для дальнейшего использования. access_token делает запросы к API, а refresh_token используется для получения нового access_token, когда текущий истекает. Невозможно отозвать access_token после создания, но refresh_token можно отозвать. Если refresh_token отозван, пользователь должен заново пройти проверку подлинности, чтобы получить новый refresh_token. Для того чтобы вручную отозвать refresh_token, можно использовать Revoke-AzureADUserAllRefreshToken.

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

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