#google-cloud-platform #google-cloud-auth
#google-cloud-platform #google-cloud-auth
Вопрос:
Каковы эквивалентные вызовы rest api для них?
gcloud auth activate-service-account --key-file=myvaultkey.json
export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
Ответ №1:
См. раздел Использование OAuth2 для приложений между серверами
Вы можете gcloud показать базовые вызовы REST API, добавив --log-http к любой команде.
В этом случае часть работы включает обновление gcloud локальной конфигурации для использования учетной записи службы, но вы можете проигнорировать эту часть и сосредоточиться на создании JWT и использовать его для получения токена доступа, который затем можно использовать для вызова API (ов).
Я рекомендую вам использовать один из SDK от Google, а не делать это с помощью базовых API. На странице документации, на которую ссылается выше, объясняются оба подхода, и вы увидите, что использование SDK не только тривиально, но и обеспечивает надежную гарантию того, что вы правильно (надежно) реализуете поток.
Комментарии:
1. «Корпоративная» ситуация, в которой я нахожусь, ограничивается только предоставленным хранилищем gcpkey. json для gcp-проекта. Однако мне нужно обновить эти токены в давно запущенном java-приложении (это означало бы использование api-вызова, а не cli, верно?).
2. Интересный вопрос. Да, я так думаю. Единственной альтернативой было бы извлечение скриптом ключа из хранилища для аутентификации
gcloudс его помощью. Это зависит от корпоративной политики, но я предполагаю (по понятным причинам), что они не хотят, чтобы вы сохраняли ключи локально. Я думаю, вам следует рассмотреть возможность использования SDKs>> Вызовов REST API. Вероятно, существует (я им не пользовался) механизм, который поддерживает извлечение ключа из хранилища и передачу его в SDK без сохранения его на диске.3. «без сохранения на диске» — Спасибо за вашу помощь. Я попробую ‘—log-http’ и посмотрю, смогу ли я выполнить обновление токена и т. Д. Без сохранения ключа на диске. Пока я вижу, что sdk полагается только на переменную env GOOGLE_APPLICATION_CREDENTIALS , GOOGLE_OAUTH_ACCESS_TOKEN …
4. Существует средство, называемое учетными данными приложения по умолчанию (или «ADC»). Это очень полезно. Когда код выполняется в службе GCP (compute), служба может автоматически получать АЦП (например, из службы метаданных в Compute Engine). Когда код выполняется с помощью GCP (например, локально), ADCs ищет
GOOGLE_APPLICATION_CREDENTIALSключ учетной записи службы. Смотрите: cloud.google.com/docs/authentication/production Вам не нужно использовать АЦП с SDK. Вы можете просто указать местоположение ключа и указать SDK для получения учетных данных таким образом5. Я предполагаю (но не пробовал), что вы можете объединить SDK от Google, например, с хранилищем Hashicorp (и другими хранилищами), чтобы ваш код получал ключ из хранилища, а затем передавал его клиенту SDK, чтобы клиент мог аутентифицироваться без необходимости сохранения файла на диске.