Служба аутентификации Google Cloud Run-to-Service - PullRequest
Новая
       81

Служба аутентификации Google Cloud Run-to-Service

1 голос
/ 03 ноября 2019

У меня есть две службы (API), развернутые в GCP Cloud Run. Назовите их service-one.myDomain.com и service-two.myDomain.com. Я хотел бы, чтобы service-one проходил аутентификацию при вызове service-two независимо от того, что делает любой пользователь.

Я прочитал и выполнил инструкции из документации GCP Cloud Run по аутентификации между сервисами (https://cloud.google.com/run/docs/authenticating/service-to-service), но service-one.myDomain.com не удалось вызвать service-two.myDomain.com, получив 401: Несанкционированный ответ.

Есть мысли о том, как заставить service-one успешно позвонить service-two?

Вот мои настройки:

IAM и учетные записи служб:

В Google IAM я создал две учетные записи службы и предоставил им обеим роль «Cloud Run Invoker» (roles/run.invoker): service-one@myproject.iam.gserviceaccount.com service-two@myproject.iam.gserviceaccount.com

Внутри Cloud Run я изменил учетную запись службы с «По умолчанию»вычислить учетную запись службы "для учетных записей службы, которые я создал. Я назначил service-one@myproject.iam.gserviceaccount.com для service-one.myDomain.com и service-two@myproject.iam.gserviceaccount.com для service-two.myDomain.com

токен OAuth:

В service-one.myDomain.com я делаювызовите сервер метаданных, чтобы получить токен OAuth (jwt) из следующего URL: http://metadata/computeMetadata/v1/instance/service-accounts/default/identity?audience=https://service-two.myDomain.com с заголовком запроса, установленным как {'Metadata-Flavor': 'Google'} Запрос выполнен успешно, и полученный мной токен декодируется, чтобы иметь следующую полезную нагрузку: 

{
  "alg": "RS256",
  "kid": "9cef5340642b157fa8a4f0d874fe7543872d82db",
  "typ": "JWT"
}

{
  "aud": "https://service-two.mydomain.com",
  "azp": "100959068407876085761",
  "email": "service-one@myproject.iam.gserviceaccount.com",
  "email_verified": true,
  "exp": 1572806540,
  "iat": 1572802940,
  "iss": "https://accounts.google.com",
  "sub": "100953168404568085761"
}

Http-запрос:

Использованиетокен я делаю запрос от service-one.myDomain.com к конечной точке http на service-two.myDomain.com. Я установил заголовок запроса с помощью {'Authorization': 'Bearer {token}'} ({token} - значение токена).

Http-ответ:

Ответ - 401 Unauthorized, и мои журналы показывают, что заголовки ответа включают:

{'WWW-Authenticate': 'Bearer error="invalid_token" error_description="The access token could not be verified"'}

С содержанием: 

"
<html><head>
<meta http-equiv="content-type" content="text/html;charset=utf-8">
<title>401 Unauthorized</title>
</head>
<body text=#000000 bgcolor=#ffffff>
<h1>Error: Unauthorized</h1>
<h2>Your client does not have permission to the requested URL <code>/health</code>.</h2>
<h2></h2>
</body></html>
"

Я в тупике ... любые идеи о том, что мне не хватает, чтобы получить service-oneаутентифицироваться на service-two?

Ответы [ 2 ]

1 голос
/ 04 ноября 2019

Ответ состоял в том, чтобы использовать в качестве аудитории в запросе токена OAuth прогон облака gcp, сгенерированный URL-адрес. И, соответственно, поле "Aud" в JWT.

Мое обнаружение состояло в том, что аутентификация между сервисами в облачной среде не поддерживает пользовательские домены (myDomain.com). Я использовал свой собственный домен.

(я чувствую себя тупым) благодаря @ guillaumeblaquiere

1 голос
/ 04 ноября 2019

Ваша ошибка (HTTP 401) в Google Cloud обычно означает, что ваш токен имеет неверный / поврежденный / неправильный формат.

В сообщении об ошибке указано «Не удалось проверить токен доступа», что подтверждает это предположение. Это сообщение означает, что подпись токена недействительна.

Отображаемый токен кажется действительным. kid - для текущего сертификата публичной подписи Google, который вы можете найти по адресу https://www.googleapis.com/oauth2/v1/certs

Тело токена также правильное, имеет правильную аудиторию и т. Д.

Это оставляетпроблема в том, что где-то между получением токена и отправкой токена вы либо повреждаете его, либо не отправляете полученный токен.

[ОБНОВЛЕНИЕ]

Я заметил из комментариев, что последнее решение заключается в использованииправильная конечная точка DNS. Использование неправильного DNS-имени предотвратит авторизацию (пользовательское доменное имя).

...