Assigned
Status Update
Comments
ke...@google.com <ke...@google.com> #2
Update on issue:
OrgPolicy is being considered here as a potential solution to the problem. This would control access to features at a higher level than the project (Org or Folder). Details of service outlined in [1].
[1]https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints
OrgPolicy is being considered here as a potential solution to the problem. This would control access to features at a higher level than the project (Org or Folder). Details of service outlined in [1].
[1]
ml...@nocturnal.org <ml...@nocturnal.org> #3
Shame that individual APIs enabled on a project can't have their access managed much like you would do with any other resource (storage buckets, vm instances, etc). Seems the most consistent solution. Having discovered this flaw I'm now curious what other resources like this can be exploited by any service account in the project.
pe...@gmail.com <pe...@gmail.com> #4
Please support the roles for Vision APIs -- I cannot grant owner role for the whole project to people who need to upload samples for vision API
mi...@legalontech.jp <mi...@legalontech.jp> #5
This one of the areas where Google Cloud is lagging behind Azure...
Description
Currently, all service accounts under a project have permission to call Cloud Vision API, even without any IAM role assigned.
Given the customers area of work, without permissions/IAM roles assigned to service accounts, it may create regulatory issues.
I have suggested to the customer to create a separate project for Vision API alone in the meantime.