For Google Cloud Pub/Sub, give a producer the Publisher role on its one topic and give a consumer the Subscriber role on its one subscription. Avoid Editor and Admin for workloads. Grant roles on the resource, not the whole project, so a leaked service account can reach only what it needs.
The predefined roles
Google's access control documentation lists them. Pub/Sub Publisher has a single permission, to publish to a topic. Pub/Sub Subscriber consumes messages from a subscription and attaches subscriptions to a topic. Pub/Sub Viewer reads topics, subscriptions, snapshots and schemas without changing them. Pub/Sub Editor can modify topics and subscriptions and can also publish and consume. Pub/Sub Admin has full access.
The Service Agent role is a special case. The documentation says not to grant it to any principal except service agents.
Grant at the resource level
Access can be set at project level or on individual resources: topics, subscriptions, snapshots and schemas. Per-resource grants let you give publish-only on one topic without exposing the rest of the project. For cross-project publishing, the documentation advises against granting Editor on the whole project and recommends the publisher role on the specific topic instead.
A worked layout
Imagine an orders service and a billing service.
- The orders service account gets Publisher on the orders topic. It cannot read anything.
- The billing service account gets Subscriber on its own billing subscription. It cannot publish to the topic.
- An on-call group gets Viewer for diagnosis, plus a documented process for temporary elevation.
- Nobody gets Editor at project level just to make a deploy pass.
Each service uses its own service account, so audit logs name the real actor.
Common slips
- Using one shared service account for everything. A single leak then grants publish and consume everywhere.
- Granting Subscriber on the topic when only a subscription is needed. Read the lowest-level resource listed for each role.
- Forgetting that creating a subscription in one project against a topic in another needs permission in both places, as the documentation states.
Review it
Export the IAM policy for each topic and subscription during access reviews. Look for broad principals and roles that include more than the service does. A role that can publish but never needs to is a finding.
Pair this with attention to message content. IAM controls who can send. It does not validate what is sent, so consumers still need to validate input. For the equivalent on another platform, see Kafka ACLs for producers and consumers.
Safeguard can help here in a small way. Its SBOM and dependency scanning covers the broker client libraries and service frameworks your code pulls in, and reachability analysis shows which advisories your services actually call. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Which role does a publish-only service need?
Pub/Sub Publisher, granted on the specific topic.
Is Editor fine for a service that both sends and receives?
It works, but it also lets the service modify topics and subscriptions. Grant Publisher and Subscriber on the specific resources instead.
Sources
Last reviewed: 19 October 2026.
