Enforce Foundational IAM Organization Policy Constraints
Specification & Description
Apply foundational IAM Organization Policy constraints at the organization root to restrict identity domains, prevent automatic broad role grants on default service accounts, and block unmanaged public key uploads.
Technical Specifications
Google Cloud Organization Policies act as immutable guardrails that enforce security baselines across all projects and folders, superseding local project IAM permissions. This control establishes four core IAM constraints at the organization root:
-
Domain Restricted Sharing (constraints/iam.allowedPolicyMemberDomains): Restricts IAM role bindings exclusively to your corporate Cloud Identity or Google Workspace customer ID (e.g., C01234567). This blocks accidental or intentional grants to personal
@gmail.comaccounts or external tenants. -
Disable Default Service Account Role Grants (constraints/iam.automaticIamGrantsForDefaultServiceAccounts): By default, activating APIs like Compute Engine or App Engine automatically creates default service accounts (e.g.,
[PROJECT_NUMBER]-compute@developer.gserviceaccount.com) and binds them to the primitiveroles/editorrole across the entire project. This policy disables that automatic privilege assignment. -
Disable Service Account Key Upload (constraints/iam.disableServiceAccountKeyUpload): Blocks users from uploading self-generated public keys to service accounts, preventing the creation of untracked external credentials.
-
Service Account Key Expiry (constraints/iam.serviceAccountKeyExpiryHours): For approved legacy exceptions where keys are strictly unavoidable, this constraint enforces an absolute maximum lifespan (e.g., 2160h / 90 days) on user-managed keys.
Security Rationale
Default Google Cloud project configurations favor rapid onboarding over security isolation. Without Domain Restricted Sharing, a rogue or compromised project owner can bind sensitive storage buckets or compute instances to an external personal account without triggering organizational identity validation. Furthermore, the default Compute Engine service account with roles/editor creates an instant lateral movement path: any compromised VM can modify IAM policies, read cloud secrets, and destroy project assets. Enforcing these constraints at the organization root eliminates default privilege escalation vectors and guarantees that all projects conform to baseline identity governance from inception.
Policy Exceptions (1)
Projects hosting multi-tenant customer integrations or SaaS applications that require granting IAM bindings to external customer Google accounts can configure an explicit override exception on a dedicated subfolder, provided external identities are logged and reviewed quarterly.
Operational & Implementation Notes
Enforcing Domain Restricted Sharing does not retroactively remove existing external IAM bindings. Before applying the policy, run an Asset Inventory IAM query across all projects to identify and remediate any existing bindings granted to domains outside your Cloud Identity directory.