Поделиться через

Использование управления доступом на основе ролей Azure для авторизации Kubernetes

  • Статья

В этой статье описывается, как использовать Azure RBAC для авторизации Kubernetes, которая обеспечивает унифицированное управление и управление доступом в ресурсах Azure, AKS и Kubernetes. Дополнительные сведения см. в статье Azure RBAC для авторизации Kubernetes.

Примечание.

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

Подготовка к работе

  • Вам потребуется azure CLI версии 2.24.0 или более поздней версии. Чтобы узнать версию, выполните команду az --version. Если вам необходимо выполнить установку или обновление, см. статью Установка Azure CLI 2.0.
  • Вам нужна kubectlминимальная версия 1.18.3.
  • Чтобы добавить azure RBAC для авторизации Kubernetes, необходимо включить интеграцию Microsoft Entra в кластере. Если необходимо включить управляемую интеграцию Microsoft Entra, см. раздел "Использование идентификатора Microsoft Entra в AKS".
  • Если у вас есть crD и создаются пользовательские определения ролей, единственным способом покрытия CRD сегодня является использование Microsoft.ContainerService/managedClusters/*/read. Для оставшихся объектов можно использовать определенные группы API, например Microsoft.ContainerService/apps/deployments/read.
  • Новые назначения ролей могут занять до пяти минут для распространения и обновления сервером авторизации.
  • Azure RBAC для авторизации Kubernetes требует, чтобы клиент Microsoft Entra, настроенный для проверки подлинности, совпадал с клиентом для подписки, содержащей кластер AKS.

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

  1. Создайте группу ресурсов Azure с помощью az group create команды.

    export RESOURCE_GROUP=<resource-group-name>
export LOCATION=<azure-region>

az group create --name $RESOURCE_GROUP --location $LOCATION

  2. Создайте кластер AKS с управляемой интеграцией Microsoft Entra и Azure RBAC для авторизации Kubernetes с помощью az aks create команды.

    export CLUSTER_NAME=<cluster-name>

az aks create \
    --resource-group $RESOURCE_GROUP \
    --name $CLUSTER_NAME \
    --enable-aad \
    --enable-azure-rbac \
    --generate-ssh-keys

    Выходные данные должны выглядеть примерно так:

    "AADProfile": {
    "adminGroupObjectIds": null,
    "clientAppId": null,
    "enableAzureRbac": true,
    "managed": true,
    "serverAppId": null,
    "serverAppSecret": null,
    "tenantId": "****-****-****-****-****"
}

Включение Azure RBAC в существующем кластере AKS

  • Включите авторизацию Azure RBAC для Kubernetes в существующем кластере AKS с помощью az aks update команды с флагом --enable-azure-rbac .

    az aks update --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --enable-azure-rbac

Отключение авторизации Azure RBAC для Kubernetes из кластера AKS

  • Удалите Azure RBAC для авторизации Kubernetes из существующего кластера AKS с помощью az aks update команды с флагом --disable-azure-rbac .

    az aks update --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --disable-azure-rbac

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

AKS предоставляет следующие встроенные роли:

Роль Description
Читатель RBAC для Службы контейнеров Azure Разрешает доступ только для чтения, позволяя просматривать большинство объектов в пространстве имен. Оно не позволяет просматривать роли или привязки ролей. Эта роль не разрешает просмотр Secrets, так как чтение содержимого секретов обеспечивает доступ к учетным данным ServiceAccount в пространстве имен, что позволит API получить доступ как к любому ServiceAccount в пространстве имен (форма эскалации привилегий).
Модуль записи RBAC для службы Azure Kubernetes Разрешает доступ для чтения и записи к большинству объектов в пространстве имен. Эта роль не позволяет просматривать или изменять роли или привязки ролей. Однако эта роль позволяет получить доступ к Secrets и запускать поды как любую учетную запись службы в пространстве имен. Поэтому эту роль можно использовать для получения уровней доступа API любой учетной записи службы в пространстве имен.
Администратор RBAC для службы Azure Kubernetes Предоставляет административный доступ, предназначенный для предоставления в пространстве имен. Разрешает доступ для чтения и записи к большинству ресурсов в пространстве имен (или области кластера), включая возможность создания ролей и привязок ролей в пространстве имен. Эта роль не разрешает доступ на запись к квоте ресурса или пространству имен.
Администратор кластера RBAC для службы Azure Kubernetes Разрешает доступ суперпользователя для выполнения любых действий с любым ресурсом. Он предоставляет полный контроль над каждым ресурсом в кластере и во всех пространствах имен.

Создание назначений ролей для доступа к кластеру

  1. Получите идентификатор ресурса AKS с помощью az aks show команды.

    AKS_ID=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query id --output tsv)

  2. Создайте назначение роли с помощью az role assignment create команды. <AAD-ENTITY-ID> может быть именем пользователя или идентификатором клиента субъекта-службы. В следующем примере создается назначение ролей для роли администратора RBAC Служба Azure Kubernetes.

    az role assignment create --role "Azure Kubernetes Service RBAC Admin" --assignee <AAD-ENTITY-ID> --scope $AKS_ID

    Примечание.

    Вы можете создать Служба Azure Kubernetes средство чтения RBAC и Служба Azure Kubernetes назначения ролей записи RBAC в определенном пространстве имен в кластере с помощью az role assignment create команды и задания области в нужном пространстве имен.

    az role assignment create --role "Azure Kubernetes Service RBAC Reader" --assignee <AAD-ENTITY-ID> --scope $AKS_ID/namespaces/<namespace-name>

Создание определений настраиваемых ролей

В следующем примере определение пользовательской роли позволяет пользователю читать только развертывания и ничего другого. Полный список возможных действий см. в разделе "Операции Microsoft.ContainerService".

  1. Чтобы создать собственные определения пользовательских ролей, скопируйте следующий файл, заменив <YOUR SUBSCRIPTION ID> собственный идентификатор подписки, а затем сохраните его как deploy-view.json.

    {
    "Name": "AKS Deployment Reader",
    "Description": "Lets you view all deployments in cluster/namespace.",
    "Actions": [],
    "NotActions": [],
    "DataActions": [
        "Microsoft.ContainerService/managedClusters/apps/deployments/read"
    ],
    "NotDataActions": [],
    "assignableScopes": [
        "/subscriptions/<YOUR SUBSCRIPTION ID>"
    ]
}

  2. Создайте определение роли с помощью az role definition create команды, задав --role-definitiondeploy-view.json файл, созданный на предыдущем шаге.

    az role definition create --role-definition @deploy-view.json

  3. Назначьте определение роли пользователю или другому удостоверению с помощью az role assignment create команды.

    az role assignment create --role "AKS Deployment Reader" --assignee <AAD-ENTITY-ID> --scope $AKS_ID

Использование Azure RBAC для авторизации Kubernetes с помощью kubectl

  1. Убедитесь, что у вас есть встроенная роль Служба Azure Kubernetes кластерного пользователя, а затем получите kubeconfig кластера AKS с помощью az aks get-credentials команды.

    az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME

  2. Теперь вы можете kubectl управлять кластером. Например, можно перечислить узлы в кластере с помощью kubectl get nodes.

    kubectl get nodes

    Пример результата:

    NAME                                STATUS   ROLES   AGE    VERSION
aks-nodepool1-93451573-vmss000000   Ready    agent   3h6m   v1.15.11
aks-nodepool1-93451573-vmss000001   Ready    agent   3h6m   v1.15.11
aks-nodepool1-93451573-vmss000002   Ready    agent   3h6m   v1.15.11

Использование Azure RBAC для авторизации Kubernetes с помощью kubelogin

AKS создал подключаемый kubelogin модуль для разблокировки таких сценариев, как неинтерактивные имена входа, старые kubectl версии или использование единого входа в нескольких кластерах без необходимости входа в новый кластер.

  1. Используйте подключаемый kubelogin модуль, выполнив следующую команду:

    export KUBECONFIG=/path/to/kubeconfig
kubelogin convert-kubeconfig

  2. Теперь вы можете kubectl управлять кластером. Например, можно перечислить узлы в кластере с помощью kubectl get nodes.

    kubectl get nodes

    Пример результата:

    NAME                                STATUS   ROLES   AGE    VERSION
aks-nodepool1-93451573-vmss000000   Ready    agent   3h6m   v1.15.11
aks-nodepool1-93451573-vmss000001   Ready    agent   3h6m   v1.15.11
aks-nodepool1-93451573-vmss000002   Ready    agent   3h6m   v1.15.11

Очистка ресурсов

Удаление назначения роли

  1. Вывод списка назначений ролей с помощью az role assignment list команды.

    az role assignment list --scope $AKS_ID --query [].id --output tsv

  2. Удалите назначения ролей с помощью az role assignment delete команды.

    az role assignment delete --ids <LIST OF ASSIGNMENT IDS>

Удаление определения роли

  • Удалите определение пользовательской роли с помощью az role definition delete команды.

    az role definition delete --name "AKS Deployment Reader"

Удаление группы ресурсов и кластера AKS

  • Удалите группу ресурсов и кластер AKS с помощью az group delete команды.

    az group delete --name $RESOURCE_GROUP --yes --no-wait

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

Дополнительные сведения о проверке подлинности AKS, авторизации, Kubernetes RBAC и Azure RBAC см. в следующем разделе: