Управление доступом с помощью Microsoft Entra ID и RBAC Kubernetes в AKS, включаемых Azure Arc

  • Статья

Область применения: AKS в Azure Stack HCI 22H2, AKS в Windows Server

Служба Azure Kubernetes (AKS) можно настроить для использования Microsoft Entra ID для проверки подлинности пользователей. В этой конфигурации вы входите в кластер Kubernetes с помощью маркера проверки подлинности Microsoft Entra. После проведения проверки подлинности вы можете использовать встроенное управление доступом на основе ролей Kubernetes (Kubernetes RBAC) для управления доступом к пространствам имен и ресурсам кластера на основе идентификатора пользователя или членства в группе.

В этой статье описывается, как управлять доступом с помощью Kubernetes RBAC в кластере Kubernetes на основе Microsoft Entra членства в группах AKS Arc. Вы создаете демонстрационную группу и пользователей в Microsoft Entra ID. Затем вы создаете роли и привязки ролей в кластере, чтобы предоставить соответствующие разрешения на создание и просмотр ресурсов.

Предварительные требования

Перед настройкой Kubernetes RBAC с помощью удостоверения Microsoft Entra необходимо:

  • Кластер Kubernetes, созданный в AKS Arc

    Вам потребуется кластер Kubernetes, созданный в AKS Arc. Если вам нужно настроить кластер, см. инструкции по использованию Windows Admin Center или PowerShell для развертывания AKS.

  • Подключение Azure Arc

    У вас должно быть подключение Azure Arc к кластеру Kubernetes. Сведения о включении Azure Arc см. в статье Подключение Служба Azure Kubernetes в кластере Azure Stack HCI к Kubernetes с поддержкой Azure Arc.

  • Вам потребуется доступ к следующим средствам командной строки:

    • Azure CLI и расширение connectedk8s

      Интерфейс командной строки (Azure CLI) — это набор команд для создания ресурсов Azure и управления ими. Чтобы проверка, есть ли у вас Azure CLI, откройте программу командной строки и введите : az -v. Кроме того, необходимо установить расширение connectedk8s , чтобы открыть канал для кластера Kubernetes.

      Инструкции по установке см. в статье Установка Azure CLI.

    • Kubectl

      Программа командной строки Kubernetes kubectl позволяет выполнять команды, предназначенные для кластеров Kubernetes. Чтобы проверка, установлен ли kubectl, откройте программу командной строки и введите : kubectl version --client. Убедитесь, что версия клиента kubectl не ниже v1.24.0.

      Инструкции по установке см. в разделе kubectl.

    • PowerShell и модуль PowerShell AksHci

      PowerShell — это кроссплатформенное решение для автоматизации задач, которое включает оболочку командной строки, скриптовый язык и платформу управления конфигурацией. Если вы установили AKS Arc, у вас есть доступ к модулю PowerShell AksHci.

Необязательные первые шаги

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

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

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

Сначала создайте группу в Microsoft Entra ID в клиенте для разработчиков приложений с помощью команды az ad group create. В следующем примере показано, как войти в клиент Azure, а затем создать группу с именем appdev:

az login
az ad group create --display-name appdev --mail-nickname appdev

Добавление пользователей в группу

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

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

$AKSDEV_ID = az ad user create --display-name <name> --password <strongpassword> --user-principal-name <name>@contoso.onmicrosoft.com
az ad group member add --group appdev --member-id $AKSDEV_ID

Создание настраиваемой привязки роли RBAC Kubernetes для ресурса кластера AKS для группы Microsoft Entra

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

  1. Получите учетные данные администратора кластера с помощью команды Get-AksHciCredential :

    Get-AksHciCredential -name <name-of-your-cluster>

  2. Создайте пространство имен в кластере Kubernetes с помощью команды kubectl create namespace . В следующем примере создается пространство имен с именем dev:

    kubectl create namespace dev

    В Kubernetes роли определяют разрешения для предоставления, а RoleBindings применяют разрешения к нужным пользователям или группам. Эти назначения могут применяться к заданному пространству имен или ко всему кластеру. Дополнительные сведения см. в разделе Использование авторизации RBAC Kubernetes.

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

  3. Создайте файл с именем role-dev-namespace.yaml и вставьте следующий манифест YAML:

    kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: dev-user-full-access
  namespace: dev
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["*"]
  verbs: ["*"]
- apiGroups: ["batch"]
  resources:
  - jobs
  - cronjobs
  verbs: ["*"]

  4. Создайте роль с помощью команды kubectl apply и укажите имя файла манифеста YAML:

    kubectl apply -f role-dev-namespace.yaml

  5. Получите идентификатор ресурса для группы appdev с помощью команды az ad group show . Эта группа будет задана в качестве субъекта RoleBinding на следующем шаге:

    az ad group show --group appdev --query objectId -o tsv

    Команда az ad group show возвращает значение, которое будет использоваться как groupObjectId:

    38E5FA30-XXXX-4895-9A00-050712E3673A

  6. Создайте файл с именем rolebinding-dev-namespace.yaml и вставьте следующий манифест YAML. Вы устанавливаете привязку роли, которая позволяет группе appdev использовать роль для доступа к пространству role-dev-namespace имен. В последней строке замените groupObjectId идентификатором объекта группы, созданным командой az ad group show .

    kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: dev-user-access
  namespace: dev
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: dev-user-full-access
subjects:
- kind: Group
  namespace: dev
  name: groupObjectId

    Совет

    Если вы хотите создать RoleBinding для одного пользователя, укажите kind: User и замените groupObjectId именем участника-пользователя (UPN) в примере.

  7. Создайте RoleBinding с помощью команды kubectl apply и укажите имя файла манифеста YAML:

    kubectl apply -f rolebinding-dev-namespace.yaml

    rolebinding.rbac.authorization.k8s.io/dev-user-access created

Использование встроенных ролей RBAC Kubernetes для ресурса кластера AKS

Kubernetes также предоставляет встроенные роли для пользователей. К этим встроенным ролям относятся:

  • Роли суперпользовать (администратор кластера)
  • Роли, предназначенные для предоставления на уровне кластера с помощью ClusterRoleBindings
  • Роли, предназначенные для предоставления в определенных пространствах имен с помощью RoleBindings (администратор, редактирование, представление)

Дополнительные сведения о встроенных ролях RBAC Kubernetes см. в статье Роли, доступные для пользователей Kubernetes RBAC.

Роли для пользователей

ClusterRole по умолчанию ClusterRoleBinding по умолчанию Описание
администратор кластера группа system:master Позволяет суперпользовать доступ для выполнения любых действий с любым ресурсом. При использовании в ClusterRoleBinding эта роль предоставляет полный контроль над каждым ресурсом в кластере и во всех пространствах имен. При использовании в RoleBinding он предоставляет полный контроль над каждым ресурсом в пространстве имен привязки роли, включая само пространство имен.
admin Нет Разрешает доступ администратора, предназначенный для предоставления в пространстве имен с помощью привязки роли. При использовании в привязке роли разрешает доступ на чтение и запись к большинству ресурсов в пространстве имен, включая возможность создания ролей и привязок ролей в пространстве имен. Эта роль не разрешает доступ на запись к квоте ресурса или пространству имен. Эта роль также не разрешает доступ на запись к конечным точкам в кластерах, созданных с помощью Kubernetes версии 1.22+. Дополнительные сведения см. в разделе Доступ на запись для конечных точек.
изменение; Нет Разрешает доступ для чтения и записи к большинству объектов в пространстве имен. Эта роль не позволяет просматривать или изменять роли или привязки ролей. Однако эта роль позволяет получать доступ к секретам и запускать модули pod в качестве любой учетной записи ServiceAccount в пространстве имен, поэтому ее можно использовать для получения уровней доступа к API любой учетной записи ServiceAccount в пространстве имен. Эта роль также не разрешает доступ на запись к конечным точкам в кластерах, созданных с помощью Kubernetes версии 1.22+. Дополнительные сведения см. в разделе Доступ на запись для конечных точек.
представление Нет Разрешает доступ только для чтения, позволяя просматривать большинство объектов в пространстве имен. Оно не позволяет просматривать роли или привязки ролей. Эта роль не позволяет просматривать секреты, так как чтение содержимого секретов обеспечивает доступ к учетным данным ServiceAccount в пространстве имен, что разрешает доступ ЧЕРЕЗ API в качестве любой учетной записи ServiceAccount в пространстве имен (форма повышения привилегий).

Использование встроенной роли RBAC Kubernetes с Microsoft Entra ID

Чтобы использовать встроенную роль RBAC Kubernetes с Microsoft Entra ID, сделайте следующее:

  1. Примените встроенную view роль RBAC Kubernetes к группе Microsoft Entra:

    kubectl create clusterrolebinding <name of your cluster role binding> --clusterrole=view --group=<Azure AD group object ID>

  2. Примените встроенную view роль RBAC Kubernetes к каждому из пользователей Microsoft Entra:

    kubectl create clusterrolebinding <name of your cluster role binding> --clusterrole=view --user=<Azure AD user object ID>

Работа с ресурсами кластера с помощью Microsoft Entra удостоверений

Теперь проверьте ожидаемые разрешения при создании ресурсов и управлении ими в кластере Kubernetes. В этих примерах планируется и выполняется просмотр объектов pod в назначенном пользователю пространстве имен. Затем вы попытаетесь запланировать и просмотреть модули pod за пределами назначенного пространства имен.

  1. Войдите в Azure, используя $AKSDEV_ID учетную запись пользователя, переданную в качестве входных данных в az ad group member add команду. az connectedk8s proxy Выполните команду , чтобы открыть канал к кластеру:

    az connectedk8s proxy -n <cluster-name> -g <resource-group>

  2. После установки прокси-канала откройте еще один сеанс и запланируйте модуль pod NGINX с помощью команды kubectl run в пространстве имен разработки :

    kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev

    После успешного планирования NGINX вы увидите следующие выходные данные:

    pod/nginx-dev created

  3. Теперь используйте команду kubectl get pods , чтобы просмотреть объекты pod в dev пространстве имен:

    kubectl get pods --namespace dev

    Когда NGINX успешно выполняется, вы увидите следующие выходные данные:

    $ kubectl get pods --namespace dev

NAME        READY   STATUS    RESTARTS   AGE
nginx-dev   1/1     Running   0          4m

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

Чтобы попытаться просмотреть объекты pod за пределами пространства имен dev , используйте команду kubectl get pods с флагом --all-namespaces .

kubectl get pods --all-namespaces

Членство пользователя в группе не имеет роли Kubernetes, которая разрешает это действие. Без разрешения команда выдает ошибку.

Error from server (Forbidden): pods is forbidden: User cannot list resource "pods" in API group "" at the cluster scope

Дальнейшие действия