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

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

  • Статья

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

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

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

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

Kubernetes RBAC

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

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

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

Роли и Роли кластера

Роли

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

Примечание.

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

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

Кластерные роли

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

Элементы RoleBinding и ClusterRoleBinding

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

ПривязкиРолей

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

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

ClusterRoleBinding

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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.

Поток авторизации в Kubernetes с помощью Azure RBAC

Как показано на приведенной выше схеме, при использовании интеграции 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.

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

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

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

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

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

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

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

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

Сервер вебхука и API

Поток аутентификации вебхука и сервера API

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

  1. kubectl использует клиентское приложение Microsoft Entra для входа пользователей с помощью потока авторизации устройства OAuth 2.0.
  2. Microsoft Entra ID предоставляет access_token, id_token и refresh_token.
  3. Пользователь отправляет запрос в kubectl с помощью команды access_token из kubeconfig.
  4. kubectl отправляет access_token на сервер API.
  5. Сервер API настроен с сервером WebHook аутентификации для выполнения валидации.
  6. Сервер вебхука аутентификации подтверждает, что подпись веб-токена JSON действительна, проверив открытый ключ подписи от Microsoft Entra.
  7. Если группы больше 200, серверное приложение использует предоставленные пользователем учетные данные для запроса членства в группах пользователя, вошедшего в систему, из API MS Graph. Если количество групп не превышает 200, информация о группах уже содержится в токене клиента, и запрос не будет выполнен.
  8. Ответ отправляется на сервер API со сведениями о пользователе, такими как утверждение основного имени пользователя (UPN) маркера доступа, и членство пользователя в группе, определяемое идентификатором объекта.
  9. API принимает решение по авторизации на основе Role/RoleBinding в Kubernetes.
  10. После авторизации сервер API возвращает ответ в kubectl.
  11. kubectl предоставляет пользователю обратную связь.

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

Разрешения службы 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-адресов на балансировщике нагрузки (цен. категория "Стандартный").
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 Требуется присоединить Azure Disks к виртуальной машине в 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. Во всех случаях применяется следующая пользовательская последовательность команд:

  1. Запустите az login для выполнения проверки подлинности в Azure.

  2. Запустите az aks get-credentials, чтобы скачать учетные данные кластера в .kube/config.

  3. Запустите команды kubectl.

    • Первая команда может активировать аутентификацию на основе браузера для входа в кластер, как описано в следующей таблице.

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

  • Предоставление роли (предоставление роли Azure RBAC), указанной во втором столбце, показано на вкладке Управление доступом.
  • Группа "Администратор кластера Microsoft Entra" отображается на вкладке "Конфигурация ".
    • Также доступна в Azure CLI в виде параметра --aad-admin-group-object-ids.
Описание Требуется предоставление роли Группы администратора кластера 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 ID является скачивание пустой записи в .kube/config, что запускает проверку подлинности на основе браузера при первом использовании kubectl. Пользователь не входит ни в одну из этих групп. Поскольку пользователь не входит в группы администраторов кластера, его права полностью контролируются любыми привязками ролей или привязками ролей кластеров, настроенными администраторами кластеров. Роли (Cluster)RoleBindings назначают пользователей Microsoft Entra или группы Microsoft Entra в качестве их subjects. Если такие привязки не настроены, пользователь не сможет выполнять команды kubectl. Если вы хотите детального управления доступом, и вы не используете Azure RBAC для авторизации Kubernetes. Обратите внимание, что пользователь, настраивающий привязки, должен войти в систему с помощью одного из дополнительных способов, приведенных в этой таблице.
Идентификатор Microsoft Entra по члену группы администрирования То же, что и выше Пользователь является членом одной из приведенных здесь групп. AKS автоматически создает ClusterRoleBinding, связывающую все перечисленные группы с cluster-admin ролью Kubernetes. Таким образом, пользователи в этих группах могут выполнять все команды kubectl как cluster-admin. Если вы хотите удобно предоставить пользователям полные права администратора и не используете Azure RBAC для авторизации Kubernetes.
Идентификатор Microsoft Entra ID с Azure RBAC для авторизации Kubernetes Две роли:
Сначала роль пользователя кластера в службе Azure Kubernetes (как описано выше).
вторая — одна из ролей Azure Kubernetes Service RBAC, приведенных выше, или собственный пользовательский вариант.		 Поле "Роли администратора" на вкладке "Конфигурация" не имеет значения при включенной авторизации Azure RBAC для Kubernetes. Вы используете Azure RBAC для авторизации в Kubernetes. Такой подход обеспечивает детальное управление без необходимости настройки привязок ролей или привязок ролей кластеров.

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

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