Использование Azure RBAC в кластерах Kubernetes с поддержкой Azure Arc (предварительная версия)

  • Статья

Типы объектов ClusterRoleBinding и RoleBinding в Kubernetes помогают определить собственную авторизацию в Kubernetes. С помощью этой функции можно использовать идентификатор и назначения ролей Microsoft Entra в Azure для управления авторизацией проверка в кластере. Назначения ролей Azure позволяют детально контролировать, какие пользователи могут читать, записывать и удалять объекты Kubernetes, такие как развертывание, pod и служба.

Общие сведения об этой функции см. в статье Azure RBAC в Kubernetes с поддержкой Azure Arc.

Важно!

Предварительные версии функций Kubernetes с поддержкой Azure Arc доступны в режиме самообслуживания после получения согласия на участие. Предварительные версии предоставляются "как есть" и "при наличии". На них не распространяются соглашения об уровне обслуживания и ограниченная гарантия. Предварительные версии функций Kubernetes с поддержкой Azure Arc предоставляются с частичной клиентской поддержкой по мере возможности.

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

  • Установите или обновите Azure CLI до последней версии.

  • Установите последнюю версию connectedk8s расширения Azure CLI:

    az extension add --name connectedk8s

    Если расширение connectedk8s уже установлено, его можно обновить до последней версии, выполнив следующую команду.

    az extension update --name connectedk8s

  • Подключитесь к существующему кластеру Kubernetes с поддержкой Azure Arc:

Примечание.

Эту функцию нельзя настроить для Red Hat OpenShift или для управляемых предложений Kubernetes облачных поставщиков, таких как служба Elastic Kubernetes или Google Kubernetes Engine, где пользователь не имеет доступа к серверу API кластера. Для кластеров Службы Azure Kubernetes (AKS) эта функция доступна изначально и не требует подключения кластера AKS к Azure Arc.

Настройка приложений Microsoft Entra

Создание серверного приложения

  1. Создайте приложение Microsoft Entra и получите его appId значение. Это значение будет использоваться в дальнейших шагах как serverApplicationId.

    CLUSTER_NAME="<name-of-arc-connected-cluster>"
TENANT_ID="<tenant>"
SERVER_UNIQUE_SUFFIX="<identifier_suffix>"
SERVER_APP_ID=$(az ad app create --display-name "${CLUSTER_NAME}Server" --identifier-uris "api://${TENANT_ID}/${SERVER_UNIQUE_SUFFIX}" --query appId -o tsv)
echo $SERVER_APP_ID

  2. Чтобы предоставить разрешения API "Вход и чтение профиля пользователя" для серверного приложения, скопируйте этот код JSON и сохраните его в файле с именем oauth2-permissions.json:

    {
    "oauth2PermissionScopes": [
        {
            "adminConsentDescription": "Sign in and read user profile",
            "adminConsentDisplayName": "Sign in and read user profile",
            "id": "<paste_the_SERVER_APP_ID>",
            "isEnabled": true,
            "type": "User",
            "userConsentDescription": "Sign in and read user profile",
            "userConsentDisplayName": "Sign in and read user profile",
            "value": "User.Read"
        }
    ]
}

  3. Обновите утверждения о членстве в группах приложения. Выполните команды в том же каталоге, что oauth2-permissions.json и файл. RBAC для Kubernetes с поддержкой Azure Arc необходимо задать для AzureADMyOrg:signInAudience

    az ad app update --id "${SERVER_APP_ID}" --set groupMembershipClaims=All
az ad app update --id ${SERVER_APP_ID} --set  api=@oauth2-permissions.json
az ad app update --id ${SERVER_APP_ID} --set  signInAudience=AzureADMyOrg
SERVER_OBJECT_ID=$(az ad app show --id "${SERVER_APP_ID}" --query "id" -o tsv)
az rest --method PATCH --headers "Content-Type=application/json" --uri https://graph.microsoft.com/v1.0/applications/${SERVER_OBJECT_ID}/ --body '{"api":{"requestedAccessTokenVersion": 1}}'

  4. Создайте субъект-службу и получите значение его поля password. Это значение потребуется позднее в качестве serverApplicationSecret при включении этой функции в кластере. Этот секрет действителен в течение одного года по умолчанию и должен быть повернут после этого. Чтобы задать настраиваемую длительность срока действия, используйте az ad sp credential reset:

    az ad sp create --id "${SERVER_APP_ID}"
SERVER_APP_SECRET=$(az ad sp credential reset --id "${SERVER_APP_ID}"  --query password -o tsv)

  5. Предоставьте разрешения API "Вход и чтение профиля пользователя" приложению с помощью az ad app permission:

    az ad app permission add --id "${SERVER_APP_ID}" --api 00000003-0000-0000-c000-000000000000 --api-permissions e1fe6dd8-ba31-4d61-89e7-88639da4683d=Scope
az ad app permission grant --id "${SERVER_APP_ID}" --api 00000003-0000-0000-c000-000000000000 --scope User.Read

    Примечание.

    Администратор приложения Azure должен выполнить этот шаг.

    Для использования этой функции в рабочей среде рекомендуется создать отдельное серверное приложение для каждого кластера.

Создание клиентского приложения

  1. Создайте приложение Microsoft Entra и получите его appId значение. Это значение будет использоваться в дальнейших шагах как clientApplicationId.

    CLIENT_UNIQUE_SUFFIX="<identifier_suffix>" 
CLIENT_APP_ID=$(az ad app create --display-name "${CLUSTER_NAME}Client" --is-fallback-public-client --public-client-redirect-uris "api://${TENANT_ID}/${CLIENT_UNIQUE_SUFFIX}" --query appId -o tsv)
echo $CLIENT_APP_ID

  2. Создайте субъект-службу для этого клиентского приложения.

    az ad sp create --id "${CLIENT_APP_ID}"

  3. Получите значение oAuthPermissionId для серверного приложения.

        az ad app show --id "${SERVER_APP_ID}" --query "api.oauth2PermissionScopes[0].id" -o tsv

  4. Предоставьте необходимые разрешения для клиентского приложения. RBAC для Kubernetes с поддержкой Azure Arc необходимо задать для AzureADMyOrg:signInAudience

        az ad app permission add --id "${CLIENT_APP_ID}" --api "${SERVER_APP_ID}" --api-permissions <oAuthPermissionId>=Scope
    RESOURCE_APP_ID=$(az ad app show --id "${CLIENT_APP_ID}"  --query "requiredResourceAccess[0].resourceAppId" -o tsv)
    az ad app permission grant --id "${CLIENT_APP_ID}" --api "${RESOURCE_APP_ID}" --scope User.Read
    az ad app update --id ${CLIENT_APP_ID} --set  signInAudience=AzureADMyOrg
    CLIENT_OBJECT_ID=$(az ad app show --id "${CLIENT_APP_ID}" --query "id" -o tsv)
    az rest --method PATCH --headers "Content-Type=application/json" --uri https://graph.microsoft.com/v1.0/applications/${CLIENT_OBJECT_ID}/ --body '{"api":{"requestedAccessTokenVersion": 1}}'

Создание назначения роли для серверного приложения

Серверное приложение должно иметь Microsoft.Authorization/*/read разрешения, чтобы убедиться, что пользователь, выполняющий запрос, авторизован на объекты Kubernetes, включенные в запрос.

  1. Создайте файл с именем accessCheck.json и со следующим содержимым.

    {
"Name": "Read authorization",
"IsCustom": true,
"Description": "Read authorization",
"Actions": ["Microsoft.Authorization/*/read"],
"NotActions": [],
"DataActions": [],
"NotDataActions": [],
"AssignableScopes": [
  "/subscriptions/<subscription-id>"
  ]
}

    Замените <subscription-id> фактическим идентификатором подписки.

  2. Выполните следующую команду, чтобы создать новую настраиваемую роль.

    ROLE_ID=$(az role definition create --role-definition ./accessCheck.json --query id -o tsv)

  3. Создайте назначение роли для серверного приложения как assignee, используя созданную роль.

    az role assignment create --role "${ROLE_ID}" --assignee "${SERVER_APP_ID}" --scope /subscriptions/<subscription-id>

Включение Azure RBAC в кластере

Включите управление доступом на основе ролей Azure (RBAC) в кластере Kubernetes с поддержкой Azure Arc, выполнив следующую команду:

az connectedk8s enable-features -n <clusterName> -g <resourceGroupName> --features azure-rbac --app-id "${SERVER_APP_ID}" --app-secret "${SERVER_APP_SECRET}"

Примечание.

Перед выполнением предыдущей команды убедитесь, что файл kubeconfig на компьютере указывает на кластер, в котором вы включаете функцию Azure RBAC.

Используйте --skip-azure-rbac-list с предыдущей командой для указания списка разделенных запятыми имен пользователей, адресов электронной почты и подключений OpenID, которые подлежат проверкам авторизации с использованием собственных объектов Kubernetes ClusterRoleBinding и RoleBinding вместо Azure RBAC.

Универсальный кластер, в котором не выполняется примиратель в спецификации apiserver

  1. Подключитесь по протоколу SSH к каждому главному узлу кластера и выполните следующие действия.

    Если используется kube-apiserver статический модуль pod:

    1. Секрет azure-arc-guard-manifests в kube-system пространстве имен содержит два файла: guard-authn-webhook.yaml и guard-authz-webhook.yaml. Скопируйте эти файлы в /etc/guard каталог узла.

      sudo mkdir -p /etc/guard
kubectl get secrets azure-arc-guard-manifests -n kube-system -o json | jq -r '.data."guard-authn-webhook.yaml"' | base64 -d > /etc/guard/guard-authn-webhook.yaml
kubectl get secrets azure-arc-guard-manifests -n kube-system -o json | jq -r '.data."guard-authz-webhook.yaml"' | base64 -d > /etc/guard/guard-authz-webhook.yaml

    2. Откройте манифест apiserver в режиме правки.

      sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml

    3. Добавьте следующую спецификацию в раздел volumes.

      - name: azure-rbac
    hostPath:
    path: /etc/guard
    type: Directory

    4. Добавьте следующую спецификацию в раздел volumeMounts.

      - mountPath: /etc/guard
    name: azure-rbac
    readOnly: true

    Если вы kube-apiserver не является статическим модулем pod:

    1. Откройте манифест apiserver в режиме правки.

      sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml

    2. Добавьте следующую спецификацию в раздел volumes.

      - name: azure-rbac
    secret:
    secretName: azure-arc-guard-manifests

    3. Добавьте следующую спецификацию в раздел volumeMounts.

      - mountPath: /etc/guard
    name: azure-rbac
    readOnly: true

  2. Добавьте следующие аргументы apiserver.

    - --authentication-token-webhook-config-file=/etc/guard/guard-authn-webhook.yaml
- --authentication-token-webhook-cache-ttl=5m0s
- --authorization-webhook-cache-authorized-ttl=5m0s
- --authorization-webhook-config-file=/etc/guard/guard-authz-webhook.yaml
- --authorization-webhook-version=v1
- --authorization-mode=Node,RBAC,Webhook

    Если кластер Kubernetes имеет версию не ниже 1.19.0, необходимо также задать следующий аргумент apiserver.

    - --authentication-token-webhook-version=v1

  3. Сохраните изменения и закройте редактор, чтобы обновить pod apiserver.

Кластер, созданный с помощью API кластера

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

    kubectl get secret azure-arc-guard-manifests -n kube-system -o yaml > azure-arc-guard-manifests.yaml

  2. Измените поле namespace в файле azure-arc-guard-manifests.yaml на пространство имен в кластере управления, где вы применяете настраиваемые ресурсы для создания кластеров рабочей нагрузки.

  3. Примените этот манифест.

    kubectl apply -f azure-arc-guard-manifests.yaml

  4. Измените объект KubeadmControlPlane, выполнив kubectl edit kcp <clustername>-control-plane.

    1. Добавьте в раздел files следующий фрагмент кода.

      - contentFrom:
    secret:
      key: guard-authn-webhook.yaml
      name: azure-arc-guard-manifests
  owner: root:root
  path: /etc/kubernetes/guard-authn-webhook.yaml
  permissions: "0644"
- contentFrom:
    secret:
      key: guard-authz-webhook.yaml
      name: azure-arc-guard-manifests
  owner: root:root
  path: /etc/kubernetes/guard-authz-webhook.yaml
  permissions: "0644"

    2. Добавьте в раздел apiServer>extraVolumes следующий фрагмент кода.

      - hostPath: /etc/kubernetes/guard-authn-webhook.yaml
    mountPath: /etc/guard/guard-authn-webhook.yaml
    name: guard-authn
    readOnly: true
- hostPath: /etc/kubernetes/guard-authz-webhook.yaml
    mountPath: /etc/guard/guard-authz-webhook.yaml
    name: guard-authz
    readOnly: true

    3. Добавьте в раздел apiServer>extraArgs следующий фрагмент кода.

      authentication-token-webhook-cache-ttl: 5m0s
authentication-token-webhook-config-file: /etc/guard/guard-authn-webhook.yaml
authentication-token-webhook-version: v1
authorization-mode: Node,RBAC,Webhook
authorization-webhook-cache-authorized-ttl: 5m0s
authorization-webhook-config-file: /etc/guard/guard-authz-webhook.yaml
authorization-webhook-version: v1

    4. Сохраните изменения и закройте объект KubeadmControlPlane, чтобы обновить его. Дождитесь появления этих изменений в кластере рабочей нагрузки.

Создание назначений ролей для доступа пользователей к кластеру

Владельцы ресурса Kubernetes с поддержкой Azure Arc могут использовать встроенные роли или пользовательские роли для предоставления другим пользователям доступа к кластеру Kubernetes.

Встроенные роли

Роль Description
Зритель Kubernetes Azure Arc Разрешает доступ только для чтения, позволяя просматривать большинство объектов в пространстве имен. Эта роль не позволяет просматривать секреты, так как read разрешение на секреты позволит получить доступ к ServiceAccount учетным данным в пространстве имен. В свою очередь, эти учетные данные позволят доступ к API через это значение ServiceAccount (форма повышения привилегий).
Писатель Kubernetes Azure Arc Разрешает доступ для чтения и записи к большинству объектов в пространстве имен. Эта роль не позволяет просматривать или изменять роли или привязки ролей. Однако эта роль позволяет получать доступ к секретам и запускать pod в качестве любого ServiceAccount значения в пространстве имен, поэтому его можно использовать для получения уровней доступа API любого ServiceAccount значения в пространстве имен.
Администратор Kubernetes Azure Arc Разрешает административный доступ. Эта роль предназначена для предоставления в пространстве имен через RoleBinding. Если вы используете ее в RoleBinding, она разрешает доступ на чтение и запись к большинству ресурсов в пространстве имен, включая возможность создания ролей и привязки ролей в пространстве имен. Эта роль не разрешает доступ на запись к квоте ресурса или пространству имен.
Администратор кластера Kubernetes Azure Arc Позволяет суперпользователю выполнять любые действия с любым ресурсом. При использовании этой роли в ClusterRoleBinding она предоставляет полный контроль над каждым ресурсом в кластере и во всех пространствах имен. При использовании этой роли в RoleBinding она предоставляет полный контроль над каждым ресурсом в пространстве имен привязки роли, включая само пространство имен.

Вы можете создать назначения ролей область в кластер Kubernetes с поддержкой Azure Arc в портал Azure на панели контроль доступа (IAM) ресурса кластера. Вы также можете использовать следующие команды Azure CLI.

az role assignment create --role "Azure Arc Kubernetes Cluster Admin" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID

В этих командах AZURE-AD-ENTITY-ID может быть именем пользователя (например, testuser@mytenant.onmicrosoft.com) или даже значением appId субъекта-службы.

Ниже приведен еще один пример создания назначения роли в области определенного пространства имен в кластере.

az role assignment create --role "Azure Arc Kubernetes Viewer" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID/namespaces/<namespace-name>

Примечание.

Вы можете создавать назначения ролей, область область в кластере, с помощью портал Azure или Azure CLI. Однако для создания назначений ролей область в пространствах имен можно использовать только Azure CLI.

Пользовательские роли

Вы можете создать собственное определение роли для использования в назначениях ролей.

Рассмотрим следующий пример определения роли, которая разрешает пользователю только чтение развертываний. Дополнительные сведения см. в полном списке действий с данными, которые можно использовать для создания определения роли.

Скопируйте следующий объект JSON в файл с именем custom-role.json. Замените заполнитель <subscription-id> фактическим идентификатором подписки. Настраиваемая роль использует одно из действий с данными и позволяет просматривать все развертывания в области (кластере или пространстве имен), в которой создается назначение роли.

{
    "Name": "Arc Deployment Viewer",
    "Description": "Lets you view all deployments in cluster/namespace.",
    "Actions": [],
    "NotActions": [],
    "DataActions": [
        "Microsoft.Kubernetes/connectedClusters/apps/deployments/read"
    ],
    "NotDataActions": [],
    "assignableScopes": [
        "/subscriptions/<subscription-id>"
    ]
}

  1. Создайте определение роли, выполнив следующую команду из папки, в которую сохранен файл custom-role.json.

    az role definition create --role-definition @custom-role.json

  2. Создайте назначение роли с помощью этого определения настраиваемой роли.

    az role assignment create --role "Arc Deployment Viewer" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID/namespaces/<namespace-name>

Настройка kubectl с учетными данными пользователя

Существует два способа получить файл kubeconfig, необходимый для доступа к кластеру.

  • Вы используете функцию Подключение кластера (az connectedk8s proxy) кластера Kubernetes с поддержкой Azure Arc.
  • Администратор кластера предоставляет общий доступ к файлу kubeconfig всем пользователям.

Использование подключения к кластеру

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

az connectedk8s proxy -n <clusterName> -g <resourceGroupName>

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

Использование общего файла kubeconfig

Использование общей kubeconfig требует немного разных шагов в зависимости от версии Kubernetes.

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

    kubectl config set-credentials <testuser>@<mytenant.onmicrosoft.com> \
--auth-provider=azure \
--auth-provider-arg=environment=AzurePublicCloud \
--auth-provider-arg=client-id=<clientApplicationId> \
--auth-provider-arg=tenant-id=<tenantId> \
--auth-provider-arg=apiserver-id=<serverApplicationId>

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

    kubectl config set-context --current=true --user=<testuser>@<mytenant.onmicrosoft.com>

  3. Добавьте параметр config-mode в раздел user>config.

    name: testuser@mytenant.onmicrosoft.com
user:
    auth-provider:
    config:
        apiserver-id: $SERVER_APP_ID
        client-id: $CLIENT_APP_ID
        environment: AzurePublicCloud
        tenant-id: $TENANT_ID
        config-mode: "1"
    name: azure

Примечание.

Подключаемый модуль Exec — это стратегия проверки подлинности Kubernetes, которая позволяет kubectl выполнить внешнюю команду для получения учетных данных пользователя для отправки apiserver. Начиная с Kubernetes версии 1.26 подключаемый модуль авторизации Azure по умолчанию больше не включен client-go и kubectl. В более поздних версиях, чтобы использовать подключаемый модуль exec для получения учетных данных пользователя, необходимо использовать Azure Kubelogin, client-go подключаемый модуль учетных данных (exec), реализующий проверку подлинности Azure.

  1. Установите Azure Kubelogin:

    • Для Windows или Mac следуйте инструкциям по установке Azure Kubelogin.

    • Для Linux или Ubuntu скачайте последнюю версию kubelogin, а затем выполните следующие команды:

      curl -LO https://github.com/Azure/kubelogin/releases/download/"$KUBELOGIN_VERSION"/kubelogin-linux-amd64.zip 

unzip kubelogin-linux-amd64.zip 

sudo mv bin/linux_amd64/kubelogin /usr/local/bin/ 

sudo chmod +x /usr/local/bin/kubelogin

  2. Преобразуйте kubelogin, чтобы использовать соответствующий режим входа. Например, для входа кода устройства с пользователем Microsoft Entra команды будут следующим образом:

    export KUBECONFIG=/path/to/kubeconfig

kubelogin convert-kubeconfig

Отправка запросов в кластер

  1. Выполните любую команду kubectl. Например:

    • kubectl get nodes
    • kubectl get pods

  2. После запроса проверки подлинности на основе браузера скопируйте URL-адрес входа устройства (https://microsoft.com/devicelogin) и откройте его в веб-браузере.

  3. Введите код, выведенный на вашей консоли. Скопируйте код и вставьте его в окно терминала в ответ на запрос проверки подлинности устройства.

  4. Введите имя пользователя (testuser@mytenant.onmicrosoft.com) и соответствующий пароль.

  5. Если появляется сообщение об ошибке, аналогичное приведенному ниже, это означает, что вы не можете получить доступ к запрошенному ресурсу.

    Error from server (Forbidden): nodes is forbidden: User "testuser@mytenant.onmicrosoft.com" cannot list resource "nodes" in API group "" at the cluster scope: User doesn't have access to the resource in Azure. Update role assignment to allow access.

    Администратору необходимо создать новое назначение роли, которое разрешает этому пользователю доступ к ресурсу.

Использование условного доступа с идентификатором Microsoft Entra

При интеграции идентификатора Microsoft Entra с кластером Kubernetes с поддержкой Azure Arc можно также использовать условный доступ для управления доступом к кластеру.

Примечание.

Условный доступ Microsoft Entra — это возможность Microsoft Entra ID P2.

Чтобы создать пример политики условного доступа для использования с кластером:

  1. В верхней части портал Azure найдите и выберите идентификатор Microsoft Entra.

  2. В меню для идентификатора Microsoft Entra в левой части выберите корпоративные приложения.

  3. В меню для корпоративных приложений слева выберите Условный доступ.

  4. В меню для условного доступа слева выберите Политики>Создать политику.

    Screenshot showing how to add a conditional access policy in the Azure portal.

  5. Введите имя политики, например arc-k8s-policy.

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

    Screenshot that shows selecting users or groups to apply the Conditional Access policy.

  7. Выберите Облачные приложения или действия. В списке Включить нажмите Выбрать приложения. Затем найдите и выберите созданное ранее серверное приложение.

    Screenshot showing how to select a server application in the Azure portal.

  8. В разделе Элементы управления доступом выберите Предоставление. Выберите Предоставить доступ>Require device to be marked as compliant (Требовать, чтобы устройство было отмечено как соответствующее).

    Screenshot showing how to allow only compliant devices in the Azure portal.

  9. В разделе Включить политику нажмите Вкл.>Создать.

    Screenshot showing how to enable a conditional access policy in the Azure portal.

Снова откройте кластер. Например, выполните команду kubectl get nodes, чтобы просмотреть узлы в кластере.

kubectl get nodes

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

  1. В портал Azure перейдите к идентификатору Microsoft Entra.

  2. Выберите Корпоративные приложения. Затем в разделе Действие выберите Входы.

  3. В записи вверху отображается Failed (Сбой) для состояния и Success (Успешно) для условного доступа. Щелкните эту запись, а затем в области Сведения выберите Условный доступ. Обратите внимание, что в списке указана ваша политика условного доступа.

    Screenshot showing a failed sign-in entry in the Azure portal.

Настройка JIT-доступа к кластеру с помощью идентификатора Microsoft Entra

Другим вариантом управления доступом кластера является использование управление привилегированными пользователями (PIM) для JIT-запросов.

Примечание.

Microsoft Entra PIM — это возможность Microsoft Entra ID P2. Дополнительные сведения об номерах SKU идентификаторов Microsoft Entra см. в руководстве по ценам.

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

  1. В верхней части портал Azure найдите и выберите идентификатор Microsoft Entra.

  2. Запишите идентификатор клиента. В остальных инструкциях мы будем ссылаться на этот идентификатор как на <tenant-id>.

    Screenshot showing Microsoft Entra ID details in the Azure portal.

  3. В меню идентификатора Microsoft Entra в левой части в разделе "Управление" выберите группы>"Создать группу".

  4. Убедитесь, что для типа группы выбран параметр Безопасность. Введите имя группы, например myJITGroup. В разделе ролей Microsoft Entra можно назначить этой группе (предварительная версия), нажмите кнопку "Да". Наконец, выберите Создать.

    Screenshot showing details for the new group in the Azure portal.

  5. Снова откроется страница Группы. Выберите только что созданную группу и запишите ее идентификатор объекта. В остальных инструкциях мы будем ссылаться на этот идентификатор как на <object-id>.

    Screenshot showing the object ID for the new group in the Azure portal.

  6. Вернитесь на портал Azure и в меню для действий слева выберите Привилегированный доступ (предварительная версия). Затем нажмите Включить привилегированный доступ.

    Screenshot showing selections for enabling privileged access in the Azure portal.

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

    Screenshot showing how to add active assignments in the Azure portal.

  8. Выберите роль члена, а затем выберите пользователей и группы, которым вы хотите предоставить доступ к кластеру. Администратор группы может изменить эти назначения в любое время. Когда вы будете готовы продолжить, нажмите кнопку Далее.

    Screenshot showing how to add assignments in the Azure portal.

  9. Выберите тип назначения Active (Активно), желаемую длительность и укажите обоснование. Когда все будет готово, нажмите кнопку Назначить. Дополнительные сведения о типах назначений см. в разделе Назначение соответствия для группы привилегированного доступа (предварительная версия) в Privileged Identity Management.

    Screenshot showing assignment properties in the Azure portal.

После выполнения назначений попробуйте получить доступ к кластеру, чтобы убедиться, что JIT-доступ работает. Например, выполните команду kubectl get nodes, чтобы просмотреть узлы в кластере.

kubectl get nodes

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

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

NAME      STATUS   ROLES    AGE      VERSION
node-1    Ready    agent    6m36s    v1.18.14
node-2    Ready    agent    6m42s    v1.18.14
node-3    Ready    agent    6m33s    v1.18.14

Обновление секрета серверного приложения

Если срок действия секрета для субъекта-службы сервера истек, необходимо повернуть его.

SERVER_APP_SECRET=$(az ad sp credential reset --name "${SERVER_APP_ID}" --credential-description "ArcSecret" --query password -o tsv)

Обновите секрет в кластере. Включите все необязательные параметры, настроенные при первоначальном выполнении команды.

az connectedk8s enable-features -n <clusterName> -g <resourceGroupName> --features azure-rbac --app-id "${SERVER_APP_ID}" --app-secret "${SERVER_APP_SECRET}"

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