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

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

Общие сведения об этой функции см. в статье Azure RBAC в 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.

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

1. Получите удостоверение MSI кластера, выполнив следующую команду:

   az connectedk8s show -g <resource-group> -n <connected-cluster-name>
   

2. Получите идентификатор (identity.principalId) из выходных данных и выполните следующую команду, чтобы назначить роль читателя checkAccess для управляемого кластера Подключение кластера CheckAccess:

   az role assignment create --role "Connected Cluster Managed Identity CheckAccess Reader" --assignee "<Cluster MSI ID>" --scope <cluster ARM ID>
   

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

   az connectedk8s enable-features -n <clusterName> -g <resourceGroupName> --features azure-rbac
   

   Примечание.

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

Версия >Kubernetes = 1.26

1. Выполните следующую команду, чтобы задать учетные данные для пользователя. Укажите serverApplicationId как и clientApplicationId как 6256c85f-0aad-4d50-b960-e6e9b21efe353f4439ff-e698-4d6d-84fe-09c9d574f06b:

   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.

4. Установите 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 
     

5. Kubelogin можно использовать для проверки подлинности с помощью кластеров с поддержкой Azure Arc, запросить маркер проверки владения (PoP). Преобразуйте kubeconfig с помощью kubelogin, чтобы использовать соответствующий режим входа. Например, для входа кода устройства с пользователем Microsoft Entra команды будут следующим образом:

   export KUBECONFIG=/path/to/kubeconfig
   
   kubelogin convert-kubeconfig --pop-enabled --pop-claims 'u=<ARM ID of cluster>"
   

Kubernetes < версии 1.26

1. Выполните следующую команду, чтобы задать учетные данные для пользователя. Укажите serverApplicationId как и clientApplicationId как 6256c85f-0aad-4d50-b960-e6e9b21efe353f4439ff-e698-4d6d-84fe-09c9d574f06b:

   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
   

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

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. В меню для условного доступа слева выберите Политики>Создать политику.

   

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

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

   

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

   

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

   

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

   

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

kubectl get nodes

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

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

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

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

   

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

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

Примечание.

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

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

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

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

   

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

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

   

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

   

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

   

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

   

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

   

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

   

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

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

• Безопасное подключение к кластеру с помощью функции подключения к кластеру.
• Ознакомьтесь с архитектурой Azure RBAC в Kubernetes с поддержкой Arc.