У меня есть служба, прослушивающая «https://myapp.a.run.app/dosomething», но я хочу использовать функции масштабируемости Cloud Run, поэтому в контроллере для «dosomething» я отправляю 10 запросов на « https://myapp.a.run.app/smalltask'; с моим приложением, настроенным на обслуживание только одного запроса на экземпляр, я ожидаю, что 10 экземпляров раскрутятся, все выполнят свою маленькую задачу и вернутся (все в течение периода ожидания).
Но я не знаю, как правильно аутентифицировать запрос, поэтому все эти 10 запросов приводят к ошибке 403. Для сервисов Cloud Run я вручную передаю токен носителя с первоначальным запросом, хотя в какой-то момент я ожидаю добавить некоторый прокси-сервер API. Но без указанного API-прокси, как правильно отправить запрос, чтобы он был принят? Приложение работает от имени пользователя, у которого есть разрешения на доступ к конечной точке.
Аутентификация между службами
Если в вашей архитектуре используется несколько сервисов, эти сервисы, скорее всего, должны взаимодействовать друг с другом.
Вы можете использовать синхронную или асинхронную связь между службами:
Для асинхронной связи используйте
Для синхронной связи
Одна служба вызывает другую через HTTP, используя URL своей конечной точки. В этом случае рекомендуется убедиться, что каждая служба может выполнять запросы только к определенным службам. Например, если у вас есть служба входа в систему, она должна иметь доступ к службе профилей пользователей, но, вероятно, не должна иметь доступа к службе поиска.
Во-первых, вам нужно настроить принимающую службу для приема запросов от вызывающей службы:
roles/run.invoker
) удостоверению вызывающей службы в принимающей службе. По умолчанию это идентификатор [email protected]
.В службе вызова вам потребуется:
Создайте подписанный Google токен идентификатора OAuth с аудиторией (aud
), настроенной на URL-адрес принимающей службы. Это значение должно содержать префикс схемы (http://
или https://
), а личные домены в настоящее время не поддерживаются для значения aud
.
Включите токен ID в заголовок Authorization: Bearer ID_TOKEN
. Вы можете получить этот токен с сервера метаданных, пока контейнер работает в Cloud Run (полностью управляемый). Если приложение работает за пределами Google Cloud, вы можете сгенерировать токен идентификатора из файла ключа сервисного аккаунта.
Полное руководство и примеры в Node/Python/Go/Java и других см. в статье: Аутентификация между службами
Убедитесь, что token_request_url = metadata_server_token_url + receiving_service_url
обычно люди забывают добавить последнее.
Часть, которая у меня была - проблема заключалась в том, что мой uri префикс «http» вместо «https». FWIW, руководство по Python обновлено для использования библиотечной функции специально для получения токенов метаданных, поэтому google.oauth2.id_token.fetch_id_token(auth_req, target_audience)
вместо прямого вызова http://metadata/computeMetadata/...
. Я думаю, что красивее с использованием библиотеки.
Чтобы подтвердить, в основном единственный вариант - запросить токен перед тем, как сделать фактический запрос?
Спасибо за быстрый ответ! Тем не менее, даже после того, как я следовал руководству (попробовав как подход с аутентификацией документа, так и подход с учебным пособием), я вижу 401 в своих журналах обслуживания. Идентификатор, связанный со службой, которую я подтвердил, имеет разрешения на вызов для себя; возможно, это недокументированное ограничение, что служба не может вызывать себя?