Permissions for creating a subscription

[Walter Smith]

It seems like a common intended usage of pubsub is for a consumer to create its own subscription when it starts up. That's based on a few observations: some client libraries have an option that automatically creates subscriptions; a subscription seems to evaporate after 7 days if nobody pulls from it; deployment/configuration of a service is more complicated if a subscription has to be pre-created; and a service often wouldn't want messages starting at some arbitrary time before it started.

However, to create a subscription, we see from the docs that you need:

(a) pubsub.subscriptions.create on the containing Cloud project

(b) pubsub.topics.attachSubscription on the requested topic

The pubsub.subscriber role on the topic gives you (b), which makes sense.

But the only role listed with pubsub.subscriptions.create in it is pubsub.editor, which seems like a crazy permission to give at project level.

So…what am I missing? Intuitively it seems like pubsub.subscriber on the topic should be enough to do this. (Also, there doesn't seem to be any such operation in the API as "attaching" a subscription…isn't that the same as creating a subscription? So how are subscriptions.create and topics.attachSubscription logically different?)

— Baffled in Seattle

[Kenworth (Google Cloud Platform)]

@Walter I am currently investigating this issue, I will get back to you in a few days.

[Kenworth (Google Cloud Platform)]

In Google Cloud Pub/Sub, topics and subscriptions are resources that live in a Cloud project. As such, topics and subscriptions inherit policies from their containing project. The “pubsub.subscriptions.create” and “pubsub.topics.attachSubscription” permissions are two pieces to the same call. The former allows the creation of subscriptions, and the latter allows for attaching those subscriptions to topics.

If you have potential permission creep or escalation associated with having the project-level permission, I recommend you file a feature request [1] so that proper attention will be given to it.

[1] https://issuetracker.google.com

[Rohit Khare]

I would note that IAM Custom Roles may also be appropriate for your scenario. A custom role is as a way to grant pubsub.{topics|subscriptions}.create and that permission alone — rather than all of pubsub.editor — to certain users/service accounts on a specific project/folder/organization. 

It's in Open Alpha right now, so you can consult the documentation at https://cloud.google.com/iam/docs/understanding-custom-roles

Thanks,

  Rohit Khare

  PM, IAM Roles

  (and, coincidentally, former PM, Pub/Sub)

--
You received this message because you are subscribed to the Google Groups "Google Cloud Pub/Sub Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cloud-pubsub-discuss+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cloud-pubsub-discuss/3e5d2fcc-8e9d-41c7-a5b5-8ad38733b90f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Johannes Ziemke]

I just run into the same issue. My code creates a new subscription if there isn't one for it's hostname. What is the recommended way to setup the subscriptions? Is it recommended to do that outside of the subscriber worker?

[Alex Mordkovich]

a subscription seems to evaporate after 7 days if nobody pulls from it

Not quite. A subscription is not garbage collected until 30 days after inactivity.

But the only role listed with pubsub.subscriptions.create in it is pubsub.editor, which seems like a crazy permission to give at project level.

Creating a subscription creates a new object in the containing project, which effectively consumes resources in the containing project (given that currently there is a limit of 10,000 subscriptions per project: https://cloud.google.com/pubsub/quotas#other_limits). Hence, Editor role is required on the containing project. 

On Thu, Nov 23, 2017 at 7:31 AM, Johannes Ziemke <fi...@freigeist.org> wrote:

I just run into the same issue. My code creates a new subscription if there isn't one for it's hostname. What is the recommended way to setup the subscriptions? Is it recommended to do that outside of the subscriber worker?

Note that the subscription's parent project need not be the same as that of the topic to which the subscription is being attached. You can create a subscription in project A to a topic in project B. Then you need Editor role on project A and Subscriber role on the topic.

 

--
You received this message because you are subscribed to the Google Groups "Google Cloud Pub/Sub Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cloud-pubsub-discuss+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cloud-pubsub-discuss/4fe01864-f3f7-49c5-8461-a18f2c14c4d3%40googlegroups.com.

[Walter Smith]

On Monday, November 27, 2017 at 2:26:08 PM UTC-8, Alex Mordkovich wrote:

But the only role listed with pubsub.subscriptions.create in it is pubsub.editor, which seems like a crazy permission to give at project level.

Creating a subscription creates a new object in the containing project, which effectively consumes resources in the containing project (given that currently there is a limit of 10,000 subscriptions per project: https://cloud.google.com/pubsub/quotas#other_limits). Hence, Editor role is required on the containing project. 

That just seems like a huge violation of least privilege, since project editor can do a whole lot of destructive things in addition to creating subscriptions. This seems like a conflict in "best practice" advice. since [some of] the SDKs appear to be designed to auto-create subscriptions, but I doubt the proper advice for IAM is to give project editor privileges to all of your application service accounts!

Custom roles do solve the problem and (despite being in alpha) that's what we're going with for now.

Thanks,

Walter

[Alex Mordkovich]

On Mon, Nov 27, 2017 at 6:02 PM, Walter Smith <wal...@carezone.com> wrote:

On Monday, November 27, 2017 at 2:26:08 PM UTC-8, Alex Mordkovich wrote:

But the only role listed with pubsub.subscriptions.create in it is pubsub.editor, which seems like a crazy permission to give at project level.

Creating a subscription creates a new object in the containing project, which effectively consumes resources in the containing project (given that currently there is a limit of 10,000 subscriptions per project: https://cloud.google.com/pubsub/quotas#other_limits). Hence, Editor role is required on the containing project. 

That just seems like a huge violation of least privilege, since project editor can do a whole lot of destructive things in addition to creating subscriptions.

Note that you can use roles/pubsub.editor which has fewer permissions than the GCP-wide roles/editor: https://cloud.google.com/pubsub/docs/access_control#tbl_roles

 

This seems like a conflict in "best practice" advice. since [some of] the SDKs appear to be designed to auto-create subscriptions, but I doubt the proper advice for IAM is to give project editor privileges to all of your application service accounts!

Custom roles do solve the problem and (despite being in alpha) that's what we're going with for now.

Sounds good!

 

Thanks,

Walter

--
You received this message because you are subscribed to the Google Groups "Google Cloud Pub/Sub Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cloud-pubsub-discuss+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cloud-pubsub-discuss/2df35e65-3d1d-466b-b523-2d8c269a35c7%40googlegroups.com.