Before we get to custom roles, let us talk about why we need custom roles in GCP (Also read, Service accounts and bindings in GCP). The first use case is that of restricting user access. If you have a set of users that you would like to let into your project (or folder or org), but want to limit what they can do, custom roles are the way to do it.

Conceptually, it helps to think of two types of custom roles – iam centric roles and non-IAM centric roles.

IAM centric implies that the custom role is able to perform IAM actions. Non IAM centric is everything else (e.g. a custom role that has access to compute engine and pub sub and nothing else)

Create a Custom Role in GCP using Terraform

resource “google_project_iam_custom_role” “my-custom-role” {
role_id = “my-custom-iam-role”
title = “custom iam Role”
description = “custom iam role to bind to an SA”
permissions = [“iam.roles.list”, “iam.roles.create”, “iam.roles.delete”]
}

Define a Policy containing this custom role – This spits out a policy_data object (a policy document)

#Define an IAM policy to bind SA to the custom role. This just defines the policy, actual binding is later:

data "google_iam_policy" "customrole-sa-policy" {
  binding {
    role = "roles/my-custom-iam-role"

members = [
serviceAccount:my-service-account@MY_PROJECT_ID.iam.gserviceaccount.com"
]
}
}

Attach Policy_Data – Now, when you create any resource, you can use the OUTPUT of the snipped above (which should be a policy document)

resource "google_pubsub_subscription"  "attach-policy" {
  name  = "my-example-subscription"
  topic = google_pubsub_topic.pubsub-policy.name
  ack_deadline_seconds = 20
  
  policy_data = data.google_iam_policy.admin.policy_data  
}

What about a custom role that restricts a user to a project?

Often, what we want is a way to restrict a user to a particular project. They can do what they like within that project but they are not allowed to cross the project boundary. Or go into another folder containing another project.

In order to do this, we can define a custom role as the project editor (or a Project owner). The project owner is also fine – as long as they are not granted folder admin (this would let them cross over into another project under another folder)

Summary

Projects are central to all GCP resources and services. Often, you want to RESTRICT users from access to resources within a project. Custom Roles in GCP, are an ideal way to accomplish this. In addition, a policy binding can help bind that role to a service account.

Ready to start a conversation? Set up a 1 on 1 appointment with Anuj to assist with your cloud journey.

The post Custom Roles in GCP appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

The trust boundary within a GCP Project is implicit — resources within a project automatically have access to each other. And they are denied access to resources in other projects.

Hence, a storage bucket and a compute instance, within the same project, don’t need any special access means. They can access each other without any policy wrangling.

Granular Resource Access within a Project — Setting access control at the Resource level

It’s great to have this type of implicit trust between resources. However, often , users need to be RESTRICTED from accessing resources.

The principle of least privilege says — only grant as much access as is needed.

This post shows a how this principle may be applied to compute engine instances.

Select your user from IAM — and assign the following two roles (At the very least, you would assign the ‘Service Account User Role’ to the IAM user. This lets the user use built in service accounts, which are used to access GCP services).

• Add two roles — Compute Viewer Role and Service Account User Role (Role in GCP is defined as a set of permissions).
• This, as per the principle of least privilege, allows this user to view all instances. But, as we will show below, this user will be only granted access (log on access) to a single instance.

To grant access to specific instances, choose the instance (note that what we are doing now is at the RESOURCE level; what we did before was at the IAM level)

• On the instance, “Add Members”
• Assign “Compute Instance Admin” role to the user. This will allow the user SSH access onto the instance.
• However if user tries to access any other instance, their SSH access will be disallowed. They can still SEE the instance — as they have the Compute Viewer role.
• This the basically the principle of least privilege at work. The user is allowed access ONLY to what she needs and not to anything more.
• The same example above can be applied to restrict / control access to Disks, Storage Buckets, Images, Snapshots etc.

What about cross project access?

If you think AWS accounts, how does a resource in Account A, access a resource in Account B? The answer is cross account roles.

In a similar vein, a role is needed in GCP as well to provide cross project access. A service account in project A is granted access (access being a compute viewer) to a compute resource in project B.

gcloud projects add-iam-policy-binding $GCP_PROJECT_ID_B \
--member=serviceAccount:${GCP_PROJECT_ID_A}@appspot.gserviceaccount.com \
--role=roles/compute.viewer \

Summary

A GCP project is like an AWS account, in that it is the holder of resources as well as designed with a built in IAM. While IAM is defined at the ORG level in GCP, it is still useful to think of it at the Project Level.

 Access from resource A to resource B within a project is implicit. However, if a user were to be restricted access to resources within a project, you would typically do a TWO STEP configuration

1. The first is the GRANT at the IAM level (user is granted viewer access for example) — and then you would,
2. GRANT / DENY at the resource level (this resource is ALLOWED to be accessed by this user, all other resources are IMPLICITLY denied).

Granular access is at the heart of the principle of least privilege, and this post shows how to use the Google Cloud Project Boundary to accomplish granular access. Along with GCP Projects, once you grasp service accounts, you can get rolling on GCP development.

The post The GCP Project Boundary, Trust Boundary and the Principle of Least Privilege appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.