• Authentication (AuthN): Authentication is the process of identifying a user through a private form of verification (for example, a password, a certificate, a key, and so on). In Google Cloud, Cloud Identity performs authentication.
• Authorization (AuthZ): Authentication on its own provides no set of permissions; authorization is used to set permissions that a user is allocated post authentication. In Google Cloud, Cloud IAM is used for authorization (and Cloud Identity for assigning admin roles with broad default permissions).
• Auditing: Auditing is about monitoring the resources accessed or modified by a particular identity.  In Google Cloud, Cloud Audit Logging helps with auditing resources and the Reports API helps auditing in Cloud Identity operations. You can also integrate the logs with prominent SIEM systems.

This post is focused on authentication.

What is Cloud Identity?

Cloud Identity is the identity provider (IdP) for Google Cloud. It also is the Identity-as-a-Service (IDaaS) solution that powers Google Workspace. It stores and manages digital identities for Google Cloud users. When you migrate to or start using Cloud Identity, you create an account at no charge for each of your users from the Google Admin console. Cloud Identity (free version) comes with a limit of 50 users, customers can either purchase cloud identity premium (paid subscription) or request CI free license increase (done based on justification). Cloud Identity provides user lifecycle management, account security, and single sign-on (SSO) support.

Setting up Cloud Identity is a prerequisite to onboarding your organization onto Google Cloud. Here is how it works:

• Upon setting up your Cloud Identity instance you will be asked to add a domain that you own (typically your company’s main domain)
• You will be asked to validate that you own this domain; this is most typically done through adding TXT record in your DNS records.
• Once this validation is complete, a Google Cloud organization will be created with the same name as your domain and you can begin using Google Cloud.

How Cloud Identity connects with Google Cloud

There are a variety of ways in which identities can be imported into Cloud Identity: manually, through a CSV file or using APIs and third party IdP systems. Once set up, users and groups will be used by Cloud IAM to grant access to Google Cloud resources. It’s important to understand that Cloud Identity roles are used for user/group management and are distinct from Google Cloud IAM roles, which manage permissions to cloud resources. This distinction will be covered in more detail in a separate post on Cloud IAM authorization.

Authentication options

Aside from username and password, there are two frequently used authentication options:

2-Step Verification (2SV) with Google authentication

2-Step Verification adds a second factor for authentication in addition to a username and password. However,  not all the 2SV methods are the same. SMS, backup codes, one-time passwords (OTP), and mobile push prompts provide additional protection but they are still phishable. FIDO Universal 2nd Factor (U2F) security keys are highly phishing-resistant. The U2F protocol uses cryptography to verify a user’s identity and URLs of the website that is being accessed. Keys stay on the device so there are no server-side shared secrets to steal, which helps protect against phishing, man-in-the-middle, and replay attacks.

Google recommends security keys for security. Further, security keys should be considered mandatory for admins for optimal security. Google offers the Titan Security Key, which includes special firmware engineered by Google to verify the key’s integrity. Android and iOS devices can also be used as security keys (requires Bluetooth). With the Titan Security Key, the user experience is similar to signing on via the Google prompt but the protection is stronger, because the key uses the FIDO U2F protocol.

Cloud Identity also offers the possibility to require 2SV with a third-party IdP (e.g., Azure AD or Okta). For example, with this option a user will login in Azure AD by entering her password, and after a successful SAML exchange between the IdP (Azure AD) and Google will be challenged with the 2SV method set up in Google as an extra authentication step. Post SAML SSO verification is not static (e.g will not be challenged every time), rather risk based.

SSO authentication with a third-party identity provider

You can also delegate authentication using SSO to a third-party SAML 2.0 identity provider, such as Okta, Ping, Active Directory Federation Services (AD FS), or Azure AD. This method normally means faster Google Cloud onboarding and less disruption if you are already using a compatible IdP.

That was a bird’s eye view of authentication options in Google Cloud. Once your users are authenticated they need to be authorized to perform any actions they may want to take. Authorization with Cloud IAM is covered here. For a more in-depth look at Cloud Identity check out the documentation.

For more #GCPSketchnote, follow the GitHub repo. For similar cloud content follow me on Twitter @pvergadia and keep an eye out on thecloudgirl.dev