Документацияbreadcrumb arrow Grafanabreadcrumb arrow Документация GlaberGraphbreadcrumb arrow Администрированиеbreadcrumb arrow Управление источниками данныхbreadcrumb arrow Управление доступом на основе меток (LBAC) для источников данныхbreadcrumb arrow Создание правила LBAC для источника данных

Создание правила LBAC для источника данных

LBAC для источников данных доступен для источников данных, поддерживающих LBAC, созданных с базовой аутентификацией. На сегодняшний день управляемые/провижининг-источники данных НЕ могут быть настроены с правилами LBAC.

Прежде чем начать

  • Убедитесь, что у вас настроены разрешения на создание тенанта Loki в Grafana Cloud.
  • Убедитесь, что у вас есть разрешения администратора на источники данных в Grafana.
  • Убедитесь, что у вас настроена команда в Grafana.

Создание правила LBAC для источника данных для команды

  1. Перейдите к вашему источнику данных
  2. Перейдите на вкладку permissions
    • Здесь вы найдёте раздел правил LBAC для источников данных.
  3. Добавьте правило LBAC для источника данных
    • Добавьте новое правило для команды в разделе правил LBAC для источников данных.
  4. Определите селектор меток для правила
    • Добавьте селектор меток в правило. Обратитесь к документации за рекомендациями по типам селекторов логов, которые вы можете указать.

Правило LBAC

Правило LBAC — это запрос logql, который фильтрует логи или метрики на основе меток. Каждое правило действует независимо как собственный фильтр, отдельно от других правил внутри команды.

Например:

  • Для логов: {namespace="dev", cluster="us-west-0"} фильтрует строки логов, соответствующие одновременно namespace="dev" и cluster="us-west-0".
  • Для метрик: {job="api-server", region="europe"} фильтрует точки данных метрик, соответствующие job="api-server" и region="europe".

Одно правило {namespace="dev", cluster="us-west-0"}, созданное с несколькими пространствами имён, будет восприниматься как namespace="dev" И cluster="us-west-0". Два правила {namespace="dev"}, {cluster="us-west-0"}, созданные для команды, будут восприниматься как namespace="dev" ИЛИ cluster="us-west-0".

Лучшие практики

Мы рекомендуем добавлять разрешения query только тем командам, которые должны использовать источник данных, а разрешения Admin должны быть только у Admin.

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

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

Задачи

Задача 1: Настройка одного правила для каждой команды

Один из распространённых сценариев создания политики LBAC — предоставление доступа к логам или метрикам с определённой меткой. Например, вы можете создать политику меток, которая включает все строки логов или метрики с меткой namespace.

У нас есть две команды, Team A и Team B, с разрешениями Query. Доступ к источнику данных настроен так, что роли Admin имеют только разрешение Admin.

  • Team A имеет правило namespace="dev".

  • Team B имеет правило namespace="prod".

Пользователь, входящий в Team A, будет иметь доступ к логам или метрикам, соответствующим namespace="dev". Пользователь, входящий одновременно в Team A и Team B, будет иметь доступ к данным, соответствующим namespace="dev" ИЛИ namespace="prod".

Задача 2: Настройка правила для исключения метки для команды

Один из распространённых сценариев создания политики LBAC — исключение логов или метрик с определённой меткой. Например, вы можете создать политику меток, которая исключает все строки логов с меткой secret=true, добавив селектор с secret!="true" при создании политики доступа:

У нас есть одна команда, Team A, с разрешениями Query. Доступ к источнику данных настроен так, что роли Admin имеют только разрешение Admin.

  • Team A имеет правило secret!="true".

Пользователь, входящий в Team A, НЕ будет иметь доступа к логам или метрикам, соответствующим secret!="true".

Задача 3: Настройка нескольких правил для команды

У нас есть две команды, Team A и Team B, с разрешениями Query. Доступ к источнику данных настроен так, что роли Admin имеют разрешение Admin.

  • Team A имеет настроенное правило cluster="us-west-0", namespace=~"dev|prod".

  • Team B имеет настроенное правило cluster="us-west-0", namespace="staging".

Пользователь, входящий только в Team A, будет иметь доступ к логам, соответствующим cluster="us-west-0" AND (namespace="dev" OR namespace="prod").

Пользователь, входящий только в Team B, будет иметь доступ к логам, соответствующим cluster="us-west-0" AND namespace="staging".

Пользователь в Team A имеет доступ к логам в кластере us-west-0 с пространствами имён dev и prod. Пользователь в Team B имеет доступ ко всему в кластере us-west-0, кроме пространства имён prod. Таким образом, пользователь, являющийся членом и Team A, и Team B, имеет доступ ко всему в кластере us-west-0.

Пользователь, который не входит ни в одну команду с ролью Editor/Viewer, не будет иметь доступа к запросу каких-либо логов.

Важно

Пользователь Admin, входящий в команду, будет иметь доступ только к логам этой команды

Пользователь Admin, не входящий ни в одну команду с ролью Admin, будет иметь доступ ко всем логам

Задача 4: Пересекающиеся правила

У нас есть две команды, Team A и Team B.

  • Team A имеет правило namespace="dev".

  • Team B имеет правило namespace!="dev".

Пользователь в Team A будет иметь доступ к логам, соответствующим namespace="dev".

Пользователь в Team B будет иметь доступ к логам, соответствующим namespace!="dev".

ПРИМЕЧАНИЕ: Пользователь, входящий в Team A и Team B, будет иметь доступ ко всем логам, соответствующим namespace="dev" OR namespace!="dev".

Задача 5: Настройка одного правила для команды

У нас есть две команды, Team A и Team B. Доступ к источнику данных настроен так, что роли Editor, Viewer имеют разрешение Query.

  • Team A имеет настроенное правило namespace="dev".

  • Team B не имеет настроенного правила.

Пользователь, входящий в Team A, будет иметь доступ к логам, соответствующим namespace="dev".

Пользователь, входящий в Team A и Team B, будет иметь доступ к логам, соответствующим namespace="dev".

Пользователь, не входящий в Team A, но входящий в Team B, с ролью Editor или Viewer, будет иметь доступ ко всем логам (благодаря разрешению query для пользователя).

Задача 6: Пользователь A является Admin и входит в Team B

У нас есть команда B, пользователь A входит в Team B и имеет базовую роль Admin.

  • Team B не имеет назначенных ролей

  • Team B имеет разрешения Query на источник данных

  • Team B имеет правило { project_id="project-dev" }

Пользователь A может получать доступ только к логам или метрикам источника данных, соответствующим { project_id="project-dev" }.