Доступ к набору данных BigQuery, когда член специальной группы

Question

В BigQuery вы можете настроить доступ на уровне набора данных.

Согласно документации :

BigQuery добавляет доступ к набору данных по умолчанию для следующих объектов: access.specialGroup: projectReaders; access.role: ЧИТАТЕЛЬ; access.specialGroup: projectWriters; access.role: ПИСАТЕЛЬ; access.specialGroup: projectOwners; access.role: ВЛАДЕЛЕЦ; access.userByEmail: [электронная почта создателя набора данных]; access.role: OWNER;

Однако, Мне не удалось найти детерминированную c эквивалентность таких specialGroup значений для ролей политики проекта .

Ссылочная документация не проливает много света на этот аспект:

Специальная группа, к которой предоставляется доступ. Возможные значения включают: projectOwners: Владельцы включающего проекта. projectReaders: Читатели вмещающего проекта. projectWriters: Авторы вмещающего проекта. allAuthenticatedUsers: все аутентифицированные пользователи BigQuery. Сопоставление с членами IAM с одинаковыми именами.

Насколько я понимаю, (пожалуйста, исправьте меня, если я ошибаюсь) эти значения идентифицируют всех членов в рамках политики проекта, чьи границы Роль является одной из следующих:

• projectOwners -> roles/bigquery.dataOwner (и / или roles/owner?)
• projectWriters -> roles/bigquery.dataEditor (и / или roles/editor?)
• projectReaders -> roles/bigquery.dataViewer (и / или roles/viewer?)

Но в конце эти ролей не более чем набор из разрешений , верно? Итак, что произойдет, если есть пользовательская роль, которая содержит то же подмножество прав доступа , что и bigquery.dataViewer? Могут ли пользователи, связанные с этой ролью, также получить доступ к наборам данных?

Итак, мой вопрос:

Имеют ли значения specialGroup детерминированный c эквивалент? с ролями проекта и если да, то что это?

Конечная цель - определить, кто именно может получить доступ к набору данных, настроенному непосредственно в доступе к набору данных или унаследованному с помощью политик проекта.

Answer 1

Возможные значения «specialGroup» аналогичны примитивным ролям для проектов:

• projectOwners -> Владельцы проектов
• projectWriters -> Редакторы проектов
• projectReaders -> Средства просмотра проектов

Если вы попробуете API-метод get dataset в наборе данных, по умолчанию это "объект доступа", который вы ' В ответе будет указано следующее:

"access": [
    {
      "role": "WRITER",
      "specialGroup": "projectWriters"
    },
    {
      "role": "OWNER",
      "specialGroup": "projectOwners"
    },
    {
      "role": "OWNER",
      "userByEmail": "userWhoCreatedTheDataset@gmail.com"
    },
    {
      "role": "READER",
      "specialGroup": "projectReaders"
    }
  ]

Возможные значения "роли" ссылаются на разрешение, предоставленное для этого указанного c набора данных, которое по умолчанию предоставляется аналоговому проекту. роли уровня (возможные значения «specialGroups»). Создателю набора данных также предоставляется доступ ВЛАДЕЛЬЦА набора данных, хотя и не в специальной группе, а в значении userByEmail. Однако, если пользователь, создавший набор данных, также является владельцем проекта, он также будет принадлежать к специальной группе projectOwners.

Что касается пользовательских ролей, то вы правы, роль - это набор разрешений, если вы создайте настраиваемую роль с точно такими же разрешениями, что и bigquery.dataViewer, и затем вы, например, предоставите учетной записи службы эту настраиваемую роль, и у нее будут те же разрешения, как если бы ей была предоставлена ​​роль bigquery.dataViewer.