Identity & Access Management in GCP Environments

A significant portion of the world’s corporate data now resides in the cloud. According to experts, over 60% of corporate data is stored on cloud platforms. And 65% of that cloud data is stored in either an Amazon Web Services (AWS), Microsoft Azure or Google Cloud Platform (GCP) server. Despite being third in market share (11%), Google Cloud Platform (GCP) demonstrates impressive growth potential (48%).

What’s the reason behind this extremely high growth rate? Why have established behemoths like Target, Deloitte, Facebook, Intel, Bloomberg and Spotify decided to make GCP their cloud provider?

Well, GCP offers cloud services that can do anything requiring a remote server – run apps, configure & monitor IoT devices, host web servers, power ML apps, manage big data, and much more. And while other cloud services also provide these services, what sets GCP apart is its reasonable payment model backed by servers powerful enough to drive some of the world’s most prevalent applications (Google Search, Maps, YouTube). It has a pay-as-you-go payment model where you pay only for the resources you use, and comes with $300 in free credits. Should you decide to go with GCP, your organizational data will be stored in highly trusted servers that host more than 1.42 million websites.

What also sets GCP apart is its highly effective Identity & Access Management (IAM) infrastructure, something we’ll be discussing in-depth here. On-premises IAM is far different from IAM in cloud, because you’re dealing with both humans and machines in the latter – more on that in a bit.

A good place to start off is to highlight why IAM forms a key part of your cloud security posture.

The reality is, today’s attackers don’t hack in, they login.

And IAM permissions stop bad actors from coming into your cloud and accessing resources ranging from servers on VMs to databases full of sensitive data. Essentially, it lets you determine who has what access to which resources. If your IAM measures aren’t strong, eventually somebody will gain access to something they shouldn’t.

Before getting into GCP IAM best practices, it’s important to understand the lay of the land (even though we’re talking cloud). Here are the core components of GCP’s IAM:

• Member: This can be a Google account, a service account, a Google group or any domain that can be granted access to a GCP resource.

• Role: This is a collection of permissions – instead of granting permissions individually, GCP bundles them into roles that can be granted to members.
• Policy: These are the tenets that bind a member to their role, and dictate which actions a member can perform on what resources.

Let’s spend some time here to discuss service accounts. They are machine accounts that access data & execute instructions based on their programming, and play a role in every single VM, server and database in your projects. They are used for functions like authorizing movement & access of data, modifying infrastructure and building services. Considering their importance in your cloud infrastructure, it is imperative to have roles for them too – if a service account has too much access to cloud projects, that situation can cause as much chaos as a normal account. This facet makes IAM in cloud drastically different to other IAMs.

There are two types of service accounts offered by GCP:

• Google-managed service accounts are created & managed by Google. For example, when you create a VM in GCP, a supplementary service account automatically gets created with specific roles and permissions.
• User-managed service accounts, which are created & managed by you. For example, if you want to give your apps access to specific resources like the cloud storage bucket, you can create an account and assign it a specific role.

We’ve understood the different types of accounts involved in Google Cloud Platform (GCP) identity and access management. Now, let’s explore the various roles available:

• Primitive roles are basic roles like owner, editor and viewer, that have broad access and apply across all GCP servers.

• Predefined roles are service-specific roles that are more granular in nature than primitive ones. For example, roles/pubsub.publisher only provides access to publish messages in a Pub/Sub topic.

• Custom roles are roles that the user defines when predefined roles don’t match their requirements.

Here’s a list of all the primitive roles and their permissions: (some of which you may already be familiar with if you make Google Docs on a daily basis)

This segues brilliantly into the type of hierarchies seen in secure access GCP environments:

• It starts at the organization level, where roles granted cascade down.
• Then, it’s the folder level, which can contain multiple projects and is useful for grouping projects by category.
• Below is the project level, which contains & isolates resources, and is ideal for creating different environments like development or production. 
• Finally, we end at the resource level, which deals with granular access control on individual resources within a project.

Great, so we have a grip of GCP’s IAM infrastructure – accounts (Google account, service account) given roles (roles/owner, roles/viewer) to access certain resources (Compute Engine, Cloud Function, Kubernetes Engine). Here’s get right into the best practices when devising and implementing your GCP IAM strategy:

Avoid primitive roles

Primitive roles are too broad and heavy-handed, whereas predefined roles are more specific to individual GCP services & products like BigQuery and Cloud Storage. That makes predefined roles finer and granular than primitive ones.

Utilize all the value-added services

GCP’s IAM infrastructure has multiple services that allow you to properly customize your strategy. IAM Role Recommendations help fine-tune access based on past usage patterns. IAM Conditions help set fine-grained conditions on roles, like limiting access to specific IP ranges or times of the day. And IAM Troubleshooter diagnoses & resolves access issues in GCP, so that if a particular user encounters an access-denied error, the troubleshooter can provide the relevant insights.

Principle of Least Privilege

This is becoming an increasingly popular approach when it comes to identity access, as it perfectly balances and handles the two risks of external attacks and insider threats. Essentially, this principle is all about granting the minimum necessary access to all users. The individual user is provided with only the permissions & access they require to complete their given task. If they need more permissions, they will request, and all this will be logged. This principle works brilliantly when combined with the next point.

Separation of duties

This is a subset of the aforementioned principle, but at a project level. This is when access is structured in a way where one person isn’t able to complete a given project on their own. Therefore, if a particular user’s credentials is to be attained by attackers, they will not gain access to the entire project, just one part of it.

This approach can also be translated across hierarchies. A top level network engineer may have the power to create folders for projects, yet not be able to access the exact contents of them. All this goes a long way in mitigating the fallout of a breach.

Regular audits

Finally, this entire ecosystem doesn’t work if you don’t continuously monitor and improve upon it. Regularly review all your logs, and audit your IAM roles & permissions every 3 months or so.

By taking full advantage of GCP’s IAM ecosystem and all its myriad parts, you are setting yourself up for improved security through a simplified, centralized access control platform that also keeps in mind all your compliance requirements. However, do understand that cloud is a relatively new technology and there may be teething problems in trying to assimilate to it, so contact us today if you need someone to guide you through it!