У нас есть несколько заданий потока данных Google Cloud (написанных на Java / Kotlin), и их можно запускать двумя различными способами:
- Инициируется из учетной записи пользователя Google Cloud
- Инициировано из учетной записи службы (с необходимыми политиками и разрешениями)
При запуске задания Dataflow из учетной записи пользователя Dataflow предоставляет рабочему учетную запись контроллера по умолчанию .Он не предоставляет авторизованного пользователя рабочим.
При запуске задания Dataflow из учетной записи service, я предполагаю, что учетная запись service, установленная с помощью setGcpCredential , будет распространена на рабочие виртуальные машины, которыеПоток данных использует в фоновом режиме. JavaDocs не упоминает ничего из этого, но они упоминают, что учетные данные используются для аутентификации по отношению к сервисам GCP.
В большинстве случаев использования Dataflow мы запускаем Dataflowзадание в проекте A, в то время как мы читаем из BigQuery в проекте B. Следовательно, мы предоставляем пользователю доступ читателя к набору данных BigQuery в проекте B, а также к учетной записи службы, используемой вторым способом, как описано выше.Эта же учетная запись службы также будет иметь роли jobUser и dataViewer для BigQuery в проекте A.
Теперь проблема заключается в том, что в обоих случаях нам, по-видимому, необходимо предоставить учетную запись службы по умолчанию для контроллерас доступом к набору данных BigQuery, который используется в задании потока данных.В противном случае мы получим отказано в разрешении (403) для BigQuery, когда задание попытается получить доступ к набору данных в проекте B. Для второго описанного способа я ожидаю, что поток данных будет независимым от значения по умолчаниюКонтроллер сервиса.Я догадываюсь, что Dataflow не передает рабочую учетную запись, заданную в PipelineOptions, рабочим.
В общем, мы предоставляем проект, регион, зону, временные местоположения (gcpTempLocation, tempLocation, stagingLocation), тип бегуна(в данном случае DataflowRunner) и gcpCredential как PipelineOptions.
Итак, действительно ли Облачный поток данных Google действительно передает предоставленную учетную запись работникам?
Обновление
Сначала мы попытались добавить options.setServiceAccount, как указано Magda , без добавления разрешений IAM.Это приводит к следующей ошибке из журналов потока данных:
{
"code" : 403,
"errors" : [ {
"domain" : "global",
"message" : " Current user cannot act as service account dataflow@project.iam.gserviceaccount.com. Causes: Current user cannot act as service account dataflow@project.iam.gserviceaccount.com..",
"reason" : "forbidden"
} ],
"message" : " Current user cannot act as service account dataflow@project.iam.gserviceaccount.com.. Causes: Current user cannot act as service account dataflow@project.iam.gserviceaccount.com.",
"status" : "PERMISSION_DENIED"
}
После этого мы попытались добавить roles/iam.serviceAccountUser к этой учетной записи службы.К сожалению, это привело к той же ошибке.У этой учетной записи службы уже были роли IAM Работник потока данных и Пользователь задания BigQuery.Сервисный аккаунт контроллера вычислений по умолчанию 123456-compute@developer.gserviceaccount.com имеет только роль редактора, и мы не добавили никаких других ролей / разрешений IAM.