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.

2 main differences beetween aws and gcp role / policy

1. A GCP role gives a SINGLE permission to an IAM user. The permission is on a GCP resource.
2. A GCP Policy gives MULTIPLE permissions (to one or more users), by BINDING each user to more than one role. This allows:

• a) A single user to get access to multiple resources
• b)  Fine grained access to resources
• c) Conditional access to resources

In this example, the GCP resource is ‘ResourceManager’.  Alex is being assigned org admin and Becky can create projects.

{
  "bindings": [
    {
      "members": [
        "user:alex@example.com"
      ],
      "role": "roles/resourcemanager.organizationAdmin"
    },
    {
      "members": [
        "user:alex@example.com",
        "user:becky@example.com"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

In this example, an entire group is granted app engine deployment permissions – for a conditional period of time.

{
  "bindings": [
    {
      "members": [
        "group:prod-dev@example.com",
        "serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
      ],
      "role": "roles/appengine.Deployer",
      "condition": {
          "title": "Expires_July_1_2020",
          "description": "Expires on July 1, 2020",
          "expression":
            "request.time < timestamp('2020-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

Roles in GCP  ( versus roles in AWS)

A role is just a set of permissions that can be assigned to a user (or a service account or any IAM identity). The permission is on a GCP resource (which can be a Project, a ResourceManager, an Org, and of course, regular compute, storage resources..)

Why would you need to assign a role at the Project level?

As an example, if you were to grant access to all Cloud Storage buckets in a project, you could grant access to the project resource (instead of each individual bucket resource).

To grant access to all Compute Engine instances in a project, grant access to the project rather than each individual instance.

Service Accounts in GCP and AWS – One important difference between GCP and AWS is that service accounts are a special type of IAM user in Google cloud (think programmatic user). In AWS, the same functionality of a service account is fulfilled by a ROLE (that is typically assumed by an EC2 or a lambda function).

Roles do mean the same thing in AWS and GCP – they are just a set of permissions, that get assigned to IAM users.

Primitive Roles vs. Predefined Roles

A role is a named list of permissions; each role can be an IAM predefined role or a user-created custom role.

There are three roles (these existed prior to the introduction of Cloud IAM) – Owner, Editor, and Viewer

To get more granular permissions on resources,  Cloud IAM provides predefined roles that give granular access to specific resources and prevent unwanted access to other resources. There are tons of predefined roles and chances are, you would be able to find a predefined role for most of what you need to accomplish.

Policies in GCP

Policies are used to restrict access to stuff (resources).  Technically, they are JSON or YAML documents that ‘bind’ a user (or set of users) to a role (never to a set of roles, only a single role)

There are TWO types of policies – Organization Level Policies and IAM  Policies

IAM Policies

An IAM Policy is a basically, one or more binding. A binding binds a member (ormembers) to a single role(not a set of roles). This is also in contrast to AWS, where multiple roles can be specified in a binding.

Permission Boundaries that exist in AWS have no counterpart in GCP.   Organization Policies do have a direct counterpart (in fact, Google Cloud was the first to come up with Organizations – AWS followed – and Azure with their management groups also followed the GCP org construct)

Members can be user accounts, service accounts, Google groups, and domains (such as G Suite). A binding can also specify a condition, which is a logical expression that allows conditional access to a resource .  A condition can add constraints based on attributes of the request, the resource, or both.

{
  "bindings": [
    {
      "role": "roles/resourcemanager.organizationAdmin",
      "members": [
        "user:mike@example.com",
        "group:admins@example.com",
        "domain:google.com",
        "serviceAccount:my-project-id@appspot.gserviceaccount.com"
      ]
    },
    {
      "role": "roles/resourcemanager.organizationViewer",
      "members": ["user:eve@example.com"],
      "condition": {
        "title": "expirable access",
        "description": "Does not grant access after Sep 2020",
        "expression": "request.time < timestamp('2020-10-01T00:00:00.000Z')",
      }
    }
  ],
  "etag": "BwWWja0YfJA=",

Organization Policies ( Similar to AWS SCPs) –  are applied at a  higher level (higher than an IAM user).  They can be applied at the Project, at the Folder and at the Org Level. They are used to restrict access to resource at the entire level – for e.g. to restrict any service accounts from being created in/on a project, or to restrict Public IP access on Cloud SQL instances…

Disable service account creation

Restrict Public IP access on Cloud SQL instances

What about Custom Roles and Policies?

Custom Roles can be easily added as long as you (the IAM user) has the iam.roles.create permission. By default, if you are the owner of a project, you automatically have this permission and can create and manage custom roles.

<service>.<resource>.<permission>

As an example of a custom role that allows a user to view all instances as well as stop instances, the custom role would include the following predefined roles:

compute.instances.list 

compute.instances.stop

Limitations of Custom roles

Custom roles created within a project can’t list other projects.

Summary

Roles and Policies have a different meaning in GCP than they do in AWS. For most of your access needs (access to GCP resources), you will find a predefined role. For restricting access to resources, either at the resource level or at the Project Level (or higher levels), you would either use an existing IAM policy or an Org Policy or define one of your own (custom policy). Service Accounts are a unique construct within GCP (think programmatic identity) and very commonly used for a lot of tasks), whereas Service Accounts in AWS are essentially just IAM roles (also thought of as programmatic identities).

There is no analog of permission boundaries that and resource level policies (e.g. S3 bucket policies) that exist in AWS.

The post Roles and Policies in Google Cloud, and comparisons to AWS Roles and Policies appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.