Управление доступом с помощью 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.
Create демонстрационной группы в 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
Create настраиваемую привязку роли RBAC Kubernetes к ресурсу кластера AKS для группы Microsoft Entra
Настройте кластер AKS, чтобы разрешить группе Microsoft Entra доступ к кластеру. Если вы хотите добавить группу и пользователей, см. раздел Create демонстрационных групп в Microsoft Entra ID.
Получите учетные данные администратора кластера с помощью команды Get-AksHciCredential :
Get-AksHciCredential -name <name-of-your-cluster>
Create пространство имен в кластере Kubernetes с помощью команды kubectl create namespace. В следующем примере создается пространство имен с именем
dev
:kubectl create namespace dev
В Kubernetes роли определяют разрешения для предоставления, а RoleBindings применяют разрешения к нужным пользователям или группам. Эти назначения могут применяться к заданному пространству имен или ко всему кластеру. Дополнительные сведения см. в разделе Использование авторизации RBAC Kubernetes.
Create роль для пространства имен разработки. Эта роль предоставляет полные разрешения на пространство имен. В рабочих средах может потребоваться указать более детализированные разрешения для разных пользователей или групп.
Create файл с именем 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: ["*"]
Create роль с помощью команды 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
Create файл с именем 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) в примере.Create 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 | None | Разрешает доступ администратора, предназначенный для предоставления в пространстве имен с помощью привязки роли. При использовании в привязке роли разрешает доступ на чтение и запись к большинству ресурсов в пространстве имен, включая возможность создания ролей и привязок ролей в пространстве имен. Эта роль не разрешает доступ на запись к квоте ресурса или пространству имен. Эта роль также не разрешает доступ на запись к конечным точкам в кластерах, созданных с помощью Kubernetes версии 1.22+. Дополнительные сведения см. в разделе Доступ на запись для конечных точек. |
изменение; | None | Разрешает доступ для чтения и записи к большинству объектов в пространстве имен. Эта роль не позволяет просматривать или изменять роли или привязки ролей. Однако эта роль позволяет получать доступ к секретам и запускать модули pod в качестве любой учетной записи ServiceAccount в пространстве имен, поэтому ее можно использовать для получения уровней доступа к API любой учетной записи ServiceAccount в пространстве имен. Эта роль также не разрешает доступ на запись к конечным точкам в кластерах, созданных с помощью Kubernetes версии 1.22+. Дополнительные сведения см. в разделе Доступ на запись для конечных точек. |
представление | None | Разрешает доступ только для чтения, позволяя просматривать большинство объектов в пространстве имен. Оно не позволяет просматривать роли или привязки ролей. Эта роль не позволяет просматривать секреты, так как чтение содержимого секретов обеспечивает доступ к учетным данным ServiceAccount в пространстве имен, что разрешает доступ ЧЕРЕЗ API в качестве любой учетной записи ServiceAccount в пространстве имен (форма повышения привилегий). |
Использование встроенной роли RBAC Kubernetes с Microsoft Entra ID
Чтобы использовать встроенную роль RBAC Kubernetes с Microsoft Entra ID, сделайте следующее:
Примените встроенную
view
роль RBAC Kubernetes к группе 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 успешно выполняется, вы увидите следующие выходные данные:
$ kubectl get pods --namespace dev NAME READY STATUS RESTARTS AGE nginx-dev 1/1 Running 0 4m
Create и просмотр ресурсов кластера за пределами назначенного пространства имен
Чтобы попытаться просмотреть объекты 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
Дальнейшие действия
Обратная связь
https://aka.ms/ContentUserFeedback.
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделеОтправить и просмотреть отзыв по