Service-account JSON without the sprawl

Prefer identity federation

Cloud workloads can often obtain short-lived credentials from their runtime identity instead of reading a downloaded key. CI systems and external clouds may support workload identity federation based on signed job or platform assertions. This removes a persistent private key and ties access to an execution context.

Create purpose-specific accounts

When a service account is necessary, give each workload and environment its own identity. Avoid a single “automation” account spanning unrelated jobs. Grant exact resource permissions rather than broad project roles, record an owner, and prohibit interactive human use.

If a key cannot be avoided

Generate it through an approved process, deliver it directly into the target secret manager, and delete intermediate downloads. Do not attach JSON keys to tickets, email them, place them in shared drives, bake them into images, or paste them into CI configuration that exposes values to untrusted builds.

Detect and rotate

Inventory active keys and their last use. Alert on creation outside the deployment process and authentication from unexpected environments. Rotation requires creating a replacement, updating and verifying every consumer, disabling the old key, watching for failures, and then deleting it.

Design away from files

The long-term target is a system where policy grants a workload short-lived access based on verifiable identity. That makes expiration automatic, reduces secret distribution, and produces stronger audit context than an identical key copied across machines.

Sources and review basis

This guide is maintained as defensive-security education. The editorial team reviews its recommendations against current implementation experience and these authoritative references:

• Google Cloud: service-account key practices
• OWASP Secrets Management Cheat Sheet