Google CloudOverview
Use corporate login credentials instead of personal accounts, such as Gmail accounts.
Rationale
It is recommended fully-managed corporate Google accounts be used for increased visibility, auditing, and controlling access to Cloud Platform resources. Email accounts based outside of the user's organization, such as personal accounts, should not be used for business purposes.
Impact
There will be increased overhead as maintaining accounts will now be required. For smaller organizations, this will not be an issue, but will balloon with size.
Remediation guidance
Follow the documentation and setup corporate login accounts.
Prevention
To ensure that no email addresses outside the organization can be granted IAM permissions to its Google Cloud projects, folders or organization, turn on the Organization Policy for Domain Restricted Sharing. Learn more at: https://cloud.google.com/resource-manager/docs/organization-policy/restricting-domains
Default Value
By default, no email addresses outside the organization's domain have access to its Google Cloud deployments, but any user email account can be added to the IAM policy for Google Cloud Platform projects, folders, or organizations.
References
- https://cloud.google.com/docs/enterprise/best-practices-for-enterprise-organizations#manage-identities
- https://support.google.com/work/android/answer/6371476
- https://cloud.google.com/sdk/gcloud/reference/organizations/get-iam-policy
- https://cloud.google.com/sdk/gcloud/reference/beta/resource-manager/folders/get-iam-policy
- https://cloud.google.com/sdk/gcloud/reference/projects/get-iam-policy
- https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints
- https://cloud.google.com/resource-manager/docs/organization-policy/restricting-domains
Google Cloud Console (Asset-Level)
- Open the affected project/resource from the finding details in Google Cloud Console.
- Navigate to the resource security/configuration settings.
- Apply the control-specific secure configuration.
- Save and re-run the check.
Multiple Remediation Paths
Google Cloud
SERVICE-WIDE (RECOMMENDED when many resources are affected): Enforce Organization Policies at org/folder level so new resources inherit secure defaults.
gcloud org-policies set-policy policy.yaml
ASSET-LEVEL: Use the product-specific remediation steps above for only the impacted project/resources.
PREVENTIVE: Use org policy constraints/custom constraints and enforce checks in deployment pipelines.
References for Service-Wide Patterns
- GCP Organization Policy overview: https://cloud.google.com/resource-manager/docs/organization-policy/overview
- GCP Organization policy constraints catalog: https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints
- gcloud org-policies: https://cloud.google.com/sdk/gcloud/reference/org-policies
Operational Rollout Workflow
Use this sequence to reduce risk and avoid repeated drift.
1. Contain at Service-Wide Scope First (Recommended)
- Google Cloud: apply organization policy constraints at org/folder scope.
gcloud org-policies set-policy policy.yaml
2. Remediate Existing Affected Assets
- Execute the control-specific Console/CLI steps documented above for each flagged resource.
- Prioritize internet-exposed and production assets first.
3. Validate and Prevent Recurrence
- Re-scan after each remediation batch.
- Track exceptions with owner and expiry date.
- Add preventive checks in IaC/CI pipelines.
Query logic
These are the stored checks tied to this control.
Corporate login credentials are used instead of Gmail accounts
Connectors
Covered asset types
Expected check: eq []
GCPIAM1{...AssetFragment}
