Roles and Policies in Google Cloud, and comparisons to AWS Roles and Policies

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.