Как работать с неинтерактивной аутентификацией для облачных конечных точек: учетные записи служб, ключи API или пользовательские? - PullRequest
0 голосов
/ 30 июня 2019

Я на стадии планирования для создания API, который будет развернут на GCP с использованием облачных конечных точек.Мы ожидаем, что многие наши пользователи будут получать доступ к API из своих собственных автоматизированных рабочих процессов.Поэтому аутентификация не может включать в себя любое взаимодействие с пользователем.Учитывая это требование, назначение каждому клиенту ключа API кажется почти идеальным выбором.Однако это имеет серьезные недостатки в отношении безопасности, как упомянуто здесь: https://cloud.google.com/endpoints/docs/openapi/authentication-method

Приведенная выше ссылка также указывает, что учетные записи служб могут использоваться для аутентификации.Таким образом, похоже, что другим подходом было бы создать учетную запись службы для каждого из наших пользователей API с разрешениями проекта, чтобы они могли делать только вызовы наших конечных точек.Тем не менее, https://cloud.google.com/iam/docs/service-accounts указывает, что для каждого проекта существует ограничение в 100 учетных записей служб.Ограничение нашего сервиса до 100 клиентов недопустимо.

Существует ли наилучшая практика для настройки неинтерактивной аутентификации для облачных конечных точек, которая обеспечивала бы более высокую безопасность, чем обеспечивается только ключами API, и могла бы масштабироваться более 100 поддерживаемых пользователей API?

Я могу представить создание пользовательской службы, которая будет имитировать то, что GCP уже обрабатывает с помощью своих учетных записей служб, - создание веб-токена JSON (JWT) из хранимой учетной записи с парами открытого и закрытого ключей.Но надеюсь не изобретать велосипед, если не требуется.Если требуется что-то нестандартное, существуют ли другие службы Google (или сторонние библиотеки), которые могут выполнять тяжелую работу по пользовательской реализации?

...