Workload Identity Federation in GCP избавляет от долгоживущих JSON-ключей при machine-to-machine access. Компромисс — более сложная первоначальная настройка, зато модель безопасности и эксплуатации становится значительно чище.
Старый подход был простым, но хрупким. CI/CD-инструменту или сторонней системе требовался доступ к GCP project, поэтому команда создавала service account, скачивала JSON key и сохраняла его как secret. Это работало, но создавало постоянные credentials, которые нужно было защищать, ротировать и аудировать. Если ключ истекал, требовалось обновлять каждого его потребителя. Если же срок действия не ограничивался, потенциальный blast radius при утечке оставался фактически открытым.
Именно поэтому важен Workload Identity Federation in GCP. Он заменяет хранимые secrets на federated identity и short-lived access tokens. Вместо передачи credentials внешней системе вы определяете, каким внешним identity providers доверяет GCP и при каких условиях. В результате получается более контролируемая модель аутентификации для CI/CD, AWS workloads и других внешних систем, которым необходимо обращаться к GCP.
Архитектура при этом не выглядит лёгкой — и в этом как раз её смысл. WIF состоит из трёх частей: workload identity pool, provider и service account binding. Pool объединяет конфигурации внешних identities. Provider определяет, откуда поступают tokens и каким образом GCP их проверяет. Service account binding предоставляет прошедшей валидацию identity реальные IAM permissions.
По сравнению с JSON key это больше настроек и больше шагов. По сравнению с long-lived secrets это избавляет от постоянной операционной нагрузки, связанной с их хранением и ротацией.
В статье подчёркивается один важный момент: команда не стала мигрировать всё сразу. Такой проект был бы значительно сложнее. Вместо этого была введена политика для новых GCP projects: ни один новый проект больше не получает service account key. Новые deployments используют Harness pipelines, GitHub Actions workflows и AWS Lambda functions через federated identity.
Это решение перенесло проблему из постоянно растущего secret estate в ограниченную модель, где legacy risk больше не увеличивается.
Конкретная реализация зависит от исходной платформы, но общий паттерн остаётся тем же. Современные CI/CD-системы, такие как GitHub Actions и Harness, выдают short-lived OIDC JWTs. GCP проверяет issuer, сопоставляет claims с attributes и применяет CEL attribute condition в качестве последнего уровня контроля.
Именно это условие имеет большое значение: оно ограничивает, какие identities действительно получают доступ. В multi-org конфигурациях отсутствие проверки organization может сделать policy слишком permissive. В статье это отмечается как одна из важных ошибок при определении scope, за которой стоит следить.
С AWS ситуация несколько отличается. AWS не использует OIDC для этих workload tokens. Вместо этого применяется собственный STS-based flow. GCP доверяет AWS account, а затем проверяет identity, выполняя вызов AWS STS GetCallerIdentity с подписанным запросом, предоставленным workload.
Таким образом, GCP доверяет не просто некоторой метке или заявленному имени. Он просит AWS криптографически подтвердить identity.
Для архитекторов это ключевая идея: внешняя платформа становится источником доказательства, а GCP — системой, которая это доказательство проверяет.
Есть и интересный компромисс при выборе способа impersonation. Google по умолчанию рекомендует direct access, однако, согласно статье, команда в некоторых конфигурациях выбрала impersonation. Это прагматичное решение, а не универсальное правило. Оно добавляет уровень косвенности, зато лучше подходит в ситуациях, когда необходимо сохранить GCP permissions на границе service account, а не назначать их непосредственно каждой external identity.
Операционный результат оказался более стабильным, чем при старой secret-based модели. Более 120 проектов перешли на WIF в течение шести месяцев. Legacy keys не исчезли полностью, но перестали множиться.
Именно так часто и происходит реальное улучшение инфраструктуры: не обязательно сразу очищать каждый исторический edge case. Гораздо эффективнее изменить default path, чтобы система постепенно становилась безопаснее.
Для команд с большими CI/CD estates это и есть главный урок. Secret-based machine authentication создаёт скрытые операционные затраты на rotation, auditing и incident response. Workload Identity Federation переносит эту работу в первоначальную настройку trust configuration. Она требует больше дисциплины на старте, но в долгосрочной перспективе снижает operational drag и делает модель доступа значительно более прозрачной.