Service Account Over-Privilege and Keys

Description

Over‑privileged service accounts (SAs) and long‑lived user‑managed keys enable broad access across projects and offline abuse if stolen. Common pitfalls include granting roles/owner or roles/editor, binding SAs at folder/org scope, leaving user‑managed keys active for years, embedding keys in code or CI, and using default compute SAs with broad scopes.

Examples

List Roles for SA

gcloud projects get-iam-policy <project> --flatten="bindings[].members" \
  --filter="bindings.members:serviceAccount:<sa>" --format="table(bindings.role)"
gcloud organizations get-iam-policy <org> --flatten="bindings[].members" \
  --filter="bindings.members:serviceAccount:<sa>" --format="table(bindings.role)"

Enumerate Keys

gcloud iam service-accounts keys list --iam-account <sa>
gcloud logging read "protoPayload.methodName=\"google.iam.admin.v1.CreateServiceAccountKey\" AND protoPayload.authenticationInfo.principalEmail:<sa>" \
  --limit 10 --format=json   # key creation audit trail

Remediation

1. Apply least privilege
   • Replace owner/editor with precise roles; scope bindings to the minimal project/resource.
2. Eliminate long-lived keys
   • Prefer Workload Identity Federation (GKE/Cloud Run/Github OIDC) or service‑to‑service tokens; disable user‑managed keys (gcloud iam service-accounts keys delete).
3. Rotation and monitoring
   • Rotate any remaining keys; monitor key creation/use in Cloud Audit Logs; restrict egress and store keys only in secure secret managers.