IAM, Cloud Storage and Analytics Hub Controls

Identity and Access Management (IAM) (opens in a new tab) is the Google Cloud system that controls who can act on which resources. A principal such as a user, Google group, or service account receives a role on a resource, and that role contains the permissions needed to call the resource. Least privilege means granting each principal only the narrowest role on the narrowest resource that still allows the work.

1.1How IAM Permissions Grant Single Actions

An IAM permission is the smallest unit of access and allows one specific action on one type of Google Cloud resource. Permissions use the format SERVICE.RESOURCE.VERB, such as compute.instances.list, bigtable.instances.list, or pubsub.topics.publish. Permissions usually match API methods one-to-one, so calling a method requires its matching permission.

Permissions are never assigned directly to a principal in BigQuery. When a principal calls an API, IAM checks whether any role granted to that principal contains the required permission for that resource. A single data operation can require several permissions, such as bigtable.tables.get plus bigtable.tables.readRows to find and read a table, which is why roles bundle related permissions together.

1.2How IAM Roles Package Permissions for Principals

An IAM role is a named collection of permissions that is granted to a principal on a particular resource. When a principal receives a role, the principal receives every permission inside that role. When a principal receives multiple roles, the effective access is the union of all permissions, so access only grows as more roles are added.

A role granted on a parent resource also applies to descendants through policy inheritance in the resource hierarchy. A role granted on a project therefore applies to all BigQuery resources in that project, while a role granted on a dataset or on a single table applies only to that dataset or table and its children. Grantable BigQuery resources include datasets and the tables, views, and routines inside them, plus connections, saved queries, data canvases, data preparations, pipelines, and repositories.

1.3How Basic, Predefined, and Custom Roles Differ

Basic, predefined, and custom roles differ in how broad their permissions are and who defines them. Basic roles give broad access across many services, predefined roles give granular access for one service and are managed by Google Cloud, and custom roles give exact customer-chosen access.

The legacy basic roles, formerly called primitive roles, build on each other. Viewer (roles/viewer) allows read-only viewing across all services without changing state. Editor (roles/editor) includes all Viewer access plus creating, changing, and deleting resources for most services. Owner (roles/owner) includes all Editor access plus administration such as managing roles, setting up billing, and managing tag bindings.

Basic roles include thousands of permissions and have limits for data work. Conditions cannot be added to bindings for legacy basic roles, and Owner does not contain every permission, such as modifying payment information or creating IAM deny policies. Predefined roles are scoped to one service, so work spanning services needs a role for each service, such as a BigQuery role plus a Cloud Storage role. Predefined roles can gain permissions when Google Cloud adds capabilities, while custom roles stay fixed unless the owner changes them.

1.4How Resource Level Controls Least Privilege in BigQuery

Resource level in BigQuery controls whether access is broad or limited to one dataset or table. Administrators choose the narrowest resource level that still lets the principal do its work, which reduces exposure to sibling resources the principal does not need.

To verify exactly which permissions a role contains before granting it, use the BigQuery IAM roles and permissions reference, the IAM roles and permissions index, the gcloud iam roles describe command, or the roles.get() method in the IAM API.

Cloud Storage (opens in a new tab) buckets are private by default and become shared only through explicit access grants. Access is controlled by IAM policies, by uniform bucket-level access (opens in a new tab) settings, and by legacy Access Control Lists (ACLs). The choice between private, public, and uniform controls determines the trust boundary around buckets and objects.

2.1Private Access With IAM Inheritance

Private access with IAM means only named principals can act on buckets, managed folders, and objects. Principals include individual users, service accounts, Google groups, and Google Workspace or Cloud Identity domains. Each IAM role bundles permissions such as storage.objects.get or storage.objects.create, and the set of roles on a resource is called an IAM policy.

An IAM policy applies to the resource where it is set and flows downward to everything contained within it. A policy set on a project applies to all buckets, managed folders, and objects in that project, while a policy set on a bucket applies only to that bucket and its contents. Permissions from different levels add together, so a user can have read access from the project level and create access only on one bucket.

Private control can be refined with managed folders. A managed folder is not a true directory tree but a resource overlay used only for permission checking, and it can grant additional access beyond the bucket policy. An IAM allow policy cannot be set directly on an individual object, and an IAM deny policy cannot be set on a bucket, managed folder, or object. A deny policy attached higher in the hierarchy still overrides any allow, so a denied principal cannot use that permission on that resource or any sub-resource.

2.2Public Access With allUsers and allAuthenticatedUsers

Public access in Cloud Storage defines how data can be read by entities outside the organization. Buckets and objects stay private until access is granted to a special public principal through IAM or legacy ACLs. Granting a read role such as Storage Object Viewer to the public makes traffic flow from internet clients directly to the bucket or object.

The two public scopes work differently. allUsers represents any entity on the internet and requires no authentication, so it fits only truly public content such as website assets. allAuthenticatedUsers represents most authenticated Google accounts, including service accounts, and still requires the requester to sign in before Cloud Storage serves the data. In the console both scopes appear with the label Public, which makes them easy to confuse.

A bucket-level public IAM policy applies to the whole bucket, so one change exposes every current and future object inside it. Best practice is to block public access unless open distribution is required, keep sensitive data private with least-privilege roles, and grant access to Google groups instead of many individual users.

2.3Uniform Bucket-Level Access and ACLs

Uniform bucket-level access is a bucket setting that makes IAM the only access control system for that bucket and all objects within it. When uniform access is enabled on a bucket, only bucket-level and higher IAM roles grant access, and bucket ACLs and object ACLs are disabled. New objects automatically follow the bucket IAM policy instead of receiving a separate default object ACL.

Without uniform access, the bucket uses fine-grained control where IAM and ACLs work in tandem. An ACL entry pairs a scope, such as a user, group, domain, allUsers, or allAuthenticatedUsers, with OWNER, READER, or WRITER permission. Permissions are concentric, so WRITER includes READER and OWNER includes both. Because Cloud Storage grants access when either system allows it, both project IAM, bucket IAM, and object ACLs must be checked to know full access.

One exception is Storage Legacy Bucket roles, which stay synchronized with bucket ACLs. Changing one updates the other in both directions, while all other IAM roles leave ACLs unchanged.

Uniform access is managed by principals with the Storage Admin (roles/storage.admin) role, which contains storage.buckets.get, storage.buckets.list, and storage.buckets.update. Before enabling it, check the storage.googleapis.com/authz/acl_operations_count metric for the GCS Bucket resource in Cloud Monitoring. If the metric shows ACL operations, those workflows must move to IAM or signed URLs first, or they will stop working.

Analytics Hub (opens in a new tab) is the BigQuery capability for sharing data and insights at scale across organizational boundaries. Sharing operates under a security and privacy framework with unified metadata and governance and security policies. Providers manage sharing through the Analytics Hub API, and subscribers discover and query shared data through the BigQuery experience without moving it to a separate system.

3.1Data Exchanges and Listings in Analytics Hub

A data exchange in Analytics Hub is the provider-side sharing resource that defines the boundary where data is offered across projects and organizations. A listing is the sharing resource inside an exchange that describes one specific shared asset and controls how it is presented, discovered, and requested. Data flows from the provider source dataset through the listing to each subscriber project, while the provider project keeps ownership and control of the source.

Published data stays queryable through BigQuery alongside internal data. Subscribers discover the listing in the exchange and then work with the shared asset in BigQuery, where discovery, querying, and governance follow BigQuery rules.

3.2Zero-Copy Sharing and Secure Collaboration

Zero-copy sharing in Analytics Hub lets subscribers query shared data directly where it lives without creating a separate copy. Because no data is duplicated, updates appear immediately for subscribers and the provider can revoke access in one place. The provider listing keeps the provider project and storage separate from subscriber queries and costs.

Secure collaboration depends on BigQuery unified governance across organizational boundaries. Access stays controlled while discovery and use remain at scale, so collaboration happens without losing governance. Support for lakehouse data depends on which catalog manages the table, as shown below.

3.3Sensitivity, Audience, and Readiness Checks Before Sharing

Sharing through Analytics Hub is appropriate only after sensitivity, regulatory, audience, and platform checks all support it. Evaluate every candidate dataset against these policy factors:

• Data sensitivity: what identifiers or confidential attributes the data contains and whether it has been de-identified
• Regulatory requirements: what privacy, residency, and retention rules apply to the data
• Target audience: who needs the data, whether internal teams, trusted partners, or public users
• Business value: what decision, product, or collaboration the sharing enables compared to its risk

Highly sensitive data such as personally identifiable information (PII), financial records, or health data should not be shared in raw form. Sensitive Data Protection provides de-identification that masks, encrypts, and replaces sensitive fields where applicable and compliant. Data flows from the source system to protection processing and then to the sharing layer, so classification must happen first. When the audience needs only aggregated results, share a curated view instead of the full table.

Audience fit also matters for analytical need. Sharing fits when consumers will explore, join, or analyze live data in BigQuery with GoogleSQL, dashboards with BigQuery BI Engine, machine learning with BigQuery ML, geospatial functions, graph analysis, or search over unstructured text and JSON. Location is a hard boundary: data stored in the US multi-region must stay in us (multiple regions in United States) and data stored in the EU multi-region must stay in eu (multiple regions in European Union). The publishing identity must also hold the correct roles, and organizational policy defines who may approve sharing.

Key Facts

• An IAM permission allows one specific action using the format SERVICE.RESOURCE.VERB, an IAM role bundles permissions for a principal, and multiple roles combine as the union of all permissions with inheritance from parent to child resources.
• Basic Viewer, Editor, and Owner roles grant broad cross-service access, while predefined roles grant granular single-service access and custom roles grant an exact customer-chosen permission list.
• Cloud Storage buckets are private by default, public access is granted to allUsers without authentication or to allAuthenticatedUsers with sign-in, and uniform bucket-level access makes IAM the only control by disabling ACLs.
• An IAM deny policy set higher in the hierarchy overrides any IAM allow policy and any ACL grant on buckets and objects.
• Analytics Hub shares BigQuery data with zero-copy listings inside data exchanges, so subscribers query the provider source directly while the provider retains ownership and revocation control.