GCP IAM, Roles, Service Accounts and Scopes (Road to Google Associate Cloud Engineer 2020 Certification)

Introduction

This is one of the most important (and scary for me) argument of the certification test. When I started to do some exam dumps, looking at some questions I asked myself: should I learn by hearth all this stuff? The questions asking to indicate which roles should be taken to allow operation on the resources looked quite hard for example. At the end I understood that I hadn’t totally learnt some important concepts which would have been helpful to answer without memorize lot of things.

The Cloud Identity and Access management is the Google Cloud Platform service that allow to create and manage permissions to access the resources and services.

There are some concepts that are crucial for the Associate Cloud Engineer exam:

• Members, roles and policies
• Types of role
• Least privileges
• Assign role to multiple users
• Service accounts
• Usage of external authentication system and access to external applications

Members, roles and policies

You can use Cloud Identity or G Suite to create and manage users in GCP. The 3 main pieces of the system are:

• members: a Google account (a final user), a service account (we’ll see this later. It’s used for applications and virtual machines), a Google group, a Google Workspace or Cloud identity domain.
• roles: a role is a collection of permissions which describe which actions can be done on a specific GCP resource
• policies: they attach one or more member to a role. The policy is attached to a resource and define who (member) assume a role on that resource

Types of role

GCP IAM has 3 types of roles:

• Basic or Primitive roles: Owner, Editor and Viewer roles. These roles are concentric; that is, the Owner role includes the permissions in the Editor role, and the Editor role includes the permissions in the Viewer role. They were originally known as “primitive roles.”
• Predefined roles: managed by Google they define a granular access to specific services. They’re considered legacy now because not granular enough to respect the principle of least privileges. You can grant multiple roles to the same user. For example, the same user can have Network Admin and Log Viewer roles on a project and also have a Publisher role for a Pub/Sub topic within that project. For a list of the permissions contained in a role, see Getting the role metadata.
• Custom roles: these roles are defined by the user and allow a deep control of permissions with a high granular access.

To determine if one or more permissions are included in a basic, predefined, or custom role, you can use one of the following methods:

• The gcloud iam roles describe command
• The roles.get() API

Provided vs custom roles

First important concept to keep in mind about the different types of role: it is advisable to use the existing GCP provided roles over creating custom roles with similar permissions as this becomes a maintenance overhead.

If GCP modifies how permissions are handled or adds/removes permissions, the default GCP provided roles are automatically updated by Google whereas if they were custom roles, the responsibility is with us and this adds operational overhead and needs to be avoided unless there are company’s internal security constraint to respect that don’t accept the role is automatically updated and, in this case, we need to have a total control of permissions.

If you really need a custom role, if possible, create it combining existing provided roles. For example, suppose the question contains a scenario where it is required to create a new role (at organizational level) including “BigQuery Job User” and “BigTable User” roles and assign it to a team in your organization trying to keep low the operational overhead. In this case, you can go to the GCP Console, IAM section and combine the 2 roles in the new one assigning it to the team at organization level. If the question include an answer mentioning to do the operation at project level, pay attention at the level mentioned in it.

Least privileges

You should always follow least privilege principle and assign only the needed permission to any resource. Sometime this can push to create custom roles because the predefined ones are including not needed access to the resources.

An example of application of this concept can be found in the following scenario: you have a new joiner in your team and you need to give them the possibility to view all the projects in the organization but avoiding the possibility to write or edit any access to the resources. In this case, you can already understand that the roles to assign to him are not more than viewer ones. So, any response including roles like “Admin”, “Owner”, “Editor” can be ignored. In this specific case you should assign him:

• roles/viewer: to see all the resources of the organization
• roles/resourcemanager.organizationViewer: to see the organization details (folders and projects)

Custom roles testing

When creating custom roles, it’s possible to set a stage to indicate if the role is ready for production or not (for example you can set stage to Alpha to say that you’re testing the role)

When setting support levels for permissions in custom roles, you can set to one of SUPPORTED, TESTING or NOT_SUPPORTED.

SUPPORTED vs TESTING

Supported indicates the role is ready for production while testing says it still needs some adjustments.

ALPHA vs BETA

Alpha indicates the first version of the role.

Assign roles to multiple users

When the scenario ask to assign one or more roles to multiple users, the right answer include the creation or usage of a group, add the users to it and assign the permissions/roles at the group. This because we’ll maximize reuse and minimize maintenance overhead.

The questions require always to keep in mind these aspects as well as the minimum number of steps and the best practices.

Service accounts

The service accounts are reserved for applications and virtual machines not for a person.

They are associated with a pair of RSA key pairs that are used to authenticate to Google and they don’t have any password.

An example of service account usage can be in a scenario where there is an application that needs to write and read file from Cloud Storage. You can create a service account, assign the access to the Cloud Storage API to it and use the credentials of the account from the app.

A good practice is to create a small amount of keys for the service accounts to keep easy the keys rotation management.

Remember that there is a limit of 100 user-managed service accounts per project.

Access scope

Access scopes are the legacy method of specifying permissions for your VM instance. Access scopes are not a security mechanism. Instead, they define the default OAuth scopes used in requests from the gcloud tool or the client libraries. Note that they have no effect when making requests not authenticated through OAuth, such as gRPC or the SignBlob APIs.

You must set up access scopes when you configure an instance to run as a service account. The action that an instance can do is defined by the combination of service account and scope.

A best practice is to set the full cloud-platform access scope on the instance, then securely limit the service account’s API access with IAM roles.

Access scopes apply on a per-instance basis. You set access scopes when creating an instance and the access scopes persists only for the life of the instance.

Access scopes have no effect if you have not enabled the related API on the project that the service account belongs to.

Usage of external authentication system or access to external application

SAML

It’s possible to setup a SSO with external provider supporting SAML in Cloud Identity using Google as service provider. Some questions are linked to this scenario and they often include also an answer where Google is mentioned as authentication system and the external provider as service provider which is wrong (the external system is the authentication provider used to access the GCP services): be sure to take your time to read the responses carefully to spot these small but decisive differences.

Password Vaulted Apps

Some questions provide a scenario where you want to provide access to external application which need credentials because they don’t support SAML federation.

As GSuite or Cloud Identity admin you can manage access to this kind of app. The Password Vaulted Apps Service store credentials to access applications and assign them through association with users group.

This functionality leverage an extension on Chrome and Firefox.

LDAP

Cloud Identity supports also Secure LDAP which allow to authenticate users using the LDAP protocol and the same Cloud Identity credentials used to access GSuite or other SAAS apps.

Tips for roles

Role name

Some questions ask to indicate specific role among among those listed as possible answers. I find difficult to remember the roles and sometimes the listed roles are quite similar with very small differences that might confuse you in choosing the right answer. So, one way to find the right response is to discard those that don’t exist.

So, I’ve tried to find a pattern to spot the correct roles. The pattern used to specify roles in GCP is generally this:

<service>.<entity>.<action>

• service is completely lower case: appengine, storage, cloudrun, etc. If you find a role with capital letter like «Billing…..» it is a not valid one
• entity: it can be «accounts» for the service «billing» or «objects» for the service «storage». It’s not always present because the role can be broader than a simple entity (for example, appengine.serviceAdmin doesn’t have any entity). It can be camel case (like in storage.hmacKeys.get)
• action: it can be in camel case and it indicates what the role can do. For example billing.accounts.update, the “update” action indicate that the role can update the billing account

These rules should always allow to do a choice between roles name that are very similar and differ only for small details.

Copy role to other projects

Some questions give the scenario where a role that is used in the development project is now needed in the production one. To satisfy this requirements, with as less steps as possible, it’s useful to remember that it’s possible to copy roles from a project to another using the command line (GCloud SDK)

Focus on CLI commands

Create a user

gcloud projects add-iam-policy-binding whizlabs-prj --member “user:bob@xyz.com” --role “roles/editor”.

Gives the role editor to the user bob@xyz.com for the project whizlabs-prj

Create a role with a YAML file

gcloud iam roles create viewer-role --project cloudlearning-prj --file role-definition.yaml.

Copy roles to another project

gcloud iam roles copy --source "role_id_to_copy" --destination "role_id_of_copied_role_in_dest_project" --dest-project "project_id_destination"

Managing service account

gcloud iam service-accounts update certification-tester@test-certification-ema.iam.gserviceaccount.com --description="service test for certification training"
gcloud iam service-accounts enable certification-tester@test-certification-ema.iam.gserviceaccount.com
gcloud iam service-accounts disable certification-tester@test-certification-ema.iam.gserviceaccount.com