Использование токенов OAuth2 для интерактивного использования сервисов GCP вместо сервисной учетной записи (ключей)

Question

Чтобы ограничить количество учетных записей служб для управления, а также для обработки их ключей, я изучаю другие способы доступа к ресурсам GCP с ноутбука или настольного компьютера разработчика, чтобы можно было запускать специальные сценарии или интерактивные программы (например, Блокнот Jupyter), которые получают доступ к сервисам GCP.

Использование gcloud auth application-default login после проверки подлинности через веб-браузер создает токен обновления, который можно использовать для получения и обновления токенов доступа, которые можно использовать для взаимодействия со службами GCP.

Рабочий процесс, за которым я следую, таков:

1. Выполнить gcloud auth application-default login. Это создает файл JSON на моем диске, который содержит токен обновления.
2. Экспорт местоположения файла JSON как GOOGLE_APPLICATION_CREDENTIALS переменная env GOOGLE_APPLICATION_CREDENTIALS=/Users/my.username/.config/gcloud/application_default_credentials.json 1014 *
3. Используйте этот файл для аутентификации через библиотеку авторизации Google и взаимодействия с различными сервисами GCP.

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

Если я не пропустил что-то здесь, это делает файл application_default_credentials.json таким же чувствительным, как и ключ учетной записи службы. Если он потерян или скомпрометирован, его можно использовать для получения токенов доступа без необходимости повторной аутентификации, что довольно небезопасно, IMO.

Нам известны рекомендации по безопасности GCP, в которых рекомендуется использовать служебную учетную запись (и их ключи) для межсервисных рабочих нагрузок. Этот сценарий, который я описываю, предназначен для специальной разработки / тестирования кода из ноутбук разработчика или инженера. Мы считаем, что принуждение пользователей к интерактивной аутентификации через Интернет для получения новых токенов каждые несколько часов было бы более безопасным и удобным, чем использование долгосрочных служебных ключей учетной записи, хранящихся на жестком диске.

Я прочитал [1], но не смог найти окончательного ответа.

• Кто-нибудь знает, есть ли срок действия этих токенов обновления?
• Есть ли способ контролировать и ограничивать их время жизни (в идеале часами или минутами)?
• Какова наилучшая / распространенная практика для этого сценария? Использовать одну учетную запись службы (и ключ) для отдельного пользователя?

[1] https://developers.google.com/identity/protocols/OAuth2#expiration

Answer 1

Примечание. У учетных данных пользователя также есть токены обновления.

Кто-нибудь знает, существует ли срок действия этих токенов обновления?

Токены обновления Google OAuth не имеют срока действия,Они могут быть отозваны.

Есть ли способ контролировать и ограничивать их время жизни (в идеале часами или минутами)?

Вы можете периодически отзывать жетон обновления, который будетсделать недействительными токены Access и Client ID.Это означает, что вы обрабатываете токены обновления, которые добавляют еще одну проблему безопасности для управления.

Каков наилучший / распространенный способ для этого сценария?Использовать одну учетную запись службы (и ключ) для отдельного пользователя?

Если вы используете учетные данные пользователя (метод входа в Google), вы будете получать предупреждения SDK и, если вы создадите много APIзвонки, вы будете заблокированы.Google не хочет, чтобы вы использовали учетные данные пользователя вместо учетных данных учетной записи службы.Процесс проверки учетных данных пользователя требует больше усилий в бэкэнд-системах Google.Предполагается, что учетные данные пользователя создаются в небезопасной среде (веб-браузеры), а учетные данные учетной записи службы - в защищенной среде.

Рекомендуется выпускать файлы ключей JSON учетной записи службы для отдельного приложения, имеющего тольконеобходимые разрешения для этого приложения для работы.Например, если вы создаете инструмент, который должен только читать объекты облачного хранилища, создайте учетную запись службы только с разрешениями на чтение.Периодически следует менять ключи учетной записи службы, загружать новые ключи и удалять старые ключи.Каждое приложение должно иметь свой собственный файл ключа JSON учетной записи службы.Я написал статью о том, как безопасно хранить ключевые файлы JSON в облачном хранилище.Это помогает вращать клавиши, так как ваше приложение просто загружает последнюю версию ключа, когда это необходимо.( ссылка * * одна тысяча двадцать-два).В моей статье обсуждается Google Cloud Run, но применяются те же принципы.