GCP - IAM roles

 When an organization node contains lots of folders, projects, and resources, it’s likely that a workforce might need to restrict who has access to what.

To help with this task, administrators can use Identity and Access Management, or IAM. With IAM, administrators can apply policies that define who can do what on which resources :

● The “who” part of an IAM policy can be a Google account, a Google group, a service account, or Cloud Identity domain. A “who” is also called a “principal.” Each principal has its own identifier, usually an email address. 

● The “can do what” part of an IAM policy is defined by a role. An IAM role is a collection of permissions. When you grant a role to a principal, you grant all the permissions that the role contains. For example, to manage virtual machine instances in a project, you have to be able to create, delete, start, stop and change virtual machines. So these permissions are grouped together into a role to make them easier to understand and easier to manage. 

When a principal (user, group, or service account) is given a role on a specific element of the resource hierarchy, the resulting policy applies to the chosen element, as well as to all of the elements below it in the hierarchy.

You can define deny rules that prevent certain principals from using certain permissions, regardless of the roles they're granted. This is because IAM always checks relevant deny policies before checking relevant allow policies. 

Deny policies, like allow policies, are inherited through the resource hierarchy.

The first role type is basic. Basic roles are quite broad in scope. When applied to a Google Cloud project, they affect all resources in that project. Basic roles include owner, editor, viewer, and billing administrator.

Let’s have a look at these basic roles: 

● Project viewers can examine resources, but can make no changes. 

● Project editors can examine and make changes to a resource. 

● And project owners can also examine and make changes to a resource. In addition, project owners can manage the associate roles and permissions, as well as set up billing. 

● Often companies want someone to be able to control the billing for a project, but not have permissions to change the resources in the project. This is possible through a billing administrator role. 

A word of caution: If several people are working together on a project that contains sensitive data, basic roles are probably too broad. Fortunately, IAM provides other ways to assign permissions that are more specifically tailored to meet the needs of typical job roles.

But what if you need to assign a role that has even more specific permissions? That’s when you’d use a custom role.

A lot of companies use a “least-privilege” model, in which each person in your organization is given the minimal amount of privilege needed to do their job. So, for example, maybe you want to define an “instanceOperator” role to allow some users to stop and start Compute Engine virtual machines, but not reconfigure them. Custom roles allow for that.

Service accounts are identified with email addresses. Service accounts are also managed by IAM.