IAM
Last updated
Was this helpful?
Last updated
Was this helpful?
A folder can contain projects, other folders, or a combination of both. For example, your organization might contain multiple departments, each with its own set of GCP resources. Folders allows you to group these resources on a per-department basis
Resources inherit the policies of their parent resource. For instance, if you set a policy at the organization level, it is automatically inherited by all its children projects.
The policies implemented at a higher level in this hierarchy can’t take away access that’s granted at lower level. For example, suppose that a policy applied on the “bookshelf” project gives user Pat the right to modify a Cloud Storage bucket. But a policy at the organization level says that Pat can only view Cloud Storage buckets, not change them.
Less restrictive parent policy will always override the more restrictive resource policy.
The IAM policy hierarchy always follows the same path as the Google Cloud resource hierarchy, which means that if you change the resource hierarchy, the policy hierarchy also changes.
child policies cannot restrict access granted at the parent level. For example, if we grant you the editor role for department X and we grant you the viewer role at the bookshelf project level, you still have the editor role for that project.
An IAM policy is a list of policy bindings. A policy binding binds a member or an identity to a role.
One member can have multiple policy bindings in an IAM policy. you can grant more than one role to a member.
An IAM policy is always attached to a resource to make it effective.
IAM lets administrators authorize who can take action on specific resources. An IAM policy has a “who” part, a “can do what” part, and an “on which resource” part.
The “who” part of an IAM policy can be a Google account, a Google group, a service account, or an entire G Suite or Cloud Identity domain.
The “can do what” part is defined by an IAM role. An IAM role is a collection of permissions.
There are 3 types of IAM Roles - Primitive, Predefined, Custom
Primitive roles are broad. They affect all resources in that project.
GCP services offers their own sets of predefined roles, and they define where those roles can be applied.
The predefined role offers more fine-grained permissions on particular services
the role allows you to define a precise set of permissions
E.g: give permissions to a Compute Engine virtual machine rather than to a person
You can assign a predefined or custom IAM role to the service account.
use Google Groups to gather together people who are in the same role. This approach is easy to get started with, if someone leaves your organization, there is no centralized way to remove their access to your cloud resources immediately.
GCP customers who are also Google Cloud workspace customers can define GCP policies in terms of G Suite users and groups.
Cloud Identity lets you manage users and groups using the Google Admin Console, but you do not pay for or receive workspace’s collaboration products such as Gmail, Docs, Drive, and Calendar.
Google Workspace or Cloud Identity account represents a company and is a prerequisite to having access to the Organization resource. It provides identity management, recovery mechanism, ownership, and lifecycle management
The Google Cloud workspace or Cloud Identity super administrators and the GCP organization admin are key roles during the setup process and for lifecycle control, for the organization resource.
Google Cloud Directory Sync synchronizes users and groups from your existing Active Directory or LDAP system with the users and groups in your Cloud Identity domain. The synchronization is one-way only; no information in your Active Directory or LDAP map is modified.
use the principle of least privilege when granting roles
granting roles to groups instead of individuals to allows you to update group membership instead of changing a Cloud IAM policy
