Поскольку служба B является частной (требует проверки подлинности), служба A должна будет включать заголовок HTTP-авторизации в запросы к службе B.
Заголовок выглядит так:
Authorization: Bearer <replace_with_token
токен является токеном идентификации OAuth 2.0 (не токен доступа). Адрес электронной почты члена IAM для учетных данных пользователя или учетной записи службы добавляется в службу B с ролью roles/run.invoker
.
Вам все равно нужно будет позвонить по URL-адресу конечной точки (xxx.y.run.app) службы B. Это не изменится, если вы также не внедрите пользовательские домены.
Приятной особенностью Cloud Run является то, что когда требуется проверка подлинности, прокси-сервер Cloud Run обрабатывает это для вас. Прокси находится перед Cloud Run и блокирует все неавторизованные запросы. Ваш экземпляр никогда не запускается, поэтому нет времени для выставления счетов, пока хакеры пытаются получить доступ.
В одной из моих статей на моем веб-сайте я показываю, как создать токен идентификации в Go ( ссылка ). В этой статье используется CURL ( ссылка ), которая состоит из трех частей. В Интернете есть множество статей, которые также объясняют это. В другой статье я объясняю, как работает Cloud Run Identity ( ссылка ) и как работает Cloud Run Identity Access Control ( ссылка ).
Просмотрите параметр --service-account, который позволяет настроить учетную запись службы для использования в качестве удостоверения ( ссылка ).
Документация по аутентификации в облачном хранилище ( ссылка ).