Yandex Cloud
  • Сервисы
  • Решения
  • Почему Yandex Cloud
  • Сообщество
  • Тарифы
  • Документация
  • Связаться с нами
Подключиться
Language / Region
Проект Яндекса
© 2023 ООО «Яндекс.Облако»
Yandex Managed Service for Apache Kafka®
  • Начало работы
  • Пошаговые инструкции
    • Все инструкции
    • Информация об имеющихся кластерах
    • Создание кластера
    • Подключение к кластеру
    • Остановка и запуск кластера
    • Обновление версии Apache Kafka®
    • Изменение настроек кластера
    • Управление хостами Apache Kafka®
    • Работа с топиками и разделами
    • Управление пользователями Apache Kafka®
    • Управление коннекторами
    • Просмотр логов кластера
    • Удаление кластера
    • Мониторинг состояния кластера и хостов
  • Практические руководства
    • Все руководства
    • Настройка Kafka Connect для работы с Managed Service for Apache Kafka®
    • Использование схем формата данных с Managed Service for Apache Kafka®
      • Обзор
      • Работа с управляемым реестром схем формата данных
      • Использование Confluent Schema Registry с Managed Service for Apache Kafka®
    • Миграция базы данных из стороннего кластера Apache Kafka®
    • Перенос данных между кластерами Managed Service for Apache Kafka® с помощью Yandex Data Transfer
    • Поставка данных из Yandex Managed Service for PostgreSQL с помощью Debezium
    • Поставка данных из Yandex Managed Service for MySQL с помощью Debezium
    • Поставка данных из Yandex Managed Service for PostgreSQL с помощью Yandex Data Transfer
    • Поставка данных в Managed Service for ClickHouse
    • Поставка данных в Yandex Managed Service for ClickHouse с помощью Yandex Data Transfer
    • Поставка данных в ksqlDB
    • Поставка данных в Yandex Managed Service for YDB с помощью Yandex Data Transfer
  • Концепции
    • Взаимосвязь ресурсов сервиса
    • Топики и разделы
    • Брокеры
    • Производители и потребители
    • Управление схемами данных
    • Классы хостов
    • Сеть в Managed Service for Apache Kafka®
    • Квоты и лимиты
    • Типы дисков
    • Коннекторы
    • Техническое обслуживание
    • Настройки Apache Kafka®
  • Управление доступом
  • Правила тарификации
  • Справочник API
    • Аутентификация в API
    • gRPC (англ.)
      • Overview
      • ClusterService
      • ConnectorService
      • ResourcePresetService
      • TopicService
      • UserService
      • OperationService
    • REST (англ.)
      • Overview
      • Cluster
        • Overview
        • create
        • delete
        • get
        • list
        • listHosts
        • listLogs
        • listOperations
        • move
        • rescheduleMaintenance
        • start
        • stop
        • streamLogs
        • update
      • Connector
        • Overview
        • create
        • delete
        • get
        • list
        • pause
        • resume
        • update
      • ResourcePreset
        • Overview
        • get
        • list
      • Topic
        • Overview
        • create
        • delete
        • get
        • list
        • update
      • User
        • Overview
        • create
        • delete
        • get
        • grantPermission
        • list
        • revokePermission
        • update
      • Operation
        • Overview
        • get
  • История изменений
  • Вопросы и ответы
  1. Управление доступом

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

Статья создана
Yandex Cloud
  • Об управлении доступом
  • На какие ресурсы можно назначить роль
  • Какие роли действуют в сервисе
    • mdb.admin
    • mdb.viewer
    • mdb.auditor
    • resource-manager.clouds.member
    • resource-manager.clouds.owner
    • vpc.publicAdmin
    • viewer
    • editor
    • admin
    • managed-kafka.admin
    • managed-kafka.auditor
    • managed-kafka.editor
    • managed-kafka.viewer
  • Какие роли необходимы
  • Что дальше

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

  • на какие ресурсы можно назначить роль;
  • какие роли действуют в сервисе;
  • какие роли необходимы для того или иного действия.

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

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

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

Назначать роли на ресурс могут те, у кого есть роль admin или resource-manager.clouds.owner на этот ресурс.

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

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

Чтобы разрешить доступ к ресурсам сервиса Managed Service for Apache Kafka® (кластеры и хосты, резервные копии кластеров, разделы и топики, пользователи), назначьте пользователю нужные роли на каталог или облако, в котором содержатся эти ресурсы.

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

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

mdb.admin

Роль mdb.admin позволяет создавать и изменять кластеры управляемых баз данных.

mdb.viewer

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

mdb.auditor

Роль mdb.auditor позволяет просматривать информацию об управляемых базах данных кластера (кроме логов их работы).

resource-manager.clouds.member

Сама по себе роль не дает права выполнять какие-либо операции и используется только в сочетании с другими ролями.

Как сочетать роль с другими ролями зависит от того, входит облако в организацию или нет.

Для облака в организации

Роль полезна, если пользователю необходим доступ к ресурсам Yandex Cloud не только через CLI, API и Terraform, но и через консоль управления.

resource-manager.clouds.member — это одна из ролей, которая даст пользователю доступ к консоли управления. Так же для этой цели подойдет любая роль из списка:

  • На организации или облаке:

    • resource-manager.admin;
    • resource-manager.editor;
    • resource-manager.viewer;
    • admin;
    • editor;
    • viewer.
  • На облаке:

    • resource-manager.clouds.owner.

Каждая роль из списка даст пользователю не только доступ к консоли, но и свои разрешения на ресурсы облака или организацию. В зависимости от роли это может быть чтение информации обо всех ресурсах в облаке или создание и удаление любого ресурса.

Чтобы не давать пользователю дополнительных прав, используйте resource-manager.clouds.member. Роль обеспечит доступ к консоли управления при минимальных дополнительных правах. Пользователь увидит только общую информацию об облаке, на которое ему назначена роль, но не сможет просмотреть ресурсы и права доступа к облаку.

Пример:

Администратор должен управлять сетевой связностью ресурсов во всех облаках организации. За несетевые ресурсы отвечают другие члены команды. Для этого случая можно использовать такую матрицу доступа:

Роль На ресурс Разрешает
vpc.admin Организация Управлять сетями, маршрутами, IP-адресами и другими ресурсами Virtual Private Cloud через CLI, API и Terraform во всех облаках организации
resource-manager.clouds.member Все облака организации Работать с Virtual Private Cloud в консоли управления, видеть общую информацию об облаках

Примечание

Если в организации много облаков и они часто создаются и удаляются, каждый раз назначать resource-manager.clouds.member на облако будет неудобно. В этом случае можно заменить resource-manager.clouds.member ролью resource-manager.viewer — назначьте ее один раз на организацию, и администратор сможет работать в консоли управления с ресурсами Virtual Private Cloud всех облаков, включая будущие облака. Роль позволит видеть информацию обо всех облаках и каталогах, включая списки прав доступа.

Для облака без организации

Роль необходима для доступа к ресурсам в облаке всем, кроме владельцев облака и сервисных аккаунтов.

Без этой роли у пользователя не будут работать никакие другие роли.

Роль назначается автоматически при добавлении в облако без организации нового пользователя.

resource-manager.clouds.owner

Роль resource-manager.clouds.owner назначается на облако и делает пользователя владельцем облака. Владелец может выполнять любые операции с облаком и ресурсами в нем.

Только владелец облака может назначать и удалять у пользователей роль resource-manager.clouds.owner.

У облака должен быть хотя бы один владелец. Пользователь, который создал облако, автоматически становится его владельцем. Единственный владелец облака не сможет отнять эту роль у себя.

vpc.publicAdmin

Роль vpc.publicAdmin позволяет создавать и удалять статические публичные IP-адреса. Также она включает все разрешения роли vpc.viewer.

Наличие роли vpc.publicAdmin также необходимо для создания ресурсов с публичными IP-адресами, например: виртуальных машин или кластеров управляемых баз данных.

Сейчас эту роль можно назначить только на каталог или облако.

Важно: если сеть и подсеть находятся в разных каталогах, то наличие роли vpc.publicAdmin проверяется на том каталоге, в котором находится сеть.

viewer

Роль viewer дает разрешения на чтение к ресурсам.

Например, роль viewer позволяет выполнять следующие операции:

  • Просмотр информации о ресурсе.
  • Получение списка вложенных ресурсов, например списка виртуальных машин в каталоге.
  • Просмотр списка операций с ресурсом.

editor

Роль editor дает разрешения на все операции для управления ресурсом, кроме назначения ролей другим пользователям. Роль editor включает все разрешения, которые дает роль viewer.

Например, роль editor позволяет выполнять следующие операции:

  • Создание ресурса.
  • Обновление ресурса.
  • Удаление ресурса.

admin

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

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

Например, роль admin позволяет выполнять следующие операции:

  • Установить права доступа к ресурсу.
  • Изменить права доступа к ресурсу.

managed-kafka.admin

Роль managed-kafka.admin позволяет создавать, изменять и удалять кластеры, просматривать информацию о кластерах, логах их работы и квотах, а также управлять доступом к кластерам.

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

managed-kafka.auditor

Роль managed-kafka.auditor позволяет просматривать информацию о кластерах и квотах.

managed-kafka.editor

Роль managed-kafka.editor позволяет создавать, изменять и удалять кластеры, а также просматривать информацию о кластерах, логах их работы и квотах.

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

managed-kafka.viewer

Роль managed-kafka.viewer позволяет просматривать информацию о кластерах, логах их работы и квотах.

Какие роли необходимы

Чтобы пользоваться сервисом, необходима роль editor или выше на каталог, в котором создается кластер. Роль viewer позволит только просматривать список кластеров.

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

Что дальше

  • Как назначить роль.
  • Как отозвать роль.
  • Подробнее об управлении доступом в Yandex Cloud.
  • Подробнее о наследовании ролей.

Была ли статья полезна?

Language / Region
Проект Яндекса
© 2023 ООО «Яндекс.Облако»
В этой статье:
  • Об управлении доступом
  • На какие ресурсы можно назначить роль
  • Какие роли действуют в сервисе
  • mdb.admin
  • mdb.viewer
  • mdb.auditor
  • resource-manager.clouds.member
  • resource-manager.clouds.owner
  • vpc.publicAdmin
  • viewer
  • editor
  • admin
  • managed-kafka.admin
  • managed-kafka.auditor
  • managed-kafka.editor
  • managed-kafka.viewer
  • Какие роли необходимы
  • Что дальше