Why long-lived keys are hard to contain
Applications need identities to read objects, deploy infrastructure, or call cloud APIs. A downloaded service-account key can live in a CI variable, container image, developer laptop, backup, or log long after its original purpose is forgotten. Anyone who obtains the key can act as that identity until the key is revoked or expires.
Google Cloud's current service-account guidance recommends avoiding service-account keys where a more secure authentication method is available. Its workload identity federation guidance describes exchanging an external identity for short-lived cloud credentials. Similar short-lived role-based credentials are available for workloads inside AWS and Azure.
A workload should prove its identity when it runs. It should not carry a permanent credential everywhere it goes.
What federation changes
With workload identity federation, a cloud platform trusts a specific identity provider and accepts a signed assertion from an approved workload. The workload exchanges that assertion for temporary credentials. It then uses those credentials to call only the resources its identity is authorized to reach.
For example, a CI runner can present an OIDC token tied to an approved repository and deployment environment. Google Cloud can validate that identity and issue short-lived access, directly or through service-account impersonation. The job does not need a downloaded JSON key stored as a CI secret.
This is not automatic least privilege. Federation changes how a workload authenticates; IAM policy still determines what it can do. A badly scoped federated identity is still a badly scoped identity.
A controlled migration plan
1. Inventory credentials and owners
List user-managed service-account keys, where each is used, its last observed use, its owner, and the resources it can access. Include CI/CD systems, scheduled jobs, containers, third-party integrations, and scripts on virtual machines. Flag keys without a named owner or a clear business purpose.
2. Choose one low-risk workload
Start with a non-production pipeline or a read-only reporting job. Confirm that its platform can provide a supported workload identity, such as an attached cloud role or an OIDC token. Bind only the specific repository, project, branch, or environment that should authenticate.
3. Scope permissions before switching
Create a dedicated identity for the workload. Grant only the resource-level roles it needs. Avoid granting federation to every member of a pool; use stable, authoritative identity attributes and explicit conditions. Keep production deploy permissions separate from test and preview environments.
4. Test the failure path
- Confirm an approved job can obtain a token and complete its expected operation.
- Confirm a job from an unapproved repository or branch is denied.
- Confirm access expires and cannot be reused after the job ends.
- Review audit logs to make sure the workload identity and target resources are visible.
- Document a rollback path before removing the old key.
5. Revoke the old key and verify
After successful testing, disable the old key first where the platform permits. Monitor the workload through a normal operating cycle. Remove the key only after logs confirm the federated identity is handling all expected calls and no dependent process has failed.
Controls that still matter
- Short duration: Prefer the shortest token lifetime compatible with the task.
- Dedicated identities: Separate identities by application and environment so compromise stays bounded.
- Stable claims: Restrict access using verifiable issuer, audience, repository, branch, or environment attributes.
- Auditable access: Send authentication and authorization events to central logging and alert on unexpected principals.
- Key exceptions: Track any remaining static keys with an owner, restricted permissions, protected storage, and a rotation deadline.
Federation also introduces dependencies on the identity provider, token exchange service, and accurate trust configuration. Test availability and failure behavior. Avoid creating one broad identity pool or shared service account that silently becomes a new point of concentration.
Make progress without a risky cutover
A practical first month can be simple: spend week one inventorying credentials, week two selecting a pilot, week three implementing and testing federation, and week four disabling the pilot's former key after a successful observation period. Treat that as a planning sequence, not a universal deadline. Critical systems may need longer validation.
For deeper guidance, see Google Cloud Workload Identity Federation, its federation best practices, secure service-account practices, and NIST SP 800-207 Zero Trust Architecture. These are implementation references, not a substitute for testing your own access paths.
Credential sprawl is manageable when identities have owners, permissions are narrow, and access expires. If you want a second set of eyes on cloud identity design or a safe migration plan, book a free consultation.