Cloud IAM Roles

Cloud Identity & Access Management lets you grant granular access to specific Google Cloud resources and helps prevent access to other resources. Cloud IAM lets you adopt the security principle of least privilege, where you grant only necessary permissions to access specific resources.

Primitive Roles

Primitive Roles are broad and impact all resources in the project. They are roles which existed prior to existence of Cloud IAM.

These roles are concentric, owner includes the permissions of editor and editor includes the permission of viewer.

  1. Viewer – Permissions for read-only actions that do not affect state, such as viewing (but not modifying) existing resources or data.
  2. Editor – All viewer permissions, plus permissions for actions that modify state, such as changing existing resources.
  3. Owner – All editor permissions, plus Manage roles and permissions for a project and all resources within the project. Set up billing for a project.

4. Billing Administrator Role

someone to be able to control the billing for a project without the right to change the resources in the project. 

Predefined Roles

In addition to the primitive roles, Cloud IAM provides additional predefined roles that give granular access to specific Google Cloud Platform resources and prevent unwanted access to other resources.

There is a long list of these roles listed here.

Custom Roles

Custom roles can only be used at the project or organization levels. They can’t be used at the folder level. 

To create a custom role, a caller must possess iam.roles.create permission. By default, the owner of a project or an organization has this permission and can create and manage custom roles.

Users who are not owners, including organization admins, must be assigned either the Organization Role Administrator role, or the IAM Role Administrator role.

Tagged : / / / /

Policies & Cloud IAM

Organization policies are needed to enforce what resources are available in a Google Cloud trust boundary (folder, project, or other organizational level).

Cloud Identity and Access Management (IAM) enables you to manage access control by defining who (identity) has what access (role) to which resource.


Policies

Top to bottom : Resources inherit the policies of their parent resource. 

Google Cloud Platform Policies are set at the highest level, like the organisation node are cascaded down to the project.

Inheritance is transitive, all the resources in a project inherit the policy.

However policies implemented at a higher level in this hierarchy can’t affect the access that’s granted exceptionally at a lower level. 

For example,

Policy A – Enforced at the Organisation Level – Users can view cloud storage buckets.

Policy B – Enabled at the Project Level – User can modify cloud storage buckets.

Since Project Level Policy B is granting a more generous access at a lower level, it shall take effect and override Policy A.


Cloud IAM

An IAM policy has the following :

  1. “who” part, 
  2. a “can do what” part, and
  3. an “on which resource” part. 

Who

The “who” part of an IAM policy can be defined either by a

a. Google account

b. Google group

c. Service account

d. G Suite

e. Cloud Identity domain. 

Can Do What – Role

The “can do what” part is defined by an IAM role which is a collection of permissions.

To do any meaningful operations, you need more than one permission.For example, to manage instances in a project, you need to create, delete, start, stop, and change an instance. 

So the permissions are grouped together into a role that makes them easier to manage. 

There are three kinds of roles in Cloud IAM:

  1. Primitive roles: Roles historically available in the Google Cloud Console. These roles are Owner, Editor, and Viewer. Avoid using these roles if possible, because they include a wide range of permissions across all Google Cloud services.
  2. Predefined roles: Roles that give finer-grained access control than the primitive roles. For example, the predefined role Pub/Sub Publisher (roles/pubsub.publisher) provides access to only publish messages to a Pub/Sub topic.
  3. Custom roles: Roles that you create to tailor permissions to the needs of your organization when predefined roles don’t meet your needs.

Reference : Concepts Related to Access Management

Tagged : / / / / /