google-cloud-recipe-auth

Официальный навык Google для разбора аутентификации и авторизации в Google Cloud. Он начинает с различия между authentication — доказательством того, кто обращается к ресурсу, — и authorization — определением того, что этому principal разрешено делать через IAM. Перед конкретным советом навык предлагает уточнить четыре вещи: кто аутентифицируется, где работает код, к какому API или приложению нужен доступ и используется ли высокоуровневая клиентская библиотека. Эти вопросы разделяют локальную разработку, production-сервис, пользовательское приложение и вызов собственного API. Для людей и рабочих команд описаны Google-managed accounts, Google Workspace и Cloud Identity, обычная федерация с внешним IdP и Workforce Identity Federation. Важное различие касается локальных инструментов: gcloud auth login аутентифицирует сам CLI, а gcloud auth application-default login создаёт локальные Application Default Credentials, которые подхватывают клиентские библиотеки. Для администратора или разработчика предпочтительна Service Account Impersonation с короткоживущими credentials вместо скачивания постоянного JSON-ключа service account. Это особенно полезно при отладке: сначала нужно понять, какой именно identity flow используется, иначе корректная роль IAM не исправит неверный тип credential. Для конечных пользователей и клиентов навык разделяет workforce-доступ и вход в приложение. Identity-Aware Proxy может быть центральным слоем защиты внутреннего веб-приложения, а Identity Platform предназначена для CIAM-сценария, где в собственное приложение добавляется вход пользователей по email, телефону или социальным провайдерам. Выбор зависит от того, защищается ли уже размещённое приложение или строится пользовательская идентичность внутри продукта. В production-коде навык рекомендует service account, а не человеческий аккаунт. Вместо ключей следует прикреплять пользовательский service account к ресурсу: Compute Engine получает identity при создании VM, Cloud Run — в конфигурации сервиса, а среда выдаёт токен через metadata server. Для GKE описан Workload Identity Federation, связывающий Kubernetes identities с IAM principal identifiers. Для кода вне Google Cloud, включая AWS, Azure и on-premises, предлагается Workload Identity Federation с обменом внешнего токена на короткоживущий Google Cloud access token, а не хранение статического ключа. Отдельно разобраны API keys и OAuth access scopes. API key подходит только для поддерживаемых упрощённых или публичных сценариев; его нужно ограничить конкретными API и проектами, а хранить — в Secret Manager. Access scopes остаются важной проверкой для старых Compute Engine VM и GKE node pools: даже правильная IAM-роль не поможет, если scope слишком ограничен. Для impersonation и безопасного service-to-service обмена навык указывает IAM Service Account Credentials API, который может выдавать короткоживущие access token, OIDC ID token или self-signed JWT. На уровне авторизации IAM связывает principal и role с resource; сначала стоит использовать predefined roles с наименьшими необходимыми разрешениями, а custom roles оставлять для случаев, когда готовые роли слишком широки. В качестве проверяемых сценариев приведены локальный Python-клиент с ADC и ролью storage.objectViewer, Cloud Run с прикреплённым service account и ролью cloudsql.client, а также вызов приватного Cloud Run через Google-signed OIDC ID token в заголовке Authorization. Навык полезен как маршрут выбора identity и проверки least privilege; он не выдаёт права сам и не отменяет настройку IAM, Secret Manager, ограничений API key или Kubernetes identity в целевом проекте.