Service account key creation is blocked: check organization policy first
When service account key creation is blocked, the reason may be an organization policy even if project-level IAM looks correct.
Published · Updated
Problem
A user has IAM permissions but still cannot create a service account key.
Why it happens
GCP organization policy can disable service account key creation across folders or projects. Project-level IAM alone does not override that policy, so the failure can look confusing if you only inspect the project.
Recommended approach
Check organization policy first, then decide whether an exception is justified or whether a safer keyless approach should be used instead.
Checks and alternatives
Things to check:
iam.disableServiceAccountKeyCreation- Organization policy inheritance
- Folder or project policy status
- Service account permissions
- Workload Identity or instance service account alternatives
Use this when
- GCP environments with centralized security policies
- Compliance-constrained projects
- Organizations that restrict long-lived keys
Avoid this when
- Projects where service account key creation is intentionally allowed and the issue is only missing IAM permission
Common mistakes
- Debugging only at the project IAM layer
- Requesting broad exceptions before checking inherited policy
- Creating keys by habit when a keyless pattern is available
Recognize the organization-policy error
The CLI commonly returns FAILED_PRECONDITION with a reference to constraints/iam.disableServiceAccountKeyCreation. This is different from a PERMISSION_DENIED response caused by missing IAM permissions.
bash
gcloud iam service-accounts keys create key.json \
--iam-account=<service-account>@<project-id>.iam.gserviceaccount.comDo not retry with broader project roles when the error names an organization-policy constraint. Project IAM cannot override a constraint inherited from a folder or organization.
Inspect the effective policy
bash
gcloud org-policies describe constraints/iam.disableServiceAccountKeyCreation \
--project=<project-id> \
--effectiveIf needed, repeat the inspection at the parent folder and organization. You need appropriate Organization Policy permissions to see or change policies.
Google Cloud organizations created on or after May 3, 2024 can have this constraint enforced by default, so a newly created organization may behave differently from an older one.
Prefer a keyless authentication method
Choose the alternative based on where the workload runs:
- Google Cloud compute: attach a service account to the workload
- GKE: use Workload Identity Federation for GKE
- GitHub Actions or another external OIDC provider: use Workload Identity Federation
- Local development: use user Application Default Credentials or service-account impersonation
- Cross-service automation: use short-lived impersonated credentials
Long-lived JSON keys are bearer credentials. Copying one into CI secrets avoids the policy symptom but reintroduces leakage, rotation, attribution, and offboarding risks.
If an exception is truly required
Document the workload, owner, threat model, expiry date, storage location, rotation interval, and why federation or impersonation is not viable. Prefer a conditional, resource-scoped exception over disabling enforcement for the entire organization.
After creation:
- Store the key in an approved secret manager
- Never commit the JSON file
- Restrict the service account to least privilege
- Monitor key usage
- Rotate it and disable the old key before deletion