Professional Cloud Security EngineerConfiguring access within a cloud solution environmentHard
A security engineer needs to create a new service account that will be used by a custom application to publish messages to a specific Pub/Sub topic and subscribe to another specific Pub/Sub topic within the same Google Cloud project. The service account should have no other permissions. Which set of roles should be granted to this service account, and at what resource level?
- AGrant `roles/iam.serviceAccountUser` and `roles/pubsub.viewer` at the project level.
- BGrant `roles/pubsub.editor` at the project level.
- CGrant `roles/editor` at the project level.
- DGrant `roles/pubsub.publisher` on the target publish topic and `roles/pubsub.subscriber` on the target subscribe topic.
Show answer & explanationAnswer & explanation
Correct answer: D. Grant `roles/pubsub.publisher` on the target publish topic and `roles/pubsub.subscriber` on the target subscribe topic.
To adhere to the principle of least privilege, the service account should only receive the specific roles required (`roles/pubsub.publisher` and `roles/pubsub.subscriber`) and these roles should be bound at the most granular level possible, which is the individual Pub/Sub topic resources themselves, not the entire project.
Why the other options are wrong
- A. `roles/iam.serviceAccountUser` is for impersonating service accounts, and `roles/pubsub.viewer` only allows viewing, not publishing or subscribing. This does not meet the functional requirement and is still too broad at the project level for specific topic access.
- B. `roles/pubsub.editor` grants broad permissions across all Pub/Sub resources in the project, violating least privilege. The requirement is for specific publish/subscribe on specific topics.
- C. `roles/editor` is a very broad role that grants extensive permissions across almost all services in a project, a major security risk and a violation of least privilege.
Pub/Sub Granular IAM
Google Cloud Pub/Sub allows fine-grained IAM roles to be granted at the topic or subscription level, ensuring that service accounts or users only have the exact permissions needed.
- Roles can be granted on individual topics/subscriptions.
- Specific roles: `publisher`, `subscriber`, `viewer`, `editor`.
- Essential for least privilege in messaging architectures.
Memory trick: Give topics their own specific roles.