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

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

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

Требования

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

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

  az extension add --name connectedk8s
  

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

  az extension update --name connectedk8s
  

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

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

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

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

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

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

   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
   

   Примечание.

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

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

Затем выполните действия, описанные в соответствующем разделе, в зависимости от того, используется ли универсальный кластер, на спецификации которого не выполняется согласование apiserver, или кластер, созданный с помощью Cluster API.

Универсальный кластер, в котором не выполняется согласователь согласно спецификации 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.

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

   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
   

   Задайте следующий 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.

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

Следующие встроенные роли предоставляют доступ к общим задачам в кластерах Kubernetes. Эти роли можно предоставить пользователям, группам или субъектам-службам Microsoft Entra ID.

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

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

Настраиваемые роли

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

В следующем примере показано определение пользовательской роли, позволяющее пользователю просматривать развертывания, но не предоставляет никакого другого доступа. Настраиваемая роль использует одно из действий с данными и позволяет просматривать все развертывания в области (кластере или пространстве имен), в которой создается назначение роли.

{
    "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>"
    ]
}

Чтобы использовать это определение роли, скопируйте следующий объект JSON в файл с именем custom-role.json. Замените заполнитель <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) кластера с поддержкой Azure Arc Kubernetes.
• Администратор кластера может предоставить общий доступ к файлу kubeconfig каждому пользователю.

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

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

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

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

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

1. Выполните следующую команду, чтобы задать учетные данные для пользователя. Укажите serverApplicationId как 6256c85f-0aad-4d50-b960-e6e9b21efe35, а clientApplicationId как 3f4439ff-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. Добавьте параметр режима конфигурации в разделе 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
   

4. Подключаемый модуль Exec — это стратегия аутентификации Kubernetes, которая позволяет kubectl выполнить внешнюю команду для получения и передачи учетных данных пользователя в apiserver. Начиная с Kubernetes версии 1.26, чтобы использовать подключаемый модуль exec для получения учетных данных пользователя, необходимо применять Azure kubelogin, подключаемый модуль, реализующий проверку подлинности Azure. Чтобы установить 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, чтобы использовать соответствующий режим входа , поддерживающий токены PoP. Для интерактивного входа с пользователем Microsoft Entra команда выглядит следующим образом:

   export KUBECONFIG=/path/to/kubeconfig
   
   kubelogin convert-kubeconfig -l interactive --pop-enabled --pop-claims "u=/ARM/ID/OF/CLUSTER"
   

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

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

   • kubectl get nodes
   • kubectl get pods

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

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

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

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

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

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

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

1. В верхней части портала Azure найдите и выберите идентификатор Microsoft Entra.
2. В меню службы в разделе "Управление" выберите "Корпоративные приложения".
3. В меню службы в разделе "Безопасность" выберите условный доступ.
4. В меню службы выберите "Политики". Затем нажмите кнопку "Создать новую политику".
5. Введите имя политики, например arc-k8s-policy.
6. В разделе "Назначения" выберите текущее значение в пункте "Пользователи" или "Рабочие нагрузки". Затем в разделе "Что применяется к этой политике?", убедитесь, что выбраны пользователи и группы .
7. В разделе "Включить" выберите "Выбрать пользователей и группы". Затем выберите пользователей и группы, для которых хотите применить политику. В этом примере выберите ту же группу Microsoft Entra, которая имеет административный доступ к кластеру.
8. Выберите текущее значение в разделе "Облачные приложения" или "Действия". Затем в разделе "Выбор того, к чему применяется эта политика", убедитесь, что выбраны облачные приложения .
9. В разделе "Включить" выберите "Выбрать ресурсы". Затем найдите и выберите созданное ранее серверное приложение.
10. В разделе "Элементы управления доступом" выберите текущее значение в разделе Grant. Затем выберите "Предоставить доступ".
11. Установите флажок "Требовать, чтобы устройство было помечено как соответствующее" и нажмите кнопку "Выбрать".
12. В разделе "Включение политики" выберите "Включить".
13. Чтобы применить политику условного доступа, нажмите кнопку "Создать".

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

kubectl get nodes

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

1. На портале Azure перейдите к идентификатору Microsoft Entra.
2. В меню службы в разделе "Управление" выберите "Корпоративные приложения".
3. В меню службы в разделе "Действие" выберите журналы входа.
4. Выберите запись вверху, где для статуса указано «Неудачно» и для условного доступа указано «Успешно». Затем в разделе "Сведения" выберите условный доступ. Вы увидите созданную политику условного доступа, требующую соответствия устройства.

Настройка доступа к кластеру по принципу "just-in-time" с помощью Microsoft Entra ID

Другим вариантом управления доступом к кластеру является Privileged Identity Management (PIM), что позволяет получить более высокий уровень доступа для пользователей в случаях, когда запросы поступают в режиме just-in-time.

Чтобы настроить запросы на доступ с функцией "доступ по мере востребования" для группы пользователей, выполните следующие действия:

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

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

3. Для типа группы убедитесь, что выбран параметр "Безопасность ". Введите имя группы, например myJITGroup. Внесите дополнительные выделения, а затем нажмите кнопку "Создать".

   

4. Вы вернелись на страницу "Группы ". Найдите и выберите только что созданную группу.

5. В меню службы в разделе "Действие" выберите "Управление привилегированными пользователями". Затем выберите "Включить PIM" для этой группы.

6. Выберите "Добавить назначения", чтобы начать предоставление доступа.

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

   

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

   

Дополнительные сведения об этих шагах и параметрах см. в разделе "Назначение прав доступа к группе в службе управления привилегированными пользователями".

После выполнения назначений попробуйте получить доступ к кластеру, чтобы убедиться, что 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 с поддержкой Azure Arc используется веб-перехватчик авторизации Azure Arc Guard для Azure RBAC. В неуправляемых кластерах Kubernetes (например, k3s) сертификаты защитного веб-перехватчика хранятся на диске и требуют ручного обновления. Срок действия сертификата веб-перехватчика охранника истекает через год с даты создания или последнего обновления и должен обновляться ежегодно до истечения срока действия. Дату окончания срока действия можно проверить с помощью файла сертификата guard-authz-webhook или файла проверки подлинности Guard на диске.

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

• Команды kubectl завершаются сбоем с ошибками TLS, такими как tls: недопустимый сертификат.

Пример:

Error from server (InternalError): an error on the server ("Internal Server Error: \"/api/v1/nodes?limit=500\": Post \"https://192.168.X.X:443/subjectaccessreviews?timeout=30s\": remote error: tls: bad certificate") has prevented the request from succeeding (get nodes)

• Сбой операций Azure CLI с кластером
• Сервер API или журналы Guard с ошибками подтверждения TLS или истечения срока действия сертификата, например x509: срок действия сертификата истек. Пример:

http: TLS handshake error from 192.168.0.0:65062: tls: failed to verify certificate: x509: certificate has expired or is not yet valid:

Чтобы устранить проблему, необходимо обновить сертификат веб-перехватчика Azure RBAC Guard. Чтобы выполнить исправление, вам потребуется следующий доступ:

Требования

• Чтение доступа к секретам в пространстве имен kube-system в затронутом кластере.
• Для кластеров, не использующих API Cluster, доступ через SSH к системным и главным узлам этих кластеров.
• Для кластеров Cluster API доступ к кластеру управления, в котором создаются кластеры рабочей нагрузки.

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

1. Обновите сертификат Guard Webhook, выполнив следующую команду:

kubectl rollout restart deployment/guard -n azure-arc

1. Для универсального кластера, в котором не выполняется согласование в спецификации apiserver, необходимо выполнить шаг 1a, а затем перезапустить модуль pod kube-apiserver.
2. Для кластера, созданного с помощью API кластера, необходимо выполнить шаги 1–3. После выполнения шагов 1-3 необходимо инициировать повторное согласование объекта KubeadmControlPlane для применения новых конфигураций webhook'а к кластеру рабочей нагрузки. Шаг 4 (изменение CR) может активировать повторное согласование объекта KubeadmControlPlane.

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

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