Access and identity options for Azure Kubernetes Service (AKS) (Возможности контроля доступа и идентификации в Службе Azure Kubernetes (AKS))

Статья
08/02/2024

Вы можете пройти проверку подлинности, авторизовать, защитить и контролировать доступ к кластерам Kubernetes различными способами:

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

Kubernetes RBAC и AKS помогут защитить доступ к кластеру и предоставить только минимально необходимые разрешения для разработчиков и операторов.

В этой статье рассматриваются основные понятия, которые помогут выполнить проверку подлинности и назначить разрешения в AKS:

Kubernetes RBAC

Kubernetes RBAC обеспечивает детализированную фильтрацию действий пользователя. С помощью этого механизма управления:

Можно выдавать отдельным пользователям или группам пользователей разрешения на создание и изменение ресурсов или просмотр журналов запущенных приложений.
Эти разрешения могут распространяться на отдельное пространство имен или весь кластер AKS.
Можно создавать роли, чтобы определить разрешения, и затем назначить эти роли пользователям с помощью привязки ролей.

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

Элементы Role и ClusterRole

Роли

Прежде чем выдавать разрешения пользователям с помощью Kubernetes RBAC, необходимо задать разрешения в качестве роли. Предоставьте разрешения в пространстве имен с помощью ролей.

Примечание.

Роли Kubernetes предоставляют разрешения; они не отклоняют разрешения.

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

ClusterRole

ClusterRole выдает и применяет разрешения к ресурсам в пределах кластера, а не в определенном пространстве имен.

Элементы RoleBinding и ClusterRoleBinding

После определения ролей для разрешений на доступ к ресурсам эти разрешения RBAC Kubernetes можно назначить с помощью элемента RoleBinding. Если кластер AKS интегрируется с идентификатором Microsoft Entra, RoleBindings предоставляет пользователям Microsoft Entra разрешения на выполнение действий в кластере. Узнайте, как управлять доступом к ресурсам кластера с помощью управления доступом на основе ролей Kubernetes и удостоверений Microsoft Entra.

RoleBinding

Назначение ролей пользователям в заданном пространстве имен с помощью RoleBinding. С помощью RoleBinding можно логически выделить один кластер AKS и разрешить пользователям доступ к ресурсам приложения в назначенном им пространстве имен.

Если вам нужно привязать роли для доступа в пределах всего кластера или для доступа к кластерным ресурсам за пределами определенного пространства имен, можно использовать элементы ClusterRoleBinding.

ClusterRoleBinding

С помощью ClusterRoleBinding можно привязать роли к пользователям и применить к ресурсам в пределах всего кластера, а не в определенном пространстве имен. Такой подход позволяет предоставить администраторам или инженерам службы поддержки доступ ко всем ресурсам в кластере AKS.

Примечание.

Microsoft/AKS выполняет все операции в кластере с согласия пользователя с учетом встроенной роли Kubernetes aks-service и привязки встроенной роли aks-service-rolebinding.

Эта роль позволяет AKS устранять неполадки в работе кластера и диагностировать их, но она не может изменять разрешения и создавать роли или привязки ролей, а также осуществлять другие действия с высоким уровнем привилегий. Доступ к роли возможен только в рамках активных запросов в службу поддержки с JIT-доступом. Узнайте больше о политиках поддержки AKS.

Учетные записи службы Kubernetes

Учетные записи службы – один из основных типов пользователей в Kubernetes. API Kubernetes содержит учетные записи служб и управляет ими. Данные для входа в учетные записи службы хранятся в виде секретов Kubernetes, что позволяет авторизованным элементам pod использовать их для взаимодействия с сервером API. Большинство запросов к API содержат маркер аутентификации для учетной записи службы или обычной учетной записи пользователя.

Обычные учетные записи пользователя обеспечивают более традиционный доступ администраторов или разработчиков, а не только служб и процессов. Kubernetes не предоставляет решение по управлению удостоверениями для хранения обычных учетных записей пользователей и паролей, однако вы можете интегрировать внешние решения по управлению удостоверениями в Kubernetes. Для кластеров AKS это интегрированное решение для удостоверений — это идентификатор Microsoft Entra.

Дополнительные сведения о возможностях идентификации в Kubernetes см. в разделе об аутентификации Kubernetes.

Управление доступом на основе ролей Azure

Управление доступом на основе ролей в Azure (RBAC) — это система авторизации на базе Azure Resource Manager, которая обеспечивает управление доступом к ресурсам Azure на высоком уровне детализации.

Система RBAC	Description
Kubernetes RBAC	Предназначена для работы с ресурсами Kubernetes в кластере AKS.
Azure RBAC	Предназначена для работы с ресурсами в подписке Azure.

С помощью управления доступом на основе ролей Azure можно создать определение роли, описывающее предоставляемые разрешения. Затем назначьте пользователю или группе это определение роли с помощью функции назначения ролей для определенной области. Областью может быть отдельный ресурс, группа ресурсов или подписка.

Общие сведения см. в статье Что такое управление доступом на основе ролей в Azure (Azure RBAC)?

Для полноценной работы кластера AKS требуется два уровня доступа:

Доступ к ресурсу AKS в подписке Azure.
- Управление масштабированием или обновлением кластера с помощью API-интерфейсов AKS.
- извлекатьkubeconfig.
Доступ к API Kubernetes. Этот доступ контролируется следующим образом:
- Kubernetes RBAC (традиционный инструмент).
- Интеграция Azure RBAC с AKS для авторизации Kubernetes.

Azure RBAC для авторизации доступа к ресурсу AKS

С помощью Azure RBAC вы можете предоставить пользователям (или удостоверениям) детализированный доступ к ресурсам AKS в одной или нескольких подписках. Например, вы можете использовать роль участника службы Azure Kubernetes для масштабирования и обновления кластера. В то же время другой пользователь с ролью администратора кластера службы Azure Kubernetes имеет только разрешение на запрос администратора kubeconfig.

Используйте Azure RBAC для определения доступа к файлу конфигурации Kubernetes в AKS.

Azure RBAC для авторизации в Kubernetes

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

Azure RBAC для потока авторизации Kubernetes

Как показано на приведенной выше схеме, при использовании интеграции Azure RBAC все запросы к API Kubernetes будут следовать тому же потоку проверки подлинности, как описано в разделе интеграции Microsoft Entra.

Если удостоверение, выполнявшее запрос, существует в идентификаторе Microsoft Entra, Azure будет работать с Kubernetes RBAC для авторизации запроса. Если удостоверение существует за пределами идентификатора Microsoft Entra (т. е. учетной записи службы Kubernetes), авторизация отложится до обычного RBAC Kubernetes.

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

С помощью этой функции вы не только предоставляете пользователям разрешения на доступ к ресурсу AKS в подписках, но и настраиваете роль и разрешения для каждого из кластеров, управляющих доступом к API Kubernetes. Например, можно предоставить роль Azure Kubernetes Service RBAC Reader в пределах подписки. Получатель роли сможет перечислить и получить все объекты Kubernetes из всех кластеров, не изменяя их.

Внимание

Перед использованием этой функции необходимо включить Azure RBAC для авторизации Kubernetes. Дополнительные сведения и пошаговое руководство см. в руководстве Авторизация в Kubernetes с помощью Azure RBAC.

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

AKS предоставляет следующие четыре встроенные роли. Они аналогичны встроенным ролям Kubernetes, но имеют некоторые отличия, например поддержку файлов CRD. См. полный список действий, разрешенных каждой встроенной ролью Azure.

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

Интеграция с Microsoft Entra

Повышение безопасности кластера AKS с помощью интеграции Microsoft Entra. На основе десятилетий корпоративного управления удостоверениями Идентификатор Microsoft Entra — это мультитенантная облачная служба каталогов и служба управления удостоверениями, которая объединяет основные службы каталогов, управление доступом приложений и защиту идентификации. С помощью идентификатора Microsoft Entra можно интегрировать локальные удостоверения в кластеры AKS, чтобы предоставить один источник для управления учетными записями и безопасности.

Интеграция Microsoft Entra с кластерами AKS

С помощью интегрированных кластеров AKS Microsoft Entra можно предоставить пользователям или группам доступ к ресурсам Kubernetes в пространстве имен или в кластере.

Для получения контекста конфигурации kubectl пользователь может выполнить команду az aks get-credentials.
Когда пользователь взаимодействует с кластером AKS, kubectlим будет предложено войти с помощью учетных данных Microsoft Entra.

Такой подход обеспечивает единый источник для управления учетными записями пользователя и хранения паролей. Пользователь имеет доступ только к ресурсам, определенным администратором кластера.

Проверка подлинности Microsoft Entra предоставляется кластерам AKS с помощью OpenID Connect. OpenID Connect представляет собой уровень идентификации на основе протокола OAuth 2.0. Дополнительные сведения о OpenID Connect см. в документации по OpenID Connect. Внутри кластера Kubernetes проверка подлинности на основе маркера веб-перехватчика используется для проверки маркеров проверки подлинности. Настройка такой проверка подлинности и ее управление являются частью кластера AKS.

Сервер веб-перехватчика и API

Поток проверки подлинности веб-перехватчика и сервера API

Как показано на схеме выше, сервер API вызывает сервер веб-перехватчика AKS и выполняет следующие действия.

kubectl использует клиентское приложение Microsoft Entra для входа пользователей с помощью потока предоставления авторизации устройства OAuth 2.0.
Идентификатор Microsoft Entra предоставляет access_token, id_token и refresh_token.
Пользователь отправляет запрос в kubectl с помощью команды access_token из kubeconfig.
kubectl отправляет access_token на сервер API.
Сервер API настроен с сервером веб-перехватчика проверки подлинности для выполнения проверки.
Сервер веб-перехватчика проверки подлинности подтверждает, что подпись веб-токена JSON действительна, проверив открытый ключ подписи Microsoft Entra.
Серверное приложение использует предоставленные пользователем учетные данные для запроса членства в группе пользователя, вошедшего в систему, из MS API Graph.
Ответ отправляется на сервер API со сведениями о пользователе, такими как утверждение имени участника-пользователя (UPN) маркера доступа и членство пользователя в группе на основе идентификатора объекта.
API выполняет решение авторизации на основе роли или привязки роли Kubernetes.
После авторизации сервер API возвращает ответ в kubectl.
kubectl предоставляет пользователю обратную связь.

Узнайте, как интегрировать AKS с Идентификатором Microsoft Entra с руководством по интеграции Microsoft Entra, управляемого AKS.

Разрешения службы AKS

При создании кластера AKS создает или изменяет необходимые ресурсы (например, виртуальные машины и сетевые карты) для создания и запуска кластера от имени пользователя. Это удостоверение отличается от разрешения удостоверения кластера, которое создается во время создания кластера.

Удостоверение, создающее и использующее разрешения кластера

Для удостоверения, создающего и использующего кластер, необходимы следующие разрешения.

Разрешение	Причина
`Microsoft.Compute/diskEncryptionSets/read`	Требуется для чтения идентификатора набора шифрования диска.
`Microsoft.Compute/proximityPlacementGroups/write`	Требуется для обновления групп размещения близкого взаимодействия.
`Microsoft.Network/applicationGateways/read` `Microsoft.Network/applicationGateways/write` `Microsoft.Network/virtualNetworks/subnets/join/action`	Требуется для настройки шлюзов приложений и присоединения к подсети.
`Microsoft.Network/virtualNetworks/subnets/join/action`	Требуется для настройки группы безопасности сети для подсети при использовании настраиваемой виртуальной сети.
`Microsoft.Network/publicIPAddresses/join/action` `Microsoft.Network/publicIPPrefixes/join/action`	Требуется для настройки исходящих общедоступных IP-адресов на Load Balancer (цен. категория "Стандартный").
`Microsoft.OperationalInsights/workspaces/sharedkeys/read` `Microsoft.OperationalInsights/workspaces/read` `Microsoft.OperationsManagement/solutions/write` `Microsoft.OperationsManagement/solutions/read` `Microsoft.ManagedIdentity/userAssignedIdentities/assign/action`	Требуется для создания и обновления рабочих областей Log Analytics и мониторинга Azure для использования контейнеров.
`Microsoft.Network/virtualNetworks/joinLoadBalancer/action`	Требуется настроить серверные пулы подсистемы балансировки нагрузки на основе IP-адресов.

Разрешения для удостоверения кластера AKS

С помощью удостоверения кластера AKS, которое создается и связывается с кластером AKS, используются следующие разрешения. Каждое разрешение используется по следующим причинам.

Разрешение	Причина
`Microsoft.ContainerService/managedClusters/*`	Требуется для создания пользователей и работы с кластером
`Microsoft.Network/loadBalancers/delete` `Microsoft.Network/loadBalancers/read` `Microsoft.Network/loadBalancers/write`	Требуется для настройки подсистемы балансировки нагрузки для службы LoadBalancer.
`Microsoft.Network/publicIPAddresses/delete` `Microsoft.Network/publicIPAddresses/read` `Microsoft.Network/publicIPAddresses/write`	Требуется для поиска и настройки общедоступных IP-адресов для службы LoadBalancer.
`Microsoft.Network/publicIPAddresses/join/action`	Требуется для настройки общедоступных IP-адресов для службы LoadBalancer.
`Microsoft.Network/networkSecurityGroups/read` `Microsoft.Network/networkSecurityGroups/write`	Требуется для создания или удаления правил безопасности для службы LoadBalancer.
`Microsoft.Compute/disks/delete` `Microsoft.Compute/disks/read` `Microsoft.Compute/disks/write` `Microsoft.Compute/locations/DiskOperations/read`	Требуется для настройки дисков AzureDisks.
`Microsoft.Storage/storageAccounts/delete` `Microsoft.Storage/storageAccounts/listKeys/action` `Microsoft.Storage/storageAccounts/read` `Microsoft.Storage/storageAccounts/write` `Microsoft.Storage/operations/read`	Требуется для настройки учетных записей хранения для файла AzureFile или дика AzureDisk.
`Microsoft.Network/routeTables/read` `Microsoft.Network/routeTables/routes/delete` `Microsoft.Network/routeTables/routes/read` `Microsoft.Network/routeTables/routes/write` `Microsoft.Network/routeTables/write`	Требуется для настройки таблиц маршрутов и маршрутов узлов.
`Microsoft.Compute/virtualMachines/read`	Требуется для поиска сведений о виртуальных машинах в VMAS, таких как зоны, домен сбоя, размер и диски данных.
`Microsoft.Compute/virtualMachines/write`	Требуется для присоединения дисков AzureDisks к виртуальной машине в VMAS.
`Microsoft.Compute/virtualMachineScaleSets/read` `Microsoft.Compute/virtualMachineScaleSets/virtualMachines/read` `Microsoft.Compute/virtualMachineScaleSets/virtualmachines/instanceView/read`	Требуется для поиска сведений о виртуальных машинах в масштабируемом наборе виртуальных машин, таких как зоны, домен сбоя, размер и диски данных.
`Microsoft.Network/networkInterfaces/write`	Требуется для добавления виртуальной машины в VMAS в серверный пул адресов подсистемы балансировки нагрузки.
`Microsoft.Compute/virtualMachineScaleSets/write`	Требуется для добавления масштабируемого набора виртуальных машин к серверным пулам адресов подсистемы балансировки нагрузки и узлам масштабирования в масштабируемом наборе виртуальных машин.
`Microsoft.Compute/virtualMachineScaleSets/delete`	Требуется для удаления масштабируемого набора виртуальных машин для внутренних пулов адресов подсистемы балансировки нагрузки и уменьшения масштаба узлов в масштабируемом наборе виртуальных машин.
`Microsoft.Compute/virtualMachineScaleSets/virtualmachines/write`	Требуется для присоединения AzureDisks и добавления виртуальной машины из масштабируемого набора виртуальных машин в подсистему балансировки нагрузки.
`Microsoft.Network/networkInterfaces/read`	Требуется для поиска внутренних IP-адресов и серверных пулов адресов подсистемы балансировки нагрузки для виртуальных машин в VMAS.
`Microsoft.Compute/virtualMachineScaleSets/virtualMachines/networkInterfaces/read`	Требуется для поиска внутренних IP-адресов и серверных пулов адресов подсистемы балансировки нагрузки для виртуальной машины в масштабируемом наборе виртуальных машин.
`Microsoft.Compute/virtualMachineScaleSets/virtualMachines/networkInterfaces/ipconfigurations/publicipaddresses/read`	Требуется для поиска общедоступных IP-адресов виртуальной машины в масштабируемом наборе виртуальных машин.
`Microsoft.Network/virtualNetworks/read` `Microsoft.Network/virtualNetworks/subnets/read`	Требуется для проверки наличия подсети для внутренней подсистемы балансировки нагрузки в другой группе ресурсов.
`Microsoft.Compute/snapshots/delete` `Microsoft.Compute/snapshots/read` `Microsoft.Compute/snapshots/write`	Требуется для настройки моментальных снимков AzureDisk.
`Microsoft.Compute/locations/vmSizes/read` `Microsoft.Compute/locations/operations/read`	Требуется для поиска размеров виртуальных машин и ограничений томов AzureDisk.

Дополнительные разрешения для удостоверения кластера

При создании кластера с конкретными атрибутами требуются следующие дополнительные разрешения для удостоверения кластера. Эти разрешения не назначаются автоматически, поэтому их необходимо добавить в удостоверение кластера после создания.

Разрешение	Причина
`Microsoft.Network/networkSecurityGroups/write` `Microsoft.Network/networkSecurityGroups/read`	Требуется при использовании группы безопасности сети в другой группе ресурсов. Требуется для создания правил безопасности для службы LoadBalancer.
`Microsoft.Network/virtualNetworks/subnets/read` `Microsoft.Network/virtualNetworks/subnets/join/action`	Требуется при использовании подсети в другой группе ресурсов, например в пользовательской виртуальной сети.
`Microsoft.Network/routeTables/routes/read` `Microsoft.Network/routeTables/routes/write`	Требуется при использовании подсети, связанной с таблицей маршрутов, в другой группе ресурсов, например в пользовательской виртуальной сети с пользовательской таблицей маршрутов. Требуется для проверки наличия подсети для использования подсети в другой группе ресурсов.
`Microsoft.Network/virtualNetworks/subnets/read`	Требуется при использовании внутренней подсистемы балансировки нагрузки в другой группе ресурсов. Требуется для проверки наличия подсети для использования внутренней подсистемы балансировки нагрузки в другой группе ресурсов.
`Microsoft.Network/privatednszones/*`	Требуется при использовании частной зоны DNS в другой группе ресурсов, например в пользовательской privateDNSZone.

Доступ к узлу для AKS

По умолчанию доступ к узлу для AKS не требуется. Если используется определенный компонент, для узла необходимы указанные ниже права доступа.

Открыть	Причина
`kubelet`	Требуется предоставить MSI-доступ к ACR.
`http app routing`	Требуется для разрешения на запись в "произвольное-имя".aksapp.io.
`container insights`	Требуется предоставить разрешение рабочей области Log Analytics.

Итоги

Просмотрите таблицу для краткой сводки о том, как пользователи могут проходить проверку подлинности в Kubernetes при включенной интеграции Microsoft Entra. Во всех случаях применяется следующая пользовательская последовательность команд:

Запустите az login для выполнения проверки подлинности в Azure.
Запустите az aks get-credentials, чтобы скачать учетные данные кластера в .kube/config.
Запустите команды kubectl.
- Первая из них может активировать проверку подлинности на основе браузера для выполнения проверки подлинности в кластере, как описано в следующей таблице.

На портале Azure можно найти следующее.

Предоставление роли (предоставление роли Azure RBAC), указанной во втором столбце, показано на вкладке Управление доступом.
Группа "Администратор кластера Microsoft Entra" отображается на вкладке "Конфигурация ".
- Также доступна в Azure CLI в виде параметра --aad-admin-group-object-ids.

Description	Требуется предоставление роли	Группы Microsoft Entra администратора кластера	Когда использовать
Устаревшее имя входа администратора с использованием сертификата клиента	роль администратора кластера Служба Azure Kubernetes. Эта роль позволяет `az aks get-credentials` использовать с флагом `--admin` , который скачивает устаревший (не Microsoft Entra) сертификат администратора кластера в пользователя `.kube/config`. Это единственная цель "роль администратора кластера Служба Azure Kubernetes".	Н/Д	Если вы постоянно заблокированы, не имея доступа к допустимой группе Microsoft Entra с доступом к кластеру.
Идентификатор Microsoft Entra с вручную (cluster)RoleBindings	роль пользователя кластера Служба Azure Kubernetes. Роль "Пользователь" позволяет `az aks get-credentials` использоваться без отметки `--admin`. (Это единственная цель "роль пользователя кластера Служба Azure Kubernetes".) Результатом в кластере с поддержкой идентификатора Microsoft Entra является скачивание пустой записи`.kube/config`, в которую запускается проверка подлинности на основе браузера при первом использовании`kubectl`.	Пользователь не входит ни в одну из этих групп. Поскольку пользователь не входит в группы администраторов кластера, его права полностью контролируются любыми привязками ролей или привязками ролей кластеров, настроенными администраторами кластеров. Роли (Cluster)RoleBindings номинируют пользователей Microsoft Entra или группы Microsoft Entra в качестве их `subjects`. Если такие привязки не настроены, пользователь не сможет выполнять команды `kubectl`.	Если необходимо детальное управление доступом, без использования Azure RBAC для авторизации Kubernetes. Обратите внимание, что пользователь, настраивающий привязки, должен войти в систему с помощью одного из дополнительных способов, приведенных в этой таблице.
Идентификатор Microsoft Entra по члену группы администрирования	То же, что и выше	Пользователь является членом одной из приведенных здесь групп. AKS автоматически создает привязку роли кластера, которая привязывает все перечисленные группы к `cluster-admin` роли Kubernetes. Таким образом, пользователи в этих группах могут выполнять все команды `kubectl` как `cluster-admin`.	Если необходимо предоставить пользователям полные права администратора, не используя Azure RBAC для авторизации Kubernetes.
Идентификатор Microsoft Entra с azure RBAC для авторизации Kubernetes	Две роли: Сначала Служба Azure Kubernetes роль пользователя кластера (как описано выше). вторая — одна из ролей Azure Kubernetes Service RBAC, приведенных выше, или собственный пользовательский вариант.	В поле "Роли администратора" на вкладке "Конфигурация" значение будет отсутствовать при включенной авторизации Azure RBAC для Kubernetes.	Использование Azure RBAC для авторизации Kubernetes. Такой подход обеспечивает детальное управление без необходимости настройки привязок ролей или привязок ролей кластеров.

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

Сведения о начале работы с идентификатором Microsoft Entra ID и Kubernetes RBAC см. в статье "Интеграция идентификатора Microsoft Entra с AKS".
Соответствующие рекомендации см. в разделе Рекомендации по проверке подлинности и выполнению авторизации в AKS.
Чтобы приступить к работе с Azure RBAC для авторизации Kubernetes, см. статью Использование Azure RBAC для авторизации доступа в кластере Службы Azure Kubernetes (AKS).
Сведения о начале защиты kubeconfig файла см. в разделе "Ограничение доступа к файлу конфигурации кластера".
Сведения о начале работы с управляемыми удостоверениями в AKS см. в статье "Использование управляемого удостоверения в AKS".

Дополнительные сведения о ключевых понятиях Kubernetes и AKS приведены в следующих статьях:

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