Say a new data analyst joins your team and asks for access to one BigQuery table. The quickest fix is to make them an Editor on the whole project. It takes ten seconds. It also lets them change your Cloud Run services, touch your storage buckets, and delete things they never needed to see.
Google Cloud IAM exists to stop exactly that. IAM stands for Identity and Access Management, and it controls who can do what on which resource in your Google Cloud project.
Last reviewed: November 2026
In this guide:
- What is Google Cloud IAM?
- Types of IAM roles
- Why use IAM?
- When to use IAM
- How to create IAM access, with 4 examples
- How to check and remove access
- Mistakes to avoid
- FAQs
What Is Google Cloud IAM?
Google Cloud IAM is the access control system built into Google Cloud. Before any action goes through, whether someone opens a bucket or an app runs a query, IAM checks if that identity has permission.
Think of an office with key cards. Your card identifies you, your access level decides what you are allowed to do, and each door is something you may or may not open. A cleaner and a finance manager work in the same building, but their cards open different doors.
Every Google Cloud IAM grant has the same three parts:
| Part | Question it answers | Example |
|---|---|---|
| Principal | Who? | analyst@example.com |
| Role | What can they do? | roles/bigquery.dataViewer |
| Resource | Where? | The shop dataset |
Google stores these grants in an allow policy. It is simply a list attached to a resource that says which principals hold which roles.
What Is a Principal?
A principal is any identity that can receive access. In Google Cloud IAM, it is usually one of these:
- Google Account: One person, such as a developer.
- Google group: A team. Add or remove people from the group, and you never have to touch the policy.
- Service account: An identity for an app or script instead of a person.
- Federated identity: A person or workload signed in through an outside provider.
What Is a Permission?
A permission is one small action, written like storage.objects.get. That one means “read a file in Cloud Storage”. You cannot give someone a permission directly. You give them a role, and the role carries the permissions.
Types of Google Cloud IAM Roles
| Role type | What it gives | Use it for |
|---|---|---|
| Basic | Very broad access across services | Quick testing, not production |
| Predefined | Access to one service, maintained by Google | Almost everything |
| Custom | Only the permissions you pick | Gaps that predefined roles do not cover |
Start with predefined roles. Google keeps them updated for you, while a custom role is one more thing you have to maintain.
How Access Is Inherited
Google Cloud resources sit in a hierarchy: organization, folder, project, then resources like buckets and datasets. Access given at a higher level flows down.
So if you grant a role on a project, it also applies to the resources inside it. This catches a lot of beginners out. A policy on one bucket adds access, but it does not take back what someone already got from the project. Blocking that needs a separate deny policy.
Why Use Google Cloud IAM?
- Smaller mistakes: Someone with read-only access cannot delete your production table by accident.
- Less damage from a leak: If an app is compromised, the attacker only gets that app’s limited access.
- No passwords in code: Apps running on Google Cloud can use a service account instead of a stored key.
- Easy team changes: When someone leaves, you remove them from one group.
- A clear record: Cloud Audit Logs show changes to your allow policies, so you can review who changed what.
- No extra bill: Google lists the IAM API as free of charge. You pay only for the other services you use.
When to Use Google Cloud IAM
Honestly, you are already using it. Every project has Google Cloud IAM from day one, and even a solo developer holds the Owner role. The real question is when to stop relying on that one powerful account. Set up proper access when:
- A second person joins the project.
- Your app needs to talk to BigQuery, Cloud Storage or another service.
- A contractor needs access for a few weeks.
- You move anything to production.
- A scheduled job or workflow runs without a person watching it.
How to Create Google Cloud IAM Access
One thing to clear up first: you do not create or deploy an “IAM service”. It is already switched on in your project. What you actually create is one of these:
- A role grant, which gives someone access.
- A service account, which gives an app its own identity.
- A custom role, when no predefined role fits.
The Google Cloud IAM examples below use a small online shop, the same one from our Google Cloud Run tutorial. Replace PROJECT_ID, the email addresses and the bucket names with your own.
Example 1: Give an Analyst Read-Only Access to BigQuery
The analyst needs two things: permission to run queries in the project, and permission to read one dataset. Start with the first one in the console.
- Open the IAM page and select your project.
- Click Grant access.
- Enter the analyst’s email address as the principal.
- Under Select a role, search for BigQuery Job User and select it.
- Click Save, then check that the new entry appears in the list.
This command does the same job from the terminal:
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="user:analyst@example.com" \
--role="roles/bigquery.jobUser"Now give access to only the shop dataset. If you know SQL, this part will feel familiar. Run it in the BigQuery editor:
GRANT `roles/bigquery.dataViewer`
ON SCHEMA `PROJECT_ID`.shop
TO "user:analyst@example.com";Notice what we did not do. We never gave the analyst Editor, and we kept the data role on one dataset instead of the full project.
Example 2: Give a Cloud Run App Its Own Service Account
Our orders-api app needs to read invoices from a bucket. It should not borrow a person’s login, and it should not share the default service account. So we give it a dedicated identity.
Step 1: Create the service account.
gcloud iam service-accounts create orders-api-sa \
--display-name="Orders API on Cloud Run"Step 2: Let it read that one bucket.
gcloud storage buckets add-iam-policy-binding gs://my-invoice-bucket \
--member="serviceAccount:orders-api-sa@PROJECT_ID.iam.gserviceaccount.com" \
--role="roles/storage.objectViewer"Step 3: Deploy the app with that identity.
gcloud run deploy orders-api \
--source . \
--region=asia-south1 \
--service-account=orders-api-sa@PROJECT_ID.iam.gserviceaccount.comYou do not need to download a JSON key for this. Because the service account is attached to the Cloud Run service, Google handles the credentials. That is one less secret to lose.
Example 3: Give a Contractor Temporary Access
A contractor needs to read your logs for a month. People forget to remove access like this, so add a Google Cloud IAM condition that ends it automatically. Change the date before you run this.
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="user:contractor@example.com" \
--role="roles/logging.viewer" \
--condition='expression=request.time < timestamp("2027-01-31T18:30:00Z"),title=contractor_logs_until_january'The time is in UTC, so this example ends at midnight on 1 February in India. After that, the contractor loses access even though the entry stays in the policy. Clean it up when you next review your project.
Example 4: Create a Custom Role
The Storage Object Viewer role can also list everything in a bucket. Suppose a partner system should fetch a file only when it already knows the name. No need to show them the full list, so we build a role with one permission.
gcloud iam roles create invoiceReader \
--project=PROJECT_ID \
--title="Invoice Reader" \
--description="Can read a file but cannot list the bucket" \
--permissions=storage.objects.get \
--stage=GAThen grant it like any other role. Note the longer role name.
gcloud storage buckets add-iam-policy-binding gs://my-invoice-bucket \
--member="serviceAccount:partner-sa@PROJECT_ID.iam.gserviceaccount.com" \
--role="projects/PROJECT_ID/roles/invoiceReader"How to Check and Remove Google Cloud IAM Access
Giving access is the easy part. Reviewing it later is what most teams skip. This command shows the project roles held by one person:
gcloud projects get-iam-policy PROJECT_ID \
--flatten="bindings[].members" \
--filter="bindings.members:analyst@example.com" \
--format="table(bindings.role)"To remove a role:
gcloud projects remove-iam-policy-binding PROJECT_ID \
--member="user:analyst@example.com" \
--role="roles/bigquery.jobUser"If the entry has a condition, like the one in Example 3, add --all to the remove command. Changes usually take about 2 minutes to apply, and can take 7 minutes or longer, so do not panic if a new role does not work straight away.
Google Cloud IAM Mistakes to Avoid
- Using Owner or Editor everywhere: These are too broad for production. Pick a predefined role.
- Granting at project level by habit: If one bucket is enough, grant the role on that bucket.
- Adding people one at a time: Give roles to a Google group instead.
- Sharing the default service account: Give each app its own account, because a default one may hold the Editor role.
- Downloading service account keys: Anyone who gets the file can use it. Avoid keys when a safer option exists, and never commit one to Git.
- Letting too many people act as a service account: They gain whatever access that account has.
Google Cloud IAM Limits Worth Knowing
| Limit | Value |
|---|---|
| Principals in one allow policy | 1,500 |
| Groups and domains in one allow policy | 250 |
| Custom roles in a project | 300 |
| Custom roles in an organization | 300 |
For the full details, see the official Google Cloud IAM documentation and Google’s IAM security best practices.
Conclusion
If you remember one thing about Google Cloud IAM, make it this: give the smallest access that still gets the job done. Choose a predefined role, keep it on the smallest resource you can, and give each app its own service account.
Open your project’s IAM page today and look for anyone holding Owner or Editor who does not need it. Then try Example 2 with your own Cloud Run service. If you are connecting several services, our Google Cloud Workflows guide shows where these roles fit in a real process.
FAQs
Q1: Is Google Cloud IAM free?
Yes. Google says all use of the IAM API is free of charge. You still pay for the other services you run.
Q2: What is the difference between a role and a permission in Google Cloud IAM?
A permission is one action. A role is a group of permissions, and it is what you actually grant.
Q3: What is a service account in Google Cloud IAM?
It is an identity for an app or workload instead of a person.
Q4: Why did I get a permission denied error after adding a role?
The change may still be applying, so wait a few minutes. Also check that you chose the right project and resource.
Q5: Should I use Owner on my own project?
For a personal test project, it is common. For production, keep Owner to the few people who truly need it.
Q6: Can I give access to one bucket only?
Yes. Grant the role on the bucket instead of the project, as shown in Example 2.