Управление доступом с помощью Azure AD и Служба Azure Kubernetes RBAC Kubernetes в Azure Stack HCI и Windows Server

  • Статья
  • Чтение занимает 8 мин

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

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

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

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

Прежде чем настроить Kubernetes RBAC с помощью удостоверения Azure AD, вам потребуется:

  • Кластер AKS с AKS в Azure Stack HCI и Windows Server

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

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

    Вам потребуется подключение Azure Arc к кластеру AKS в Azure Stack HCI и Windows Server. Инструкции по включению Azure Arc см. в статье "Подключение Служба Azure Kubernetes в кластере Azure Stack HCI к Kubernetes с поддержкой Azure Arc".

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

    • Azure CLI

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

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

    • Kubectl.

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

      Инструкции см. в kubectl.

    • PowerShell и модуль PowerShell AksHci

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

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

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

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

Создание демонстрационной группы в Azure AD

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

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

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

С помощью примера группы, созданной в Azure AD для разработчиков приложений, давайте добавим пользователя в группуappdev. Чтобы проверить интеграцию Kubernetes RBAC в конце статьи, войдите в кластер AKS с помощью этой учетной записи пользователя.

Добавьте пользователя в группу 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 для группы Azure AD

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

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

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

  2. Создайте пространство имен в кластере AKS с помощью команды 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. Создайте Role с помощью команды 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 вернет значение, которое будет использоваться в качестве groupObjectId.

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

  6. Создайте файл rolebinding-dev-namespace.yaml и вставьте в него следующий манифест YAML. Вы устанавливаете RoleBinding для группы 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 также предоставляет встроенные роли, доступные для пользователей. К этим встроенным ролям относятся:

  • Роли суперпользоваемых пользователей (cluster-admin)
  • Роли, предназначенные для предоставления кластеру на уровне кластера с помощью ClusterRoleBindings
  • Роли, которые должны быть предоставлены в определенных пространствах имен с помощью RoleBindings (admin, edit, view)

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

Роли, доступные для пользователей

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

Использование встроенной роли RBAC Kubernetes с Azure AD

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

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

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

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

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

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

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

    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 за пределами пространства имен разработки . Используйте команду 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

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

Дополнительные сведения о безопасности с помощью AKS в Azure Stack HCI и Windows Server см. в статье "Безопасность в AKS в Azure Stack HCI и Windows Server"