Share Google Cloud Access Safely (Projects, IAM Roles, and Workload Identity)

Why “just give Owner” backfires

Primitive roles like Owner/Editor grant sweeping powers across compute, storage, and billing. One rushed click can drop a database or expose a bucket. Instead, scope access per project and assign least-privilege IAM roles.

Safe baseline for any team

• Separate environments by project (e.g., proj-app-dev, proj-app-stg, proj-app-prod)—no cross-env “Owner.”
• Use Google Groups for access (bind roles to groups, not individuals) so onboarding/offboarding is one change.
• Prefer predefined roles (e.g., roles/storage.objectViewer, roles/run.developer, roles/logging.viewer) over Editor.
• Require MFA on the identity provider (Workspace/SSO) for anyone with GCP access. Need a strong master passphrase? See: How to Create Strong Passphrases You’ll Actually Remember.
• Turn on Cloud Audit Logs (Admin/Access/Data where relevant) and ship to BigQuery or a SIEM for retention.

Onboarding (10–15 minutes)

1. Verify the request by phone/known channel before clicking any invite. Quick checks: Verify Links Like a Pro.
2. Create/choose a Google Group for the role (e.g., gcp-app-devs@).
3. In IAM & Admin → IAM, grant a minimal predefined role to the group at the project level. Add more roles only when needed.
4. Document the scope (which services, what they can change) in a shared runbook.

Service accounts: keys are last resort

• Prefer Workload Identity Federation (short-lived credentials via OIDC) instead of JSON keys for CI/CD or other clouds.
• If a key is unavoidable, limit its scopes, store it outside repos, and rotate on a schedule. Delivery pattern: send via a one-time, expiring link and share the access code in a separate channel. Basics: The Safe Way to Share Passwords in 2025 (No Email).
• Org Policy: where possible, disable service account key creation and require Workload Identity.

Extra guardrails that pay off

• IAM Conditions: time-box roles or restrict by resource path/environment.
• Folder-level controls for entire envs (dev/stg/prod) instead of ad-hoc per project.
• Bucket hygiene: no public buckets by default; use per-service accounts with object access, not bucket-admin.

Offboarding & incidents

• Remove the user from the Google Group (access drops everywhere the group is bound).
• Revoke sessions and disable any service account keys they touched; rotate secrets and tokens. Guide: Rotate Shared Credentials on a Schedule.
• Audit recent actions in Cloud Audit Logs. If exposure is suspected, follow: The Simple Incident Playbook for Leaked Passwords and Audit Your Old Messages.

When you must share files or secrets

• Never email JSON keys or paste into chat. Use a one-time, expiring link + separate access code.
• For archives, use 7z/ZIP-AES with a long passphrase: Send Encrypted Archives Safely.
• Disable chat link previews to avoid auto-fetch: Prevent Accidental Link Previews.

Related reading

Share API Keys and .env Files (Safely) · Share AWS Access Safely · Send SSH Bastion Access with Short-Lived Keys

Bottom line

Scope by project, bind minimal roles to groups, prefer Workload Identity over keys, and log everything. That’s Google Cloud access without surprises.