Identity Management on the Google Cloud Platform

The Google Cloud Platform (GCP) is Google's answer to the AWS cloud offerings from Amazon.

AWS continues to dominate the market, with Microsoft Azure and Google vying for second place. While Google is not the leader, their ubiquitous nature makes them an interesting option when choosing a cloud service provider. In this post, we'll discuss what I think is their platform's greatest offering, identity and access management.

Disclaimer: This post defines and uses many acronymns. I prefer to keep their usage minimal, but its difficult sometimes. Apologies all around for the acronymn torrent.

Cloud Identity is GCP's identity and access management (IAM) product, used to manage accounts and resource access for a customer on the platform. To understand how it works for an organization, let's look at three key subjects, the resources, identities and access.

Resources

GCP resources are divided into four hierarchical categories.

1. The first and highest level one is the Organization, which is analogous to an Active Directory domain. GCP offers productivity tools (word processing, spreadsheets, presentation software, etc.) through their GSuite service. GCP offers identity management through their Cloud Identity platform. Customers using GCP create an Organization via GSuite and Cloud Identity.
2. Below the Organization, you have Folders, which typically are used to represent departments in an organization.
3. Then below that you have Projects which represent a group of users, their permissions and resources they can access.
4. Finally at the bottom are the Resources, the actual services of GCP.

So moving back up the ladder, Resources are defined in Projects, multiple Projects may exist within a department (Folders), all the departments fit into a single Organization. Note also that there may be multiple organizations/domains in a single company, but the Organization is the highest unit in a GCP account.

Identities and Access to Resources

Identities consist of real individuals, groups or service accounts. Access to Resources is provided via permissions, these permissions can be assigned to individual identities via ACLS, or to groups via roles. These permissions grant access to a service or API resource. GCP has a number of different identity types, including Google accounts (for domains managed via GSuite, like gmail.com), service accounts (non-user accounts created for the purpose of accessing services APIs and resource data), Google groups (which can contain various other Google accounts), GSuite domain accounts (the accounts created under a customer domain's GSuite account), Cloud identity domain accounts (the accounts under a customer domain, but which do not have access to GSuite) and others (accounts which may not be Google or domain accounts, but have access to APIs and are approved by an admin).

Multiple ways to Authenticate

The true power of Cloud Identity is in it's configuration flexibility. GCP admins can setup identities, roles and their permissions in the GCP web console. This management allows for atomized users and groups, with specified permissions. Authenticating can be done using the classic username and password credential combo, or (drumroll) using Google's single sign on (SSO) solutions!

SSO allows your users to sign in once and gain access to a multitude of applications. These can be GSuite apps, other Google cloud apps or non-Google apps. In a nutshell, the SSO process is as follows:

SSO process | Source: DoubleOctopus.com

The Service Provider above is the service or app the user is attempting to access. The Identity Provider (IDp) above would be Cloud Identity. If you use Cloud Identity as the IDp you can setup access to applications which support SAML assertions or OpenID Connect. You can also setup SSOs using a third party IDp (useful when using Cloud Identity for non Google apps). In the case of another IDp, Cloud Identity manages the third party apps, like a service provider. These different options allow for the integration of any combination of applications to an SSO, relieving users of the need to manage multiple credentials (a potential security concern in and of itself).

Along with federated SSO or traditional authentication schemes in GCP, you can add Google's tried and true multifactor authentication (MFA) to the process. This tremendously increases the reliabilty of user authentication to prevent breaches and security hacks. To realize the benefits of MFA with SSO, its preferred to use Cloud Identity as your IDp. This allows admins to enforce MFA for users. It also allows for multiple options to provide the secondary authentication, including prompts on mobile devices, the Google Authenticator app and even physical security keys.

Closing Thoughts

The Google Cloud Platform's identity and access methodologies are straightforward and easy to grasp. Even if you aren't using Google apps, you can leverage Cloud Identity to build a mighty authentication and authorization layer.