Документация Grafana Документация GlaberGraph Как код Наблюдаемость как код Синхронизация Git Permissions and access control

Права доступа и контроль доступа Git Sync

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

• На уровне Grafana — для управления репозиториями и доступа к ресурсам, как описано в этом документе.
• На уровне вашего Git-провайдера — для защиты репозитория. Дополнительную информацию см. в разделе Защита репозитория для Git Sync.

Ролевые права доступа Grafana

Git Sync интегрируется со стандартной ролевой моделью прав доступа Grafana, которая имеет три уровня:

1. На уровне организации: права по умолчанию для роли Admin, Editor или Viewer. Подробнее см. в разделе Роли и права доступа.
2. На уровне папки: они также применяются ко всем дашбордам внутри неё. Подробнее см. в разделе Права доступа к папкам.
3. На уровне дашборда: подробнее см. в разделе Права доступа к дашбордам.

Для Git Sync действует следующее:

• Права доступа не синхронизируются: права доступа к папкам и дашбордам управляются только в Grafana и не синхронизируются в Git. Права доступа необходимо настраивать отдельно в каждом экземпляре Grafana, использующем этот репозиторий
• Изменения дашбордов: когда пользователи с соответствующими правами на дашборд или папку изменяют содержимое дашборда, эти изменения автоматически синхронизируются в Git или создают pull request, если включена защита веток
• Структура папок: создание, переименование или удаление папок синхронизируется в Git

Использование прав уровня организации в Git Sync

Если вы применяете права уровня организации, пользователи могут делать следующее с помощью Git Sync:

Пользователи с ролью Admin

В Grafana OSS/Enterprise для настройки и управления репозиториями и подключениями Git Sync вам нужна роль Admin. В Grafana Cloud эквивалентной ролью является Grafana Cloud Admin или Admin на уровне организации.

Как администратор вы можете:

• Настраивать новые репозитории и подключения Git Sync
• Обновлять настройки репозитория (URL, ветка, путь, интервал синхронизации, конфигурация вебхука)
• Удалять подключения к репозиториям
• Управлять учётными данными для аутентификации и подключениями к Git-провайдеру
• Вручную запускать операции синхронизации (загрузка из Git)
• Просматривать статус синхронизации, журналы и статистику
• Получать доступ к интерфейсу администрирования Provisioning в разделе Administration > General > Provisioning

Пользователи с ролью Editor

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

Возможности на уровне организации:

• Просматривать ссылки на предпросмотр дашбордов в pull request
• Отправлять свои изменения дашбордов и папок в Git, включая создание pull request, через API заданий (jobs API)

Доступ к ресурсам зависит от прав доступа к папкам и дашбордам:

• Folder Editor или Admin: создание, редактирование и удаление дашбордов внутри папки; создание вложенных папок; изменения синхронизируются в Git
• Folder Viewer: только просмотр дашбордов внутри этой папки
• Dashboard Editor или Admin: редактирование конкретных дашбордов; изменения синхронизируются в Git (даже без доступа на редактирование папки)
• Dashboard Viewer: только просмотр конкретных дашбордов

Редакторам не требуется доступ к интерфейсу администрирования Provisioning или конфигурации репозитория. Подробности см. в разделах Настройка прав доступа к папкам и дашбордам и Настройка детального контроля доступа (RBAC).

Пользователи с ролью Viewer

Пользователи с ролью Viewer могут просматривать выделенные ресурсы. Их доступ к конкретным дашбордам и папкам зависит от назначенных им прав доступа.

Возможности на уровне организации:

• Чтение настроек Git Sync через право provisioning.settings:read
• Просмотр ссылок на предпросмотр дашбордов в pull request

Доступ к ресурсам зависит от прав доступа к папкам и дашбордам:

• Folder Viewer: просмотр всех дашбордов и вложенных папок внутри этой папки
• Dashboard Viewer: просмотр конкретных дашбордов (даже если нет доступа к папке)
• Не могут редактировать дашборды или управлять репозиториями Git Sync

Настройка прав доступа к папкам и дашбордам

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

Эти роли предоставляют права Grafana (dashboards:read, dashboards:write, folders:create…), которые проверяются, когда пользователи взаимодействуют с выделенными ресурсами через конечную точку files Git Sync. Дашборды внутри выделенной папки наследуют права доступа папки.

Когда Git Sync создаёт выделенную папку, он назначает следующие права доступа по умолчанию:

Пользователи с ролью Viewer на уровне папки:

• Просматривают дашборды и папки
• Не могут создавать, редактировать или удалять ресурсы

Пользователи с ролью Editor на уровне папки:

• Обладают всеми правами Viewer
• Создают, редактируют и удаляют дашборды
• Создают вложенные папки
• Когда Editor сохраняет изменения дашборда, Git Sync автоматически фиксирует изменения в Git или создаёт pull request, если включена защита веток

Пользователи с ролью Admin на уровне папки:

• Обладают всеми правами Editor
• Обновляют настройки папки, переименовывают и удаляют папки
• Изменяют права доступа к папке
• Полный контроль над папкой и всем её содержимым

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

Права доступа к папкам в Grafana привязаны к UID папки, а не к её пути в репозитории Git. Git Sync хранит этот UID в файле метаданных папки _folder.json (в поле metadata.name). Схему файла метаданных и причины его существования см. в разделе Файл метаданных папки Git Sync.

Поскольку права доступа ссылаются на UID папки, учитывайте следующее:

• Сначала создайте папки. Папка должна существовать в Grafana — и иметь файл _folder.json со стабильным UID, — прежде чем вы сможете назначить ей права доступа. Позвольте Git Sync создать и синхронизировать папки, а затем примените права доступа, ссылающиеся на полученные UID. Если вы попытаетесь задать право доступа для ещё не синхронизированной папки, привязать его будет не к чему.
• Права доступа не синхронизируются в Git. Вы задаёте их для каждого экземпляра Grafana отдельно. Каждый экземпляр, синхронизирующий один и тот же репозиторий, использует одни и те же UID папок (из _folder.json), поэтому вы можете применять одни и те же определения прав доступа к каждому экземпляру.

Вы можете задавать права доступа к папкам вручную или в виде кода. В обоих случаях применяйте их только после того, как Git Sync создаст папки.

Настройка прав доступа вручную

• Интерфейс Grafana: перейдите в папку и выберите Folder actions > Manage permissions. Добавьте или измените права доступа для ролей, команд или пользователей.
• HTTP API: используйте API прав доступа к папкам/дашбордам. Ссылайтесь на папку по UID, хранящемуся в её файле _folder.json.
• RBAC (Enterprise/Cloud): используйте ролевой контроль доступа для детального управления правами доступа.

Настройка прав доступа с помощью Terraform

Вы можете управлять правами доступа к папкам в виде кода с помощью провайдера Grafana для Terraform. Поскольку папки создаёт Git Sync, а не Terraform, ссылайтесь на каждую папку по UID из её файла _folder.json (значение metadata.name). Применяйте права доступа только после того, как Git Sync синхронизирует папки, чтобы UID папок уже существовали.

Используйте grafana_folder_permission_item для управления отдельной записью прав доступа. Это аддитивный ресурс: он управляет только объявленными вами записями и не затрагивает остальные права доступа:

terraform Copy

# The UID comes from the folder's _folder.json metadata file ("metadata.name").
locals {
  team_platform_folder_uid = "team-platform-abc123"
}

resource "grafana_folder_permission_item" "team_platform_editor" {
  folder_uid = local.team_platform_folder_uid
  team       = grafana_team.platform.id # an existing team
  permission = "Edit"
}

resource "grafana_folder_permission_item" "team_platform_viewer" {
  folder_uid = local.team_platform_folder_uid
  role       = "Viewer"
  permission = "View"
}

В качестве альтернативы используйте grafana_folder_permission, чтобы объявить полный набор прав доступа к папке в одном ресурсе. Этот ресурс является авторитетным: любое право доступа, не указанное в нём, удаляется при применении конфигурации.

Настройка детального контроля доступа (RBAC)

Если вы используете Grafana Enterprise или Grafana Cloud с включённым RBAC, Git Sync предоставляет детальные права доступа, позволяющие более гранулярно контролировать операции Git Sync. Вы можете создавать пользовательские роли, по-разному комбинируя права доступа Git Sync. Инструкции по созданию пользовательских ролей и управлению ими см. в документации Ролевой контроль доступа.

Соответствие базовых ролей правам RBAC

Понимание того, какие права доступа получает каждая базовая роль, помогает создавать пользовательские роли или точно понимать, какой доступ имеют пользователи. Таблицы ниже показывают, какие права доступа Git Sync предоставляются каждой роли по умолчанию.

Роль Admin

Пользователи с ролью Admin получают полный доступ к инфраструктуре Git Sync:

Роль Editor

Пользователи с ролью Editor могут управлять операциями синхронизации, но не конфигурацией инфраструктуры:

Editors могут получать доступ к ресурсам в зависимости от назначений на уровне папок/дашбордов:

• dashboards:create, dashboards:read, dashboards:write, dashboards:delete — для папок/дашбордов, где назначена роль Folder Editor или Dashboard Editor
• folders:create, folders:read, folders:write, folders:delete — для папок, где назначена роль Folder Editor

Роль Viewer

Пользователи с ролью Viewer имеют доступ к Git Sync только на чтение:

Viewers могут получать доступ к ресурсам в зависимости от назначений на уровне папок/дашбордов:

• dashboards:read — для папок/дашбордов, где назначена роль Folder Viewer или Dashboard Viewer
• folders:read — для папок, где назначена роль Folder Viewer

RBAC для дашбордов и папок

Выделенные дашборды и папки используют стандартную модель прав доступа Grafana. Чтобы изменять выделенные ресурсы, вам понадобятся права доступа к вашему дашборду и папке.

Для Git Sync действует следующее:

• Вам нужны стандартные права dashboards:* и folders:* для работы с выделенными ресурсами
• Editors и Viewers нужны права provisioning.settings:read и provisioning.repositories:read для просмотра конфигурации Git Sync
• Для редактирования дашбордов вам не нужны права на запись/удаление репозитория или права на подключения
• Права доступа на уровне дашборда переопределяют права доступа на уровне папки
• Изменения, сделанные пользователями с соответствующими правами доступа, автоматически синхронизируются в Git

Действия заданий и необходимые права доступа

Операции Git Sync выполняются как задания. Вам нужно право provisioning.jobs:create, чтобы создать любое задание. Кроме того, некоторые действия заданий ограничены администраторами и требуют права provisioning.repositories:write. Это не позволяет редакторам запускать операции уровня всего репозитория, хотя они и обладают правом provisioning.jobs:create.

Доступ к подресурсам репозитория

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

Подресурс refs перечисляет ветки и коммиты репозитория, и он законно нужен двум разным сценариям:

• Редакторы отправляют изменения: когда редактор сохраняет изменения или создаёт pull request через сценарий задания push, Grafana нужен список веток. Это авторизуется с помощью provisioning.jobs:create.
• Администраторы настраивают репозиторий: когда администратор или владелец репозитория настраивает или редактирует репозиторий и выбирает целевую ветку, Grafana обновляет сведения о ресурсе Repository. Это авторизуется с помощью provisioning.repositories:write.

Поскольку у ресурса repositories нет уровня Editor (repositories:read предоставляется роли Viewer и выше, тогда как write, create и delete доступны только администраторам), refs принимает любую из этих проверок, а средства просмотра (viewers) не проходят ни одну из них.

Настройка защиты репозитория Git

После настройки прав доступа Grafana настройте соответствующие права у вашего Git-провайдера для записи изменений. Настройки защиты репозитория управляют доступом на запись, правилами защиты веток и требованиями к проверке кода.

Подробную информацию о настройке доступа на запись к репозиторию и защиты веток см. в разделе Защита репозитория для Git Sync.

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

«Permission denied» при сохранении дашборда

Причина: у пользователя нет права Editor или Admin на выделенную папку.

Решение:

1. Проверьте права доступа пользователя на уровне папки в Grafana
2. Перейдите в Folder settings > Permissions
3. Предоставьте пользователю или его команде роль Editor или Admin

Git Sync завершается ошибкой «403 Forbidden» или «Unauthorized»

Причина: учётным данным для аутентификации Git-провайдера не хватает необходимых прав доступа к репозиторию.

Решение:

1. Убедитесь, что учётные данные для аутентификации (GitHub App, персональный токен доступа) имеют права на чтение и запись в репозитории
2. Если вы используете GitHub App или OAuth-приложение, убедитесь, что оно установлено и авторизовано для целевого репозитория
3. Проверьте, что у учётных данных есть право на создание pull request (если включена защита веток)
4. Убедитесь, что учётные данные для аутентификации не истекли
5. Для истёкших или отозванных токенов создайте новые учётные данные и обновите конфигурацию подключения Git Sync

Изменения дашбордов фиксируются напрямую вместо создания pull request

Причина: у Git-провайдера не настроена защита веток.

Решение: включите правила защиты веток у вашего Git-провайдера, чтобы обеспечить процесс pull request, или в настройках репозитория в Grafana. Инструкции по настройке защиты веток см. в документации вашего Git-провайдера.

Изменения дашбордов фиксируются напрямую без проверки

Причина: у Git-провайдера не настроена защита веток.

Решение:

1. Включите защиту веток для целевой ветки у вашего Git-провайдера
2. Настройте ветку так, чтобы она требовала pull request перед слиянием
3. Убедитесь, что имя ветки в правилах защиты точно совпадает с веткой, настроенной в Grafana

Pull request не создаются, когда это ожидается

Причина: защита веток не включена или учётным данным для аутентификации не хватает права на создание pull request.

Решение:

1. Убедитесь, что защита веток включена для правильной ветки
2. Проверьте, что у учётных данных есть право на создание pull request
3. Убедитесь, что имя ветки в настройках Git Sync точно совпадает с защищённой веткой