Лучшая стратегия аутентификации для клиентского инструмента GCP

Я хочу создать клиентский инструмент gcp на python.

Я хочу избежать вызова инструмента glcoud через subprocess, поэтому я выбираю клиентскую библиотеку sdk призывы.

Согласно документам, а также этой очень всеобъемлющей статье, там есть два варианта аутентификации:

а) с использованием учетных данных приложения по умолчанию (т.е. тех, которые используются gcloud под капотом)

б) используя учетную запись службы и указав приложению соответствующий .json файл.

Я уже пробовал (а) и получил следующее предупреждение:

UserWarning: ваше приложение прошло аутентификацию с использованием учетных данных конечного пользователя из Google Cloud SDK. Мы рекомендуем вместо этого использовать в большинстве серверных приложений учетные записи служб. Если ваше приложение продолжает использовать учетные данные конечного пользователя из Cloud SDK, вы можете получить ошибку «превышена квота» или «API не включен». Для получения дополнительной информации об учетных записях служб см. https://cloud.google.com/docs/authentication/
warnings.warn (_CLOUD_SDK_CREDENTIALS_WARNING)

Если я использую кредиты приложения по умолчанию, это упрощает задачу, поскольку каждый конечный пользователь, которому будет распространяться приложение, будет иметь этот .json файл как источник истины для его / ее процесса авторизации. Однако приложение может столкнуться с указанной выше ошибкой quota exceeded.

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

Мы будем очень признательны за любые советы по этому поводу.


person pkaramol    schedule 13.10.2019    source источник


Ответы (2)


Существует несколько типов учетных данных приложения по умолчанию (ADC): учетная запись пользователя и учетная запись службы, а также их разновидности. Предупреждающее сообщение в вашем вопросе означает, что вы настроили интерфейс командной строки SDK с учетными данными пользователя (gcloud auth login). Я рекомендую перейти на учетные данные сервисного аккаунта.

Эта команда настроит интерфейс командной строки с учетной записью службы. Вам понадобится ваш идентификатор проекта и файл JSON сервисного аккаунта.

gcloud auth activate-service-account test@PROJECT_ID.iam.gserviceaccount.com --key-file=service_account.json

Я написал статью, в которой подробно рассказывается о том, как настроить CLI:

Настройка Gcloud с учетными данными учетной записи службы

Почему Google выдает предупреждение:

  • Авторизация учетных данных пользователя требует дополнительных усилий в серверных службах Google.
  • Для создания учетных данных учетной записи пользователя требуется вмешательство человека.
  • Токен обновления часто хранится программным обеспечением на клиенте или серверной части. Это создает брешь в безопасности.
  • Программное обеспечение должно использовать межмашинную аутентификацию с ограниченными разрешениями (областями). Учетные данные пользователя обычно выдаются со слишком большим количеством разрешений для выполняемых вызовов API. Это снова проблема безопасности.
  • Google решил, что учетным данным пользователя не будет разрешено иметь области, необходимые для доступа ко многим сервисам Google Cloud Platform. Это очень очевидно при создании клиентов OAuth, и вы получаете большое предупреждение о проверке. Существует серьезный риск того, что Google перестанет разрешать учетные данные пользователей для облачных служб. Лучше использовать поддерживаемый и официальный метод учетной записи службы и не сталкиваться с этой проблемой в будущем.

Однако, учитывая приведенные выше сведения, ваш вариант использования предоставляет пользователям учетные данные. Это плохая идея. Я бы продолжил использовать учетные данные пользователя для общения с вашим веб-интерфейсом. Ваш веб-интерфейс использует учетную запись службы, которую пользователь никогда не видит, и предоставляет окончательный доступ к службе (API).

[ОБНОВИТЬ]

Я только что заметил ваш комментарий о том, что вы разрабатываете свой собственный интерфейс командной строки. Без дополнительной информации о том, к каким проектам / службам будет осуществляться доступ к этому интерфейсу командной строки, вы можете рассмотреть возможность использования учетных данных пользователя, которые взаимодействуют с вашей службой, которая выдает пользователю токен доступа. Этот токен действителен только в течение одного часа. Вы можете поддержать обновление этого токена в своем коде. Это дает вам возможность использовать аутентификацию пользователя, контролировать использование учетной записи службы и при этом поддерживать хорошую безопасность. Обратите внимание, что я пытаюсь увести вас от распространения файлов учетной записи службы напрямую пользователям. Если эти пользователи являются вашими сотрудниками, это не проблема. Для людей, неподконтрольных вам, подумайте внимательно.

[КОНЕЦ ОБНОВЛЕНИЯ]

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

В другом случае (учетные данные для учетной записи службы) я предполагаю, что мне придется предоставить инструкции каждому разработчику для выпуска файла json, который соответствует учетной записи службы с тем же разрешением, что и его / ее.

Если бы мне пришлось написать приложение, использующее учетные данные учетной записи службы, я бы создал метод для загрузки / установки учетных данных. Просто предоставьте файл и скажите им сделать этот шаг в программе. Однако у вас есть проблема. Распространять одну и ту же учетную запись службы среди всех пользователей - не лучшая идея. Как вы справляетесь с отзывом и т. Д.? Учетные записи службы Google Cloud Platform не предназначены для однозначного распространения среди более чем нескольких десятков или сотен пользователей в рамках одного проекта.

А как насчет процесса обновления?

У файлов ключей JSON с учетными данными службы не истекает срок действия. Срок действия токенов, созданных из учетной записи службы, действительно истекает, но это управляется клиентскими библиотеками Google или вашим собственным кодом для их автоматического обновления.

Что происходит каждый раз, когда пользователю назначаются / отменяются некоторые разрешения? Как этот JSON синхронизируется?

Файл учетной записи службы не содержит разрешений. Они хранятся в Google Cloud IAM. После изменения ролей, назначенных учетной записи службы, они прозрачно применяются глобально в течение нескольких минут.

person John Hanley    schedule 13.10.2019
comment
спасибо за развернутый ответ. Мой главный вопрос заключается в следующем: Учитывая, что а) мое требование состоит в том, чтобы инструмент cli отражал точно разрешения, которые они (пользователи / разработчики инструмента) в любом случае имеют через gcloud б) Я хочу, чтобы они иметь возможность выполнять (несколько) межпроектных действий, например mycli list projects, как будет работать следующая команда, поскольку для нее требуется конкретный идентификатор проекта: gcloud auth activate-service-account test@PROJECT_ID.iam.gserviceaccount.com --key-file=service_account.json - person pkaramol; 14.10.2019
comment
Я уверен, что есть способ обойти эту проблему, но мне нужно пройти через свой ИТ, чтобы вмешаться в IAM (поэтому я хочу свести к минимуму мое стандартное взаимодействие с консолью Gloud (в идеале, даже если весь процесс сложен, я хотел бы иметь это взаимодействие при инициализации через мой код на Python). - person pkaramol; 14.10.2019
comment
например на данный момент каждый разработчик может запустить gcloud projects list и получить список проектов, к которым у него есть доступ. Как это можно сделать по api (я имею в виду с точки зрения настройки авторизации) - person pkaramol; 14.10.2019
comment
Итак (извините за множество сообщений) это заставляет меня задуматься: разве мне не нужен точный механизм аутентификации, что и gcloud? (которые, если я правильно понимаю, являются учетными данными приложения по умолчанию) - person pkaramol; 14.10.2019
comment
Пожалуйста, создавайте отдельные вопросы. Stackoverflow - это не дискуссионный форум. Большинство ваших вопросов требуют более длинных ответов, чем позволяют комментарии, или могут быть ценной информацией для других. Большинство не читают комментарии, только ответы. - person John Hanley; 14.10.2019

Если предполагается, что инструмент будет использоваться только в интерактивном режиме (например, при замене gcloud), скорее всего, можно будет использовать учетные данные по умолчанию, так как использование будет низким.

Тем не менее, создание ключа для учетной записи службы - довольно сложная операция либо в консоли, либо через gcloud, а API делает ее использовать ключ достаточно просто - вы просто устанавливаете GOOGLE_APPLICATION_CREDENTIALS переменную среды. Дополнительные сведения см. На этой странице. Использование учетных записей служб также позволяет вам назначать именно те роли, которые требуются, вместо того, чтобы работать с широкими разрешениями, которые может иметь учетная запись пользователя, и это снижает вероятность ошибок, когда код делает что-то, чего не должен.

person robsiemb    schedule 13.10.2019
comment
Однако я вижу, что ключи учетной записи службы привязаны к проекту; это, я полагаю, сделает такие операции с инструментами, как mytool list all-projects-I-have-access-to, трудными (если не невозможными) с помощью определенного метода (?) - person pkaramol; 13.10.2019
comment
И да, инструмент будет использоваться только в интерактивном режиме как cmd и своего рода gcloud замена - person pkaramol; 13.10.2019
comment
Вы можете предоставить сервисные учетные записи вне текущих ролей в этом проекте. См. Этот вопрос: stackoverflow.com/questions/ 35479025 / - person robsiemb; 13.10.2019
comment
Причина того, что SDK CLI gcloud не выдает предупреждение, заключается в том, что этот инструмент использует специальный идентификатор клиента OAuth. Этот идентификатор клиента внесен в белый список Google. Как я уже упоминал в своем ответе, Google Cloud Platform больше не хочет, чтобы вы использовали учетные данные пользователя, и постепенно это усложняет. В конце концов, я предполагаю, что они будут отброшены, за исключением доступа к консоли. - person John Hanley; 14.10.2019