Параметры доступа и удостоверения для AKS, включенные Azure Arc

Область применения: AKS в локальной среде Azure, версия 23H2

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

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

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

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

Kubernetes RBAC

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

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

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

Элементы Role и ClusterRole

Роли

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

Роли Kubernetes предоставляют разрешения; они не отклоняют разрешения. Чтобы предоставить разрешения для всего кластера или ресурсов кластера за пределами заданного пространства имен, можно использовать ClusterRoles.

ClusterRole

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

Элементы RoleBinding и ClusterRoleBinding

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

RoleBinding

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

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

ClusterRoleBinding

С помощью ClusterRoleBinding можно привязать роли к пользователям и применить к ресурсам в пределах всего кластера, а не в определенном пространстве имен. Такой подход позволяет предоставить администраторам или инженерам службы поддержки доступ ко всем ресурсам в кластере 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 Arc:

• Доступ к ресурсу AKS в подписке Azure.
  • Управление масштабированием или обновлением кластера с помощью AKS, включенного API Azure Arc.
  • Потяните администратора, kubeconfig на основе сертификатов.
  • Извлечение идентификатора записи с поддержкой kubeconfig.
• Доступ к API Kubernetes. Этот доступ контролируется следующим образом:
  • Kubernetes RBAC или
  • Интеграция Azure RBAC с AKS для авторизации Kubernetes.

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

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

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

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

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

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

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

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

Внимание

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

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

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

Роль	Description
Пользователь кластера Kubernetes с поддержкой Azure Arc	Позволяет получить файл kubeconfig на основе кластера для управления кластерами из любого места.
Зритель Kubernetes Azure Arc	Разрешает доступ только для чтения, позволяя просматривать большинство объектов в пространстве имен. Не разрешает просмотр секретов, так как разрешение на чтение секретов обеспечивает доступ к учетным данным ServiceAccount в пространстве имен. Эти учетные данные, в свою очередь, разрешают доступ к API через это значение ServiceAccount (форма эскалации привилегий).
Писатель Kubernetes Azure Arc	Разрешает доступ для чтения и записи к большинству объектов в пространстве имен. Не допускает просмотр или изменение ролей или привязок ролей. Однако эта роль позволяет получать доступ к секретам и запускать модули pod как любое значение ServiceAccount в пространстве имен, поэтому его можно использовать для получения уровней доступа API любого такого значения ServiceAccount в пространстве имен.
Администратор Kubernetes Azure Arc	Разрешает административный доступ. Он предназначен для предоставления в пространстве имен через RoleBinding. Если он используется в RoleBinding, он разрешает доступ на чтение и запись к большинству ресурсов в пространстве имен, включая возможность создавать роли и привязки ролей в пространстве имен. Эта роль не разрешает доступ на запись к квоте ресурса или пространству имен.
Администратор кластера Kubernetes Azure Arc	Разрешает "суперпользователь" доступ к выполнению любого действия в любом ресурсе. При использовании в ClusterRoleBinding он обеспечивает полный контроль над каждым ресурсом в кластере и во всех пространствах имен. При использовании в RoleBinding он обеспечивает полный контроль над каждым ресурсом в пространстве имен привязки роли, включая само пространство имен.

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

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

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

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

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

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

Итоги

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

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

Description	Требуется предоставление роли	Группы Microsoft Entra администратора кластера	Когда использовать
Имя входа администратора с помощью сертификата клиента	Служба Azure Kubernetes роль администратора кластера Arc. Эта роль позволяет az aksarc get-credentials использовать с флагом--admin, который скачивает сертификат администратора кластера, отличный от Майкрософт, в kube/config пользователя. Это единственная цель роли администратора Azure Kubernetes.	Н/Д	Если вы постоянно заблокированы, не имея доступа к допустимой группе Microsoft Entra с доступом к кластеру.
Идентификатор Microsoft Entra с ручным (кластером) RoleBindings	роль пользователя кластера Arc Служба Azure Kubernetes. Роль пользователя позволяет az aksarc get-credentials использовать без флага --admin . Это единственная цель роли пользователя кластера Служба Azure Kubernetes.) Результатом кластера с поддержкой идентификатора Microsoft Entra является скачивание пустой записи в kube/config, которая активирует проверку подлинности на основе браузера при первом использовании kubectl.	Так как пользователь не входит в группу администрирования кластера, их права полностью контролируются любыми ролями RoleBindings или ClusterRoleBindings, настроенными администраторами кластера. РольBindings номинирует пользователей Microsoft Entra или группы Microsoft Entra в качестве своих субъектов. Если такие привязки не были настроены, пользователь не может вырезать какие-либо команды kubectl .	Если необходимо детальное управление доступом, без использования Azure RBAC для авторизации Kubernetes. Обратите внимание, что пользователь, который настраивает привязки, должен войти с помощью одного из других методов, перечисленных в этой таблице.
Идентификатор Microsoft Entra по члену группы Microsoft Entra администратора кластера (задайте флаг с помощью --aad-admin-group-object-ids флага в Azure CLI)	То же самое, что и раньше.	Пользователь является членом одной из приведенных здесь групп. AKS автоматически создает привязку роли кластера, которая привязывает все перечисленные группы к cluster-admin роли Kubernetes. Таким образом, пользователи в этих группах могут выполнять все команды kubectl как cluster-admin.	Если вы хотите предоставить пользователям полные права администратора и не использовать Azure RBAC для авторизации Kubernetes.
Идентификатор Microsoft Entra с azure RBAC для авторизации Kubernetes	Две роли: Служба Azure Kubernetes роль пользователя кластера Arc (как описано ранее). Одна из ролей Azure Arc Kubernetes , описанных ранее или собственная пользовательская альтернатива.	Поле ролей администратора на вкладке "Конфигурация" не имеет значения, если включена авторизация Azure RBAC для Kubernetes.	Вы используете Azure RBAC для авторизации Kubernetes. Такой подход обеспечивает детальное управление без необходимости настройки привязок ролей или привязок ролей кластеров.

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

• Сведения о начале работы с RBAC Kubernetes для авторизации Kubernetes см. в статье "Управление доступом с помощью идентификатора Microsoft Entra и Kubernetes RBAC"
• Сведения о начале работы с авторизацией Azure RBAC для Kubernetes см. в статье "Использование Azure RBAC для авторизации Kubernetes"