https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# google-cloud
s
This message was deleted.
b
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/
d
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
b
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
d
I need to run in pulumi the equivalent of ‘gsutil iam ch TYPEEMAIL ADDRESSROLE gs://BUCKET_NAME ‘
Bucket name is known (it is fixed) the typeemail addressrole instead is the service account for cloud run in the project that I have just created when doing pulumi up
g
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
d
can you please detail why?
I understand why IAMPolicy is a bad idea as it overwrites previous policies, but what about IAMBinding, why not?
g
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)
d
so via IAMPolicy I replace all the permissions, with IAMBinding I remove all the previous roles
g
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
8 Views
Open in Slack
PreviousNext
Powered by