Access Control using IAM and Service Account in GCP

Let’s say you have resources in google cloud and you want to access those resources. To configure who can access which resources, GCP provides us with a service called Identity and Access Management. This is all about Authentication and Authorization.

GCP IAM logo

In this article let’s, dive into learning about google cloud resources and access policies. Before learning about the access policies in GCP, let us first learn about google cloud hierarchy.

Google cloud hierarchy has 4 levels that are resources, projects, folders, and organizational nodes:

GCP Hierarchy

· At level 1, we have resources. These represent virtual machines, cloud storage buckets etc. These are all services provided by google cloud.

· At level 2, we have projects, each resource is bound to a project.

· At level 3, we have folders. The projects can be organised into folders or sub-folders.

· At the top level is an organisation node, which encompasses all the projects, folders, and resources in our organisation. This node has organisation admin (have control over all cloud resources) and project creator role (have control of project creation).

Coming to access policies, access policies in GCP can be applied to project, folder, and organization levels. Some GCP resources allow policies to be applied to individual resources too. Let’s say you have applied policy to a project, and then automatically that policy will be applied to the resources in that project.

But you may ask why we may need policies. When Organization has a lot of projects and resources, we may need to restrict the users on basis of who has access to what. To do this task, administrators can use Identity and Access Management, or IAM.

With IAM, administrators can define “who” can do “what” on “which” resources. So, we have many important concepts in IAM. Let’s go one by one:

Members

The “who” part of an IAM policy can be a Google account, a Google group, a service account, or a cloud Identity Domain. The members are assigned roles.

Roles

In the “what” part, we define roles. You can grant permission to users like create, delete, start, and stop resources. There are three kinds of roles in IAM:

Three kinds of roles

· Basic: When these are applied to a Google Cloud project, they affect all resources in that project. Basic roles include owner, editor, viewer, and billing administrator.

· Predefined: Specific Google Cloud services offer sets of predefined roles, and they even define where those roles can be applied. For example with Compute Engine, you can apply specific predefined roles — such as “instanceAdmin” — to Compute Engine resources in a given project, a given folder, or an entire organization. This then allows whoever has these roles to perform a specific set of predefined actions.

· Custom: What if we want to have more specific permissions? These we can say as least-privilege. Each person is given the least privilege on the resources he/she is working on. Custom roles will allow you to define exact permissions. These can be applied to project or in an organization level, these cannot be applied to folder level.

However, you can club a number of permissions together to form a custom role according to your needs.

Policy:

We use policy to assign roles to the members. Policy object has a list of bindings. These bindings bind roles to a list of members. Let’s look into one example of policy:

{
 “bindings”: [
 {
 “role”: “roles/storage.objectAdmin”,
 “members”: [
 “user:sharadhi@test.com”,
 “serviceAccount:my-app-name@appspot.gserviceaccount.com”,
 “group:admins@test.com”,
 “domain:google.com”]
 }
 ]
 }

As you see in the above example, we have a role called storage object admin. This role is assigned to a specific user, service account, group, and domain. Every member of that domain or group will have admin permissions. We can also specify conditions. In condition, we can mention that some permission is allowed only till some time.

Some CLI commands that are useful in IAM are:

gcloud projects get-iam-policy project-id

This returns back all bindings in this project. These show link between members and roles.

gcloud projects add-iam-policy-binding project-id — member=user:sharadhi@test.com — role=roles/storage.objectAdmin

This will add the member/user mentioned to the role of storage object admin.

gcloud projects remove-iam-policy-binding project-id — member=user:sharadhi@test.com — role=roles/storage.objectAdmin

This will remove the IAM policy role.

gcloud iam roles describe roles/storage.objectAdmin

If you want to check what permission that storage.objectAdmin have, you can run the above command and get the list of permissions.

Service Accounts

What if you want to give permission to resources like Compute Engine rather than a person? Well, that’s what service accounts are for.

Let’s say you have an application running in a virtual machine that needs to send data to some database. For this, you don’t want anyone to access the data other than that VM. So we can create a service account to authenticate that VM to the database. Service accounts are named with an email address (id-compute@developer.gserviceaccount.com), but instead of passwords, they use cryptographic keys to access resources.

As a service account is also a resource, it can have an IAM policy of its own like who can edit and view these service accounts.

There are a few types of service accounts:

1. Default service account: These are automatically created when some services are created. This is not recommended as it has a default editor role.

2. User Managed: These are recommended as they are user created and provide fine-grained access control.

3. Google-managed service accounts: these are created and managed by Google. This is used by Google to perform some actions n behalf of users

Access control list

Access Control Lists (ACLs) define who has access to storage and objects as well as what level/permissions they have on that. You may be wondering how is this different from IAM. IAM is applied to all objects in the bucket. This means if I give the user read permission to the bucket, that user has read permission on all the buckets. If we want to customize access to specific objects/buckets then we make use of ACLs

Signed URL’s

Let’s say you want the user to access storage for a limited time and you don’t want a google account. In this scenario, we can use a signed URL. This Signed URL provides us with specific permission for a limited amount of time.

I hope by reading this article, you have got an idea of what are IAM and Service accounts in google and How to manage access and permission through IAM. For more understanding, you can go for official documentation here: https://cloud.google.com/iam/docs/overview

If you liked this article, please consider donating whatever amount you can using this link. It would mean a lot.

Sharadhi S S