Что касается вашего первого вопроса, роли Cloud IAM предназначены для управления уровнем доступа учетных записей пользователей к услугам и продуктам, которые существуют в вашем проекте. Роли IAM для облачных конечных точек позволяют ограничить, какие пользователи могут включить ваш API, но они не предлагают таких детальных разрешений, чтобы контролировать, как пользователи, которым действительно разрешено звонить, могут взаимодействовать с конкретными маршрутами Ваш API.
Теперь можно ограничить доступ к определенным методам API, ниже я опишу два подхода:
- Использование Auth0 и программная проверка авторизации пользователя : Когда пользователь, которому разрешено достигнуть конечной точки, делает запрос, его идентификатор передается в код обработки под заголовком
X-Endpoint-API-UserInfo
. Затем вы можете проверить, кто звонил, чтобы отменить ответ. Это потребует некоторой связи с базой данных для проверки пользователей с ограниченными правами или сомнительного наивного подхода жесткого кодирования пользователей. Этот подход solid с точки зрения безопасности, поскольку Cloud IAP блокирует доступ неавторизованных пользователей к API, а затем вы можете дополнительно ограничить области доступа по мере необходимости. Единственным недостатком этого метода является то, что он создает некоторую задержку. См. здесь для документации и ссылок на примеры кода на нескольких языках. - Ключи API : ключи API обеспечивают разрешение / ограничение доступа к отдельным методам до тех пор, пока вы можете дифференцировать маршруты конечных точек. Например, вы можете разрешить некоторым клавишам вызывать
yourendpoint/route/method1
, но ограничить yourendpoint/route/method2
. У этого есть несколько недостатков, во-первых, ключи API предназначены для идентификации проекта / приложения / веб-сайта / IP, а не отдельных пользователей, что не совсем то, о чем вы спрашиваете. Во-вторых, они менее безопасны, чем аутентификация, и как только ваш ключ API открыт, его может использовать почти любой, что может повлечь за собой непредвиденные расходы на ваш платежный аккаунт. Тем не менее, я хотел бы упомянуть об этом для полноты картины, поскольку это может быть полезно в других ситуациях. См. здесь для обзора ключей API.
В целом, я бы предложил использовать Auth0 с программной c аутентификацией.