Связаться с намиПодключиться

Управление доступом в Managed Service for Kubernetes

Статья создана
Улучшена
Обновлена 21 мая 2025 г.

В этом разделе вы узнаете:

Об управлении доступом

Все операции в Yandex Cloud проверяются в сервисе Yandex Identity and Access Management. Если у субъекта нет необходимых разрешений, сервис вернет ошибку.

Чтобы выдать разрешения к ресурсу, назначьте роли на этот ресурс субъекту, который будет выполнять операции. Роли можно назначить аккаунту на Яндексе, сервисному аккаунту, федеративным пользователям, группе пользователей, системной группе или публичной группе. Подробнее читайте в разделе Как устроено управление доступом в Yandex Cloud.

Назначать роли на ресурс могут пользователи, у которых на этот ресурс есть хотя бы одна из ролей:

  • admin;
  • resource-manager.admin;
  • organization-manager.admin;
  • resource-manager.clouds.owner;
  • organization-manager.organizations.owner.

На какие ресурсы можно назначить роль

Роль можно назначить на организацию, облако и каталог. Роли, назначенные на организацию, облако или каталог, действуют и на вложенные ресурсы.

Какие роли действуют в сервисе

На диаграмме показано, какие роли есть в сервисе и как они наследуют разрешения друг друга. Например, в editor входят все разрешения viewer. После диаграммы дано описание каждой роли.

Роли для доступа к Kubernetes API

Следующие роли дают права на управление ресурсами кластера Managed Service for Kubernetes через Kubernetes API. Роли Kubernetes API работают по модели ролевого управления доступом – Role-Based Access Control (RBAC). Для управления кластером Managed Service for Kubernetes эти роли необходимо компоновать с ролями для API Yandex Cloud. Подробнее о ролях в Kubernetes RBAC читайте в документации Kubernetes.

Чтобы просмотреть права на ресурсы кластера Managed Service for Kubernetes, доступные для определенной роли, выполните команду:

kubectl describe clusterrole <роль_в_Kubernetes_RBAC>

k8s.cluster-api.viewer

Пользователь с ролью k8s.cluster-api.viewer получает группу yc:viewer и роль view в Kubernetes RBAC для всех пространств имен в кластере.

k8s.cluster-api.editor

Пользователь с ролью k8s.cluster-api.editor получает группу yc:editor и роль edit в Kubernetes RBAC для всех пространств имен в кластере.

k8s.cluster-api.cluster-admin

Пользователь с ролью k8s.cluster-api.cluster-admin получает группу yc:admin и роль cluster-admin в Kubernetes RBAC.

Роли Managed Service for Kubernetes

Описанные ниже роли позволяют управлять кластерами Managed Service for Kubernetes и группами узлов без публичного доступа через API Yandex Cloud. Для управления ресурсами кластера Managed Service for Kubernetes эти роли необходимо компоновать с ролями для Kubernetes API. При создании кластера Managed Service for Kubernetes проверяются роли его сервисного аккаунта.

Для управления кластером Managed Service for Kubernetes и группой узлов без публичного доступа необходима роль k8s.clusters.agent.

Для управления кластером Managed Service for Kubernetes и группой с публичным доступом необходимы роли:

  • k8s.clusters.agent.
  • vpc.publicAdmin.

Для управления кластером Managed Service for Kubernetes с облачной сетью из другого каталога дополнительно необходимы роли в этом каталоге:

Для управления кластером Managed Service for Kubernetes с туннельным режимом достаточно роли k8s.tunnelClusters.agent.

k8s.viewer

Роль k8s.viewer позволяет просматривать информацию о кластерах и группах узлов Kubernetes.

k8s.editor

Роль k8s.editor дает права на создание, удаление, изменение, остановку и запуск кластеров и групп узлов Kubernetes.

Включает в себя роль k8s.viewer.

k8s.admin

Роль k8s.admin дает права на создание, удаление, изменение, остановку и запуск кластеров и групп узлов Kubernetes.

Включает в себя роль k8s.editor.

k8s.tunnelClusters.agent

k8s.tunnelClusters.agent — специальная роль для создания кластера Kubernetes с туннельным режимом. Дает право на создание групп узлов, дисков, внутренних балансировщиков. Позволяет использовать заранее созданные ключи Yandex Key Management Service для шифрования и расшифровки секретов. Включает роли:

  • compute.admin
  • iam.serviceAccounts.user
  • k8s.viewer
  • kms.keys.encrypterDecrypter
  • load-balancer.privateAdmin

k8s.clusters.agent

k8s.clusters.agent — специальная роль для сервисного аккаунта кластера Kubernetes. Дает право на создание групп узлов, дисков, внутренних балансировщиков. Позволяет использовать заранее созданные ключи Yandex Key Management Service для шифрования и расшифровки секретов, а также подключать заранее созданные группы безопасности. В комбинации с ролью load-balancer.admin позволяет создать сетевой балансировщик нагрузки с публичным IP-адресом. Включает роли:

  • k8s.tunnelClusters.agent
  • vpc.privateAdmin

Примитивные роли

viewer

Роль viewer предоставляет разрешения на чтение информации о любых ресурсах Yandex Cloud.

Включает разрешения, предоставляемые ролью auditor.

В отличие от роли auditor, роль viewer предоставляет доступ к данным сервисов в режиме чтения.

editor

Роль editor предоставляет разрешения на управление любыми ресурсами Yandex Cloud, кроме назначения ролей другим пользователям, передачи прав владения организацией и ее удаления, а также удаления ключей шифрования Key Management Service.

Например, пользователи с этой ролью могут создавать, изменять и удалять ресурсы.

Включает разрешения, предоставляемые ролью viewer.

admin

Роль admin позволяет назначать любые роли, кроме resource-manager.clouds.owner и organization-manager.organizations.owner, а также предоставляет разрешения на управление любыми ресурсами Yandex Cloud, кроме передачи прав владения организацией и ее удаления.

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

Включает разрешения, предоставляемые ролью editor.

Примечание

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

Пример

  1. Создайте в кластере роль, которая позволит управлять всеми ресурсами в заданном пространстве имен:

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: <пространство_имен>
  name: <название_роли>
rules:
- apiGroups: [""]
  resources: ["*"]   
  verbs: ["*"]

  2. Создайте связь с этой ролью для аккаунта пользователя:

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: iam-user
  namespace: <пространство_имен>
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: <название_роли>
subjects:
- kind: User
  name: <идентификатор_аккаунта>

Подробности о получении идентификатора аккаунта см. на странице Получение информации о пользователе.

Проверьте создание ресурсов в кластере. В других пространствах имен пользователь не будет иметь право на создание или редактирование ресурсов.

Какие роли необходимы для создания Managed Service for Kubernetes

Для создания кластера Managed Service for Kubernetes и группы узлов аккаунт, с помощью которого вы собираетесь создавать кластер, должен иметь роли:

Чтобы создать кластер Managed Service for Kubernetes и группу узлов с публичным доступом, дополнительно нужна роль vpc.publicAdmin.

Сервисные аккаунты кластера Managed Service for Kubernetes

При создании кластера Managed Service for Kubernetes необходимо указать два сервисных аккаунта:

  • Сервисный аккаунт кластера — от имени этого сервисного аккаунта сервис Managed Service for Kubernetes управляет узлами кластера, подсетями для подов и сервисов, дисками, балансировками нагрузки, а также шифрует и дешифрует секреты. Минимально рекомендуемая роль для такого аккаунта — k8s.clusters.agent.
  • Сервисный аккаунт группы узлов — от имени этого сервисного аккаунта узлы кластера Managed Service for Kubernetes аутентифицируются в Yandex Container Registry. Для развертывания в кластере Managed Service for Kubernetes приложений с использованием Docker-образов из Container Registry этому аккаунту нужно назначить какую-либо сервисную роль. Если используется другой container registry, то роли этому сервисному аккаунту можно не назначать.

Для управления кластером Managed Service for Kubernetes и группами узлов с публичным доступом дополнительно необходима роль vpc.publicAdmin.

При использовании в кластере Managed Service for Kubernetes облачной сети из другого каталога сервисному аккаунту кластера дополнительно необходимы роли в этом каталоге:

Доступ к консоли управления Managed Service for Kubernetes

k8s.viewer — минимально необходимая роль для доступа к Managed Service for Kubernetes через консоль управления Yandex Cloud. Роль k8s.viewer дает доступ только к основной информации о группах узлов.

Комбинация ролей k8s.viewer и k8s.clusters.agent позволяет просматривать всю информацию о группах узлов, но не об отдельных узлах кластера.

Комбинация ролей k8s.cluster-api.cluster-admin, k8s.clusters.agent и monitoring.viewer дает доступ к просмотру подробной информации о группах узлов и отдельных узлах кластера. В консоли управления для каждого узла становятся доступны все вкладки, включая вкладку Мониторинг.

Чтобы предоставить более гранулярный доступ к необходимым ресурсам, вы можете:

  • Настроить дополнительные права в Kubernetes RBAC для соответствующих пользователей.

  • Расширить роли view и edit в Kubernetes RBAC с помощью агрегации ролей. Например, вы можете разрешить всем пользователям с ролью view в Kubernetes API (в том числе пользователям с облачной ролью k8s.cluster-api.viewer) просмотр информации об узлах, добавив следующую роль в кластер Managed Service for Kubernetes:

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: view-extensions
  labels:
    rbac.authorization.k8s.io/aggregate-to-view: "true"
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]
Предыдущая
Рекомендации по использованию Managed Service for Kubernetes
Следующая
Правила тарификации