Seems GCP Document AI the permission can only be granted to project level, can we grant to lower level ,like specific processor ?
Related
I am looking to Restrict creation of VMs on GCP projects. Any workaround for this request.
You might want to try IAM Roles if you do a proper role segmentation within the users of your organization you can restrict all users/groups from creating VMw on your GCP project. Here is another link regarding IAM
The compute IAM role are too broad. If you want finer control, you need to create a custom role without this permission compute.instances.create
You can assign in IAM just permission to create instance. Here are some documentation what roles you can use.
With IAM, every API method in Compute Engine API requires that the identity making the API request has the appropriate permissions to use the resource. Permissions are granted by setting policies that grant roles to a member (user, group, or service account) of your project.
The following tables describe the predefined Compute Engine IAM roles, as well as the permissions contained within each role. Each role contains a set of permissions that is suitable for a specific task. For example, the Instance Admin roles grant permissions to manage instances, the network-related roles include permissions to manage network-related resources, and the security role includes permissions to manage security-related resources, like firewalls and SSL certificates.
Compute Admin role
Name Description Permissions
roles/compute.admin
Full control of all Compute Engine resources.
If the user will be managing virtual machine instances that are configured to run as a service account, you must also grant the roles/iam.serviceAccountUser role.
compute.*
resourcemanager.projects.get
resourcemanager.projects.list
serviceusage.quotas.get
serviceusage.services.get
serviceusage.services.list
click here for more documentation.
Set Quotas in GCP , Quota for VMs are based on the region.
https://cloud.google.com/compute/quotas#understanding_quotas
"The VM instances quota is a regional quota and limits the number of VM instances that can exist in a given region, regardless of whether the VM is running. This quota is visible in the Google Cloud console on the Quotas page. "
In my GCP organization, We have several users who have access at the organization level for IAM for all the projects within it.
I have a scenario, where in I need to restrict the access of some users to one particular project's specific services.
I'm aware of the VPC service control perimeters but since the service that I want to restrict is GCP FireStore service and it is not supported by VPC SC, What other thing can be done here to restrict the access?
Please suggest me some alternate way for doing this if there is any.
Permissions are inherited. If you grant an identity a role at the ORG/Folder level, those permissions are inherited at the project level.
Google is rapidly developing Organization Policy Constraints which might invalidate this answer in the near future.
At this time, your best solution is to remove rights at the ORG/Folder level and grant rights at the project level if you need project-level IAM control.
i am picking up terraform for GCP and i came across these three resources:
google_service_account_iam_member
google_project_iam_member
google_organization_iam_member
They sound very similar to each other but certainly with some key differences.
I went through their docs but their differences were not absolutely clear to me. Is there any easy way to illustrate the difference between these?
Thanks
Within GCP, there is a hierarchy: Organization, Project, Resource
The IAM policies you mentioned behaves the same; however, works on different levels based on the hierarchy.
For example, the google_project_iam_member will update the IAM policy to grant a role to a new member on the project level.
The google_organization_iam_member will do the same thing, but on the Organization level (which is a level higher than the project).
Update:
The google_service_account_iam_member will work on every level depending on what you would like the service account to do. You can either have the service account act as an identity or just have it run a certain resouce. A service account can be added on all three levels.
As described before the google_project_iam_member and google_organization_iam_member, are used to manager IAM permission in the project or organization level. You can also manage permission on the folder level.
When, IAM is granted on the org level all folders and projects inherit that permission. When granted in the folder, alll projects and sub folders under that folder will inherit that permission.
Permissions can also be managed at resource level, the google_service_account_iam_member allow to grant permission to manage the service account and use the service account in the service account level. That helpful when you want to grant more restricted permissions and grant access to a single service account instead of all service accounts from the project.
Thanks,
Eduardo Ruela
I am working on google cloud platform and i have faced the issue below.
(I would also like inputs from aws and azure platforms as well.)
Created a new user in gsuite admin console with no roles assigned in gsuite admin.
Added that user in gcp IAM console and gave 2 roles : compute security admin and compute network admin at organization level, meaning these permissions are inherited from organization level.
Should my user be able to create projects having only compute secuirty admin and compute network admin roles ?
No. With only those two roles assigned, your user would not be able to create Projects in GCP. You would need to assign a role with the resourcemanager.projects.create Permission. The correct role to assign according to the Principle of Least Privilege would be roles/resourcemanager.projectCreator, also known as the "Project Creator" role.
meaning these permissions are inherited from organization level.
That's not quite what this means. In GCP, resources that are below the Organization (e.g. Folders, Projects) will inherit Permissions defined at the Org level, and lower-level resources cannot further restrict permissions already granted at higher levels.
See also:
List of predefined Roles in GCP
Creating and Managing Projects
Using Resource Hierarchy for Access Control
According to the documentation which says
Child policies cannot restrict access granted at a higher
level. For example, if you grant the Editor role to a user for a
project, and grant the Viewer role to the same user for a child
resource, then the user still has the Editor role grant for the child
resource.
Does it also mean that if I assign a user restrictive access at higher level but assign more permissive access at resource level, that user will have more permissive access? In other words, more permissive policy will override restrictive policy no matter what at which level more permissive policy is granted at?
Example:
Grant UserA viewer role for a project but assign Editor role at resource level, UserA will have editor level access to the resource?
Does it also mean that if I assign a user restrictive access at higher
level but assign more permissive access at resource level, that user
will have more permissive access?
Yes.
In other words, more permissive policy will override restrictive
policy no matter what at which level more permissive policy is granted
at?
Do not think of it has overriding. Think of it as you are granting additional privileges.
Grant UserA viewer role for a project but assign Editor role at
resource level, UserA will have editor level access to the resource?
Correct, UserA will have editor level for the resource.
Think of the hierarchy being Organization / Folders / Projects / Resources. If you have permissions at a higher level, you have at least those permissions at a lower level. This is similar to a company's organization. If you are V.P. of division (project) you are still V.P. for each group (resource) under that division. The opposite also works. You are a team member for the organization (project Viewer) but you are the manager for one group (compute resources Editor) and just a project Viewer for other resources.
Just to add to above answer,
If during union of the policy, situation of policy conflict occurs then DENY takes precedence.
For example there are below two policies
On folder level ->
Allow storage bucket creation for user x#a.com
On Project1 Level ->
Deny storage bucket creation for user x#a.com
then DENY policy takes precedence and user x#a.com won't be able to create the bucket.
https://cloud.google.com/resource-manager/docs/organization-policy/understanding-hierarchy#reconciling_policy_conflicts
GCP IAM first checks the denied policies attached to the principal and then, goes on to evaluate the allowed policies.
The attached GCP policy evaluation flowchart will help you clear the concept.
https://cloud.google.com/iam/docs/deny-overview#policy-eval