Управление доступом с помощью идентификатора Microsoft Entra и RBAC Kubernetes для Windows Server
Область применения: AKS в Azure Local 22H2, AKS на Windows Server
Служба Azure Kubernetes (AKS) можно настроить для использования идентификатора Microsoft Entra для проверки подлинности пользователей. В этой конфигурации вы входите в кластер Kubernetes с помощью маркера проверки подлинности Microsoft Entra. После проведения проверки подлинности вы можете использовать встроенное управление доступом на основе ролей Kubernetes (Kubernetes RBAC) для управления доступом к пространствам имен и ресурсам кластера на основе идентификатора пользователя или членства в группе.
В этой статье описывается, как управлять доступом с помощью RBAC Kubernetes в кластере Kubernetes на основе членства в группе Microsoft Entra в AKS Arc. Вы создаете демонстрационную группу и пользователей в идентификаторе Microsoft Entra. Затем вы создадите роли и привязки ролей в кластере, чтобы предоставить соответствующие разрешения для создания и просмотра ресурсов.
Необходимые компоненты
Перед настройкой Kubernetes RBAC с помощью идентификатора Microsoft Entra необходимо выполнить следующие предварительные требования:
- Кластер Kubernetes, созданный в AKS Arc. Если вам нужно настроить кластер, см. инструкции по развертыванию AKS с помощью Центра администрирования Windows или PowerShell .
- Подключение к Azure Arc. Необходимо подключить Azure Arc к кластеру Kubernetes. Сведения о включении Azure Arc см. в статье "Подключение Служба Azure Kubernetes в локальном кластере Azure к Kubernetes с поддержкой Azure Arc".
- Вам нужен доступ к следующим средствам командной строки:
-
Azure CLI и расширение connectedk8s. Azure CLI — это набор команд, используемых для создания ресурсов Azure и управления ими. Чтобы проверить наличие Azure CLI, откройте программу командной строки и введите:
az -v
Кроме того, установите расширение connectedk8s, чтобы открыть канал в кластере Kubernetes. Инструкции по установке см. в статье "Установка Azure CLI". -
Kubectl. Это средство командной строки Kubernetes позволяет выполнять команды, предназначенные для кластеров Kubernetes. Чтобы проверить, установлен ли kubectl, откройте командную строку и введите:
kubectl version --client
Убедитесь, что версия клиента kubectl не ниже версии 1.24.0. Инструкции по установке см. в kubectl. - PowerShell и модуль AksHci PowerShell. PowerShell — это кроссплатформенное решение автоматизации задач, состоящее из оболочки командной строки, языка сценариев и платформы управления конфигурацией. Если вы установили AKS Arc, у вас есть доступ к модулю AksHci PowerShell.
- Чтобы получить доступ к кластеру Kubernetes из любого места с помощью команды прокси-сервера
az connectedk8s proxy
, вам потребуется разрешение на роль пользователя кластера Kubernetes с поддержкой Microsoft.Kubernetes/connectedClusterUserCredential/action с поддержкой Azure Arc. Между тем необходимо убедиться, что агенты и компьютер, выполняющие процесс подключения, соответствуют требованиям сети в требованиях к сети с поддержкой Azure Arc Kubernetes.
-
Azure CLI и расширение connectedk8s. Azure CLI — это набор команд, используемых для создания ресурсов Azure и управления ими. Чтобы проверить наличие Azure CLI, откройте программу командной строки и введите:
Необязательные первые шаги
Если у вас еще нет группы Microsoft Entra, содержащей участников, может потребоваться создать группу и добавить некоторых участников, чтобы следовать инструкциям в этой статье.
Чтобы продемонстрировать работу с идентификатором Microsoft Entra и Kubernetes RBAC, можно создать группу Microsoft Entra для разработчиков приложений, которые можно использовать для демонстрации того, как Kubernetes RBAC и Microsoft Entra ID управляют доступом к ресурсам кластера. В рабочих средах можно использовать существующих пользователей и групп в клиенте Microsoft Entra.
Создание демонстрационной группы в идентификаторе Microsoft Entra
Сначала создайте группу в идентификаторе Microsoft Entra в клиенте для разработчиков приложений az ad group create
с помощью команды. В следующем примере показано, как войти в клиент Azure, а затем создать группу с именем appdev:
az login
az ad group create --display-name appdev --mail-nickname appdev
Добавление пользователей в группу
С помощью примера группы, созданной в идентификаторе Microsoft Entra для разработчиков приложений, добавьте пользователя в группу 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.
Получите учетные данные администратора кластера с помощью
Get-AksHciCredential
команды:Get-AksHciCredential -name <name-of-your-cluster>
Создайте пространство имен в кластере Kubernetes с помощью
kubectl create namespace
команды. В следующем примере создается пространство имен с именемdev
:kubectl create namespace dev
В Kubernetes роли определяют разрешения для предоставления, а RoleBindings применяют разрешения для нужных пользователей или групп. Эти назначения можно применять к заданному пространству имен или всему кластеру. Дополнительные сведения см. в разделе Использование авторизации RBAC Kubernetes.
Создайте роль для пространства имен разработки. Эта роль предоставляет полные разрешения на пространство имен. В рабочих средах может потребоваться указать более детализированные разрешения для разных пользователей или групп.
Создайте файл с именем 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: ["*"]
Создайте роль с помощью
kubectl apply
команды и укажите имя файла манифеста YAML:kubectl apply -f role-dev-namespace.yaml
Получите идентификатор ресурса для группы 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
Создайте файл с именем 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) в примере.Создайте RoleBinding с помощью
kubectl apply
команды и укажите имя файла манифеста YAML:kubectl apply -f rolebinding-dev-namespace.yaml
rolebinding.rbac.authorization.k8s.io/dev-user-access created
Использование встроенных ролей RBAC Kubernetes для ресурса кластера AKS
Kubernetes также предоставляет встроенные роли, доступные для пользователей. К этим встроенным ролям относятся следующие:
- Роли суперпользоваемых пользователей (cluster-admin)
- Роли, предназначенные для предоставления кластеру на уровне кластера с помощью ClusterRoleBindings
- Роли, предназначенные для предоставления в определенных пространствах имен с помощью RoleBindings (администратор, изменение, просмотр)
Дополнительные сведения о встроенных ролях RBAC Kubernetes см. в статье о ролях, доступных для пользователей Kubernetes RBAC.
Роли, доступные для пользователей
ClusterRole по умолчанию | ClusterRoleBinding по умолчанию | Description |
---|---|---|
администратор кластера | system:master group | Позволяет суперпользовательскому доступу выполнять любое действие в любом ресурсе. При использовании в ClusterRoleBinding эта роль обеспечивает полный контроль над каждым ресурсом в кластере и во всех пространствах имен. При использовании в RoleBinding он обеспечивает полный контроль над каждым ресурсом в пространстве имен привязки роли, включая само пространство имен. |
администрирование | нет | Разрешает администратору доступ, предназначенный для предоставления в пространстве имен с помощью привязки роли. При использовании в привязке ролей разрешает доступ на чтение и запись к большинству ресурсов в пространстве имен, включая возможность создания ролей и привязок ролей в пространстве имен. Эта роль не разрешает доступ на запись к квоте ресурса или пространству имен. Эта роль также не разрешает доступ на запись к конечным точкам в кластерах, созданных с помощью Kubernetes версии 1.22+. Дополнительные сведения см. в разделе "Доступ на запись для конечных точек". |
изменить | нет | Разрешает доступ для чтения и записи к большинству объектов в пространстве имен. Эта роль не позволяет просматривать или изменять роли или привязки ролей. Однако эта роль позволяет получать доступ к секретам и запускать pod как любой ServiceAccount в пространстве имен, поэтому его можно использовать для получения уровней доступа к API любого ServiceAccount в пространстве имен. Эта роль также не разрешает доступ на запись к конечным точкам в кластерах, созданных с помощью Kubernetes версии 1.22+. Дополнительные сведения см. в разделе "Доступ на запись для конечных точек". |
view | нет | Разрешает доступ только для чтения, позволяя просматривать большинство объектов в пространстве имен. Оно не позволяет просматривать роли или привязки ролей. Эта роль не позволяет просматривать секреты, так как чтение содержимого секретов обеспечивает доступ к учетным данным ServiceAccount в пространстве имен, что позволит API получить доступ как к любому ServiceAccount в пространстве имен (форма эскалации привилегий). |
Использование встроенной роли Kubernetes RBAC с идентификатором Microsoft Entra
Чтобы использовать встроенную роль Kubernetes RBAC с идентификатором Microsoft Entra, выполните следующие действия:
Примените встроенную
view
роль Kubernetes RBAC к группе Microsoft Entra:kubectl create clusterrolebinding <name of your cluster role binding> --clusterrole=view --group=<Azure AD group object ID>
Примените встроенную
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 за пределами назначенного пространства имен.
Войдите в Azure с помощью
$AKSDEV_ID
учетной записи пользователя, указанной в качестве входных данных вaz ad group member add
команду.az connectedk8s proxy
Выполните команду, чтобы открыть канал в кластере:az connectedk8s proxy -n <cluster-name> -g <resource-group>
После установки прокси-канала откройте другой сеанс и запланируйте 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
Теперь используйте
kubectl get pods
команду для просмотра модулей pod вdev
пространстве имен:kubectl get pods --namespace dev
При успешном выполнении NGINX вы увидите следующие выходные данные:
NAME READY STATUS RESTARTS AGE nginx-dev 1/1 Running 0 4m
Создание и просмотр ресурсов кластера за пределами назначенного пространства имен
Чтобы попытаться просмотреть модули pod за пределами пространства имен разработки , используйте 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