No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

when you say existing bucket, do you mean one that was created manually/without pulumi? if so, you'll need to import it, the. modify it:
<https://www.pulumi.com/docs/guides/adopting/import/>

No it is the google container registry bucket for another project 

I am using a pattern called google project factory 

My cloud build runs in a project and pushes the image there, my pulumi stack creates a new project. This works except that the cloud run agent in the new project cannot pull the images from the root project 

i actually have some trouble with this myself, Google's IAM/service account stuff is hard to understand. Try this: <https://www.pulumi.com/docs/reference/pkg/nodejs/pulumi/gcp/serviceaccount/#IAMBinding>

I need to run in pulumi the equivalent of ‘gsutil iam ch TYPE:EMAIL-ADDRESS:ROLE <gs://BUCKET_NAME|gs://BUCKET_NAME> ‘

Bucket name is known (it is fixed) the type:email-address:role instead is the service account for cloud run in the project that I have just created when doing pulumi up

Very rarely would I recommend using `IAMBinding` or `IAMPolicy` directly.
For the safety and sanity of everyone that will use that project (including the future you), unless you have a very strong reason to affect the access of _every_ account to a resource, use `IAMMember`

I understand why IAMPolicy is a bad idea as it overwrites previous policies, but what about IAMBinding, why not?

`IAMPolicy` replaces all permissions related to a resource. `IAMBinding` is the same thing, just limited to a single role.
For example:
• You want a backup service to upload the final backups to the default bucket of the project `...<http://appspot.com|appspot.com>` 
• For that the least privileged role is `Storage Object Creator` 
• You define your permissions with an `IAMBinding` to the service account that the backup service will use
Seems fine? Well... now you cannot deploy any Cloud Functions anymore, because they require their internal `service-[projectNumber]@gcf-admin-robot.iam.gserviceaccount.com` to have the `Service Object Creator` role to the default bucket, and the binding removed it.

And Google _can_ change the internal service accounts used for the services to access one another at any time. A bit after Cloud Build went GA they changed the service account it uses, previously it used the default Compute Engine account. Since the change it has its own account

You would need to follow _every_ post they make on their blog to update your possibly affected policies/bindings

And such changes are very hard to troubleshoot because you did not change anything. You would get an error saying that an 403 on cloud storage, you would then check your permissions, the function permissions, pulumi permissions, ....
Until eventually you find that it was an indirect access (personal experience)

so via IAMPolicy I replace all the permissions, with IAMBinding I remove all the previous roles

No, IAMPolicy replaces all permissions of a resource. IAMBinding replaces all permission with a specific role on a resource.

IAMBinding affects only one role, making it _safer_, but not _safe_