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 : / / / / /

Google Hierarchy Objects : Projects, Folders, Organisation Node

Projects, Folders, Organisation Node are the binding blocks of the Google Cloud Hierarchy.

Policies

Policies are inherited downwards in the hierarchy. All Google Cloud platform resources belong to a project.

Projects

Projects are the basis for enabling and using GCP services like managing APIs, enabling billing and adding and removing collaborators and enabling other Google services. 

Each project is a separate compartment and each resource belongs to exactly one. 

Projects can have different owners and users – they’re built separately and they’re managed separately. 

Project ID / Name / Number

Project has three identifying attributes

Each GCP project has a name and a project ID that you assign. 

Project ID : Globally unique : Chosen by you : Immutable

The project ID is a permanent, unchangeable identifier and it has to be unique across GCP. You use project IDs in several contexts to tell GCP which project you want to work with.  In general, project IDs are made to be human readable strings and you’ll use them frequently to refer to projects.

It is a a unique identifier for your project, composed of the project name and a randomly assigned number.

Project Name : Need not be unique : Chosen by you : Mutable

On the other hand, project names are for your convenience and you can assign them. 

Project Number : Globally Unique : Assigned by GCP : Immutable

GCP also assigns each of your projects a unique project number and you’ll see a display to you in various contexts.  It is a number that’s automatically generated by the server and assigned to your project.

Folders

You can organize projects into folders, although you don’t have to. 
For example, you can use folders to represent different departments,
teams, applications or environments in your organization. 

Folders let teams have the ability to delegate administrative rights, 
so they can work independently. 

The resources in a folder inherit IAM policies from the folder. 
So, if project three and four are administered by the same team by design, 
you can put IAM policies into folder B instead. 

Doing it the other way, putting duplicate copies of those policies on 
project three and project four would be tedious and error prone. 

To use folders, you need an organization node at the top of the hierarchy. 

Organisation Node

You probably want to organize all the projects in your company into a single structure. 
Most companies want the ability to have centralized visibility on how resources are being used and to apply policy centrally. That’s what the organization node is for. It’s the top of the hierarchy. 

In part the answer depends on whether your company is also a G Suite customer. 

If you have a G Suite domain, GCP projects will automatically belong to your organization node. Otherwise, you can use Google Cloud Identity to create one.

When you get a new organization node, it lets anyone in the domain create 
projects and billing accounts just as they could before. That’s to avoid surprises and disruption. 

But it’d be a great first step with a new organization node to decide who on your team should really be able to do those things. 

Once you have an organization node, you can create folders underneath it and put it in projects. 

Tagged : / / /

Google Cloud Platform Hierarchy

The Google Cloud Platform Hierarchy is a internal platform resource hierarchy is something you should go out bottom up.

Details

Whatever the resources utilized they are VM’s, cloud storage buckets, tables and big query, they are all organised into projects.

  • Projects rollup into folders.
  • Folders can also multiple other folders.

Together everything can rollup into an organisation node.

GCP Resources -> Projects -> Folders -> Organisation Node

Graphical Representation

Policies can be enforced at any level of this tree.

Tagged : / /