Google’s Budgets and alerts example shows project selection for a multi-project user and explicitly warns that a budget does not cap resource or API consumption. The project, currency, amount and alert thresholds are vendor examples. Verify the actual billing scope and recipient authority; this screen is not proof of a spending limit or a successfully delivered alert.[7] View full-size image
A Google Cloud review must calculate effective access across the resource hierarchy and billing account, not simply export one project’s IAM page. Broad roles can be inherited from the organization or folder, service accounts can be impersonated, and billing authority can exist outside project administration. Every finding needs a principal, resource, role, path of inheritance, business purpose, and remediation owner.
Do not remove Owner, Editor, Service Account Token Creator, billing administration, key access, or a project link before tracing workload and recovery dependencies. Test a replacement role or identity and preserve policy plus audit evidence. Disabling a questionable service account before deletion can provide a safer observation window while keeping bindings recoverable.
ALLMSP coordinates Google Cloud access, ownership, and security review from Lawrenceville for clients in Suwanee, across Gwinnett County and Metro Atlanta, and throughout Georgia, through one accountable in-house workflow from discovery and correction through testing, training, and ongoing support.
Evidence to collect before changing Cloud IAM and billing
A useful review identifies human and non-human principals, inherited and direct roles, basic roles, service account impersonation paths, keys, external identities, billing authority, orphaned projects, budget ownership, logging coverage, and recovery gaps. Findings are ranked by reachable resources and business impact.
- Organization, folder, project, resource, service account, and billing account IAM policies.
- Effective access for Owners, Editors, administrators, external domains, groups, and service account impersonators.
- Service account purpose, attached workloads, key inventory, authentication activity, and domain-wide delegation.
- Billing account roles, payment ownership, linked projects, budgets, alerts, exports, and cost contacts.
- Cloud Audit Logs for IAM, project, billing, key, and service account changes.
- Projects outside expected hierarchy, inactive workloads, missing owners, and untested emergency access.
Worked example: three Cloud findings that need different fixes
These hypothetical cases illustrate authorization and billing boundaries. They do not describe a real organization's resources, costs, or successful remediation.
| Finding | Boundary to establish | Appropriate next action |
|---|---|---|
| A deployment user has Service Account User on a privileged identity. | Can the user also create or update a resource that runs as that identity? actAs is not the same permission as Token Creator. | Review both the deployment permission and attached identity's access before narrowing the grant. |
| A vendor has Token Creator on that service account. | The vendor may mint short-lived credentials with the identity's authority without using its private key file. | Identify the supported workload and replace unnecessary standing impersonation after a controlled test. |
| A project has a monthly budget and a project cost viewer. | The budget is an alert, and project cost visibility does not establish billing-account/payment authority. | Verify recipients and the authorized billing administrator; do not call the budget a spending cap. |
Calculate effective human and service account access
Organization and folder inheritance
What to check: Record direct and inherited roles, conditions, deny policies, groups, domains, and exceptions. For each broad role, identify the highest resource where it is granted and every child environment it reaches.
What to do next: Move access to the narrowest practical resource, replace basic roles, and test required actions before removing the inherited grant.
Owner and Editor roles
What to check: List every human, group, service account, domain, and external identity with Owner or Editor. Record business purpose, last activity, authentication protection, reachable production resources, and replacement role options.
What to do next: Replace basic roles with predefined roles, preserve at least two controlled recovery paths, and remediate service accounts using Editor before routine user cleanup.
Service account impersonation
What to check: Identify users and workloads that can attach, act as, or create tokens for each privileged service account. Compare the principal's own permissions with the greater access available through impersonation.
What to do next: Remove unjustified impersonation, grant access on individual service accounts rather than an entire project, and protect more-privileged identities from less-privileged users.
Separate attachment from token creation. Service Account User supplies actAs for attaching the identity when the principal has the other required resource permissions. Service Account Token Creator can create short-lived credentials. Both can matter to the risk review, but they are not interchangeable grants.
Supporting documentation: [5]
Review billing authority and project ownership
Service account keys and federation
What to check: Record key ID, creation date, last use where available, owner, storage, workload, rotation, and whether an attached identity, impersonation, or Workload Identity Federation could replace it.
What to do next: Disable unused accounts before deletion, migrate viable workloads to keyless authentication, rotate necessary keys, and apply organization policy to reduce new key creation.
Keep private key material out of the audit workbook. Use key identifiers and a named workload owner to plan a supported replacement. Test the new authentication route before disabling an unexplained production key or service account.
Supporting documentation: [2]
Billing account permissions
What to check: List Billing Account Administrators, Users, Viewers, Costs Managers, payment profile owners, support contacts, and outside accounts. Record which principals can link projects, change billing settings, view cost, or manage payments.
What to do next: Separate finance, project-linking, cost analysis, and payment responsibilities. Remove stale external or former users after company-controlled replacements are tested.
Project ownership and billing links
What to check: Record every active, suspended, and pending-deletion project, billing account, environment, workload, technical owner, business owner, cost owner, and lifecycle decision. Flag projects outside the expected organization.
What to do next: Assign missing owners, move or recreate projects in the approved hierarchy when appropriate, quarantine unknown resources, and close unused projects through documented retention and recovery steps.
Budgets, alerts, and exports
What to check: Capture scope, thresholds, recipients, alert delivery, owner, linked projects, export dataset, permissions, freshness, and whether management mistakes a budget for a spending cap.
What to do next: Create missing accountable alerts, correct stale recipients, protect the export dataset, and add operational controls for services that need an actual limit or shutdown procedure.
Inspect keys, logs, and recovery paths
Audit log coverage
What to check: Confirm Admin Activity and System Event availability, required Data Access logs, IAM and billing change visibility, sink filters, destination access, retention, exclusions, and alert coverage for critical changes.
What to do next: Enable required logs, correct broken sinks and broad destination access, and create actionable alerts for high-impact policy, key, project, and billing changes.
External identities and domains
What to check: List consumer accounts, outside domains, vendors, federated subjects, dormant invitations, and groups that contain external members. Record contract owner, access purpose, resource scope, and review date.
What to do next: Remove access without a current sponsor, narrow scopes, use controlled federation or groups, and prevent unmanaged identities from receiving new broad grants.
Emergency and ownership recovery
What to check: Confirm two authorized recovery paths, strong authentication, credential custody, alerting, business approval, and a test record. Identify dependence on one employee, agency, personal account, or payment profile.
What to do next: Create and test company-controlled recovery before removing current access. Monitor every emergency use and require post-use review and credential protection.
Rank findings by reachable cloud impact
Rank access by what a principal can ultimately reach. A narrow-looking role that can impersonate a powerful service account may be more dangerous than a visible project editor. Billing loss, project deletion, production control, key creation, log tampering, and organization-level inheritance deserve immediate attention.
Priority 1: Organization, billing, or production compromise
Use this level for unknown Owners, exposed keys, unjustified privileged impersonation, payment or billing loss, suspicious project changes, disabled logging, or access that can alter production across several projects.
Priority 2: Fragile ownership and preventable privilege
Use this level for basic roles, shared default service accounts, untested recovery, one-person billing administration, unlabeled production projects, stale vendors, and key-based workloads that can move to safer authentication.
Priority 3: Governance and documentation debt
Use this level for naming, labels, missing review dates, stale viewers, incomplete budget routing, and unclassified low-risk projects after active security and continuity risks are controlled.
Frequently Asked Questions
How can inherited Google Cloud IAM access be reviewed accurately?
Start with the resource hierarchy and follow each grant from organization or folder down to the target project or resource. Include group membership, conditions, deny policies, and other applicable controls; the project's direct IAM list alone is incomplete. Record both the source of the grant and the workload it supports before narrowing access.
FAQ supporting documentation: [4]
Why are Google Cloud Owner and Editor roles risky?
They are broad basic roles that often give a person or workload substantially more authority than one task requires. Their presence warrants a dependency review, not immediate removal. Map the actual administrative or application operation to a narrower predefined or justified custom role, test that replacement, and retain a recovery administrator during the change.
FAQ supporting documentation: [4]
What should be checked for service account impersonation risk?
Check who can attach the service account to a workload and who can create credentials as it. Service Account User includes actAs for attaching an identity when other resource permissions are present; Token Creator can mint short-lived credentials. Audit both routes, the service account's own privileges, keys, delegation, and the workloads affected before revoking a grant.
FAQ supporting documentation: [5]
How should existing Google Cloud service account keys be audited?
For each user-managed key, establish its service account, creation date, owner, storage location, workload, and evidence of use. Never copy private key material into the review. Prefer a supported keyless identity design where practical, test the replacement, then disable and retire the obsolete key through a planned change rather than deleting an unexplained production credential.
FAQ supporting documentation: [2]
Which Google Cloud billing permissions should be reviewed?
Review the billing account, linked projects, and payment profile as separate authorization scopes. Someone able to view project costs may not administer the billing account or payment method. Linking a project also requires suitable permissions on both the project and destination billing account. Confirm who can authorize a move or resolve billing loss without changing a live project's billing during a routine audit.
FAQ supporting documentation: [6]
How can orphaned Google Cloud projects be found?
Reconcile the organization/folder project inventory with billing records, workload owners, deployed resources, and scheduled automation. An unfamiliar name, quiet project, or missing label does not prove abandonment. Identify a responsible business owner and retention or dependency requirements first; isolate or retire a project only through an approved service change with a recovery plan.
FAQ supporting documentation: [4]
What should be checked in a Google Cloud budget review?
Check the budget's billing scope, period, included projects/services, threshold basis, notification recipients, and any linked automation. A Google Cloud budget sends alerts; it does not automatically cap spending. Test delivery to a maintained recipient and review automated responses separately, including delays and the service interruption they could cause.
FAQ supporting documentation: [7]
Which Cloud Audit Logs matter during an IAM review?
Review Admin Activity for administrative changes, System Event logs for Google-generated resource changes, and the Data Access logs needed for the specific service and investigation. Data Access logging is not uniformly enabled by default; availability, configuration, retention, routing, and charges vary. Verify what is actually collected before promising that a missing event proves no access occurred.
FAQ supporting documentation: [8]
How should vendor and external access to Google Cloud be reviewed?
Identify external users, groups, federated principals, service accounts, keys, and impersonation paths, then map each to an approved support task and owner. Check inherited access and time or resource conditions as well as direct project roles. Replace unsupported standing privilege with a tested, appropriately scoped access method; do not strand a production workload by removing its vendor identity without handover.
What proves a business can recover Google Cloud administration?
An independent authorized backup administrator must be able to reach the relevant organization/projects and the separate billing controls required for continuity. Confirm strong authentication, supported recovery methods, escalation contacts, and a documented test that avoids destructive resource or billing changes. A working project Owner account alone does not establish payment-profile control or recovery for the wider organization.
Related ALLMSP Resources
Sources
- Google Cloud IAM overview. Official explanation of principals, roles, resources, policies, inheritance, and fine-grained authorization in Google Cloud, with the planning steps on this page applying it to the work needed to audit Google Cloud roles, service accounts, and billing access. ↩
- Google Cloud service-account security practices. Official guidance for limiting service-account privilege, avoiding unnecessary keys, tracking ownership, and reducing impersonation risk, with the configuration checks here applied to the controls needed to audit Google Cloud roles, service accounts, and billing access. ↩
- Google Cloud Billing access control. Official guidance for billing-account roles, project cost access, payment-profile permissions, budgets, and administrative control, with the review process on this page using that guidance to help the organization audit Google Cloud roles, service accounts, and billing access. ↩
- Using resource hierarchy for access control. ↩ ↩ ↩ ↩ ↩
- Roles for service account authentication. ↩ ↩ ↩ ↩
- Enable, disable, or change billing for a project. ↩ ↩ ↩
- Create, edit, or delete budgets and budget alerts. ↩ ↩
- Cloud Audit Logs overview. ↩
