WM Blog · Clara

Service Accounts Outlive Every Residency Policy

Australian teams still issue long-lived credentials for background jobs without binding them to local identity anchors. The accounts keep authenticating through foreign control planes long after any policy review ends.

Illustration showing a service account credential leaking identity traffic across international boundaries

Your infrastructure lead at a 120-person Melbourne logistics platform signs off on a new batch processing cluster. The vendor supplies a service account with a ten-year key rotation schedule and no region lock on the token endpoint.

The account authenticates against a global directory every night when pulling freight manifests. Each request crosses the same trust boundary the compliance team claimed was closed after the last audit.

Static policy documents list approved regions and approved identity providers. They say nothing about the runtime path a service account actually takes once it leaves the Kubernetes namespace.

When the manifests contain customer delivery addresses, those details transit through the provider's European auth layer before returning to the Australian cluster. The data never triggers a residency alert because the check only runs at account creation.

Engineering keeps shipping new jobs that reuse the same credential set. Each addition widens the surface without touching the original approval ticket.

The security lead only discovers the pattern after a customer complains about delayed manifests and an external log review shows the auth traffic pattern. By then the credential has already been copied into three downstream pipelines.

Bind service account issuance to a local identity broker that refuses tokens unless the assertion carries an explicit Australian jurisdiction claim. Reissue every existing long-lived key under that rule within the next sprint.

Identity Management Data Residency Service Accounts Trust Boundaries