Google Cloud structure: projects, billing and IAM

Why the structure matters

In Google Cloud, everything you create is a resource: a virtual machine, a storage bucket, a database, a Pub/Sub topic. Every resource belongs to exactly one project. Projects can be grouped into folders, and folders sit under one organisation. This tree is called the resource hierarchy.

The hierarchy decides two important things. First, who pays: billing is attached to projects. Second, who can do what: access rules attached to a level of the tree flow down to everything below it. If you design the tree well, managing hundreds of projects stays simple. If you design it badly, you spend your time fixing permissions one project at a time.

The four levels

An organisation resource only exists when you sign up with Google Workspace or Cloud Identity for your domain. A student using a personal Gmail account can still create projects. They simply have no organisation above them, so folders and organisation-wide rules are not available.

Project ID, project name and project number

• Project name: a friendly label such as "Payroll Production". It does not have to be unique and you can change it at any time.
• Project ID: a globally unique identifier such as payroll-prod-4821. You choose it when you create the project (Google suggests one). It uses 6 to 30 lowercase letters, digits and hyphens and starts with a letter. It can never be changed, and commands and URLs use it.
• Project number: a number Google assigns automatically. You see it in some service account names and in logs and API responses.

Billing accounts and budgets

A Cloud Billing account holds the payment method, such as a card or an invoiced company account. One billing account can pay for many projects, but each project is linked to at most one billing account at a time. If a project has no billing account linked, most paid services in it cannot run.

A budget is a spending target you set on a billing account, for all projects or a chosen few. You add alert thresholds, for example 50%, 90% and 100% of the amount, and Google emails the billing administrators when actual or forecast costs cross them.

IAM: who can do what, where

Identity and Access Management (IAM) answers one question: who can do what on which resource. A principal (the "who") is granted a role (the "what") on a resource (the "where"). The grants are stored in an allow policy attached to the resource. A policy is a list of bindings, and each binding pairs one role with a list of principals.

• A Google account, written user:asha@acme.in, is a person.
• A Google group, written group:analysts@acme.in, lets you grant once to a whole team.
• A service account, written serviceAccount:name@PROJECT_ID.iam.gserviceaccount.com, is an identity for a program.
• A domain, written domain:acme.in, means every account in your Workspace or Cloud Identity domain.

A role is a set of permissions such as storage.objects.get or compute.instances.start. There are three kinds. Basic roles (Owner, Editor and Viewer) are very broad: Editor can change almost everything in a project. Avoid them in production. Predefined roles are made by Google for each service, for example roles/storage.objectViewer or roles/cloudsql.client. Custom roles let you pick exact permissions when no predefined role fits.

{
  "bindings": [
    { "role": "roles/storage.objectViewer", "members": ["group:analysts@acme.in"] },
    { "role": "roles/cloudsql.client", "members": [
        "user:asha@acme.in",
        "serviceAccount:payroll-app@payroll-prod-4821.iam.gserviceaccount.com" ] }
  ]
}

Inheritance: policies flow downwards

A policy set on the organisation applies to every folder, project and resource below it. A policy on a folder applies to every project in that folder. The access a principal really has on a resource is the union of the policy on that resource and the policies on all its ancestors. You cannot remove an inherited role by leaving it out lower down. (Google Cloud has separate deny policies for blocking, which are an advanced topic.)

Service accounts and keys

A service account is how a program proves who it is. The safest way is to attach the service account to the thing that runs your code, such as a VM or a Cloud Run service. Google client libraries then fetch short-lived tokens automatically. For code running outside Google Cloud, for example in GitHub Actions or on AWS, use workload identity federation: the outside system exchanges its own token for short-lived Google credentials.

You can also download a service account key as a JSON file. That file is a long-lived secret: anyone who finds it can act as the service account until someone deletes the key. Use keys only as a last resort. Many organisations block key creation completely with an organisation policy.

Regions and zones

A region is a geographic area, such as asia-south1 (Mumbai) or asia-south2 (Delhi). A zone is an isolated location inside a region, such as asia-south1-a. Some resources are zonal (a VM and its disk), some are regional (a subnet), and some are global (a VPC network). Indian companies often keep data in asia-south1 or asia-south2 for low latency and data-residency rules.

gcloud basics

gcloud init                                    # log in, choose a default project and region
gcloud projects list                           # projects you are allowed to see
gcloud config set project payroll-prod-4821    # default project for later commands
gcloud config set compute/region asia-south1   # default region
gcloud config list                             # show the current account, project and region
gcloud projects get-iam-policy payroll-prod-4821 --format=json   # who has which role

Common mistakes and how to fix them

• Giving everyone the Editor role. Fix: grant predefined roles to groups, not basic roles to individuals.
• Granting at the organisation level what one project needs. Fix: grant at the lowest level that does the job.
• Downloading service account keys and committing them to Git. Fix: attach service accounts, or use workload identity federation.
• Running a delete command against the wrong project. Fix: check gcloud config list first, or pass --project explicitly.