Native Google Authentication in Google Cloud SecOps

6 min readJun 10, 2024

In this post I explore the exciting upcoming new feature in Google Cloud SecOps: native Google Cloud Identity authentication.

You’ll learn how it can simplify user access, enhances security, and can reduce the time required to setup SecOps. I’ll walk you through the process step-by-step, from checking your current configuration to assigning the right permissions and enabling native Google authentication for a seamless experience.

Using Google Cloud Identity to authenticate in Google SecOps

📝 The native Google auth feature for Google Cloud SecOps is currently being rolled out. If you don’t see the option to enable it in your Google Cloud console yet, rest assured it will be available soon. Throughout this post, I’ll refer to Google Cloud Identity authentication as “Google Auth” for brevity.

Cloud Identity (CI) and Workforce Identity Federation (WIF)

If you’re familiar with CI and WIF you can skip this section.

What is Cloud Identity?

If you’re already using Google Workspace (formerly Gsuite) or Google Cloud Platform (GCP) you’re likely familiar with Cloud Identity, Google’s Identity and Access Management (IAM) solution used to manage users and groups in Google Workspace and Google Cloud Platform (GCP).

Cloud Identity is available in two tiers, Free and Premium. For the purposes of Google SecOps the Free tier is adequate, providing a default of 50 user licences, with additional user licenses available free upon request via Google support, and provides security features such as two step verification.

What is Workforce Identity Federation?

If you’ve already set up Bring Your Own Identity (BYOID) for Google Cloud Security Operations (SecOps), you’re using WIF.

This feature lets your organization leverage your existing identity provider (IdP) — such as Azure Active Directory or Okta — to control who can access Google Cloud resources, including SecOps.

To use WIF with Google SecOps you create a Pool, which is linked to a SAML Provider, e.g., Azure AD or OKTA, and then within GCP IAM you configure authorization. When a user tries to access SecOps they’re redirected to your IdP for authentication and, upon success, WIF receives the user information and attributes and authorizes them accordingly.

The advantage of WIF is you don’t need to create and manage separate user accounts within Google Cloud, but the downside of WIF is it can be challenging to setup when you need to involve separate Identity and Cloud teams during a proof of concept or deployment.

Configuring Native Google Authentication for Google Cloud SecOps

Here’s a high-level overview of the steps involved in enabling native Google authentication for SecOps:

Assess Your Current Setup: Determine whether you’re currently using Workforce Identity Federation (WIF) or another authentication method. This will help you plan the migration.
Create Google Groups: Establish Google Groups that align with your SecOps access roles and permissions.
Assign IAM Roles: Grant the appropriate Identity and Access Management (IAM) roles to these groups within Google Cloud.
Enable Native Google Authentication: Configure Google Cloud SecOps to use native Google authentication instead of your previous method.

Important Note: Switching to native Google authentication is an either/or decision. You can’t simultaneously use both native Google authentication and WIF. However, you can always switch back to WIF if needed, so you have flexibility in choosing the best authentication method for your organization.

Verify Your Current Google Cloud SecOps Setup

Before switching to native Google authentication for SecOps, it’s important to understand your current configuration:

New SecOps Customer?
If you’re setting up SecOps for the first time, you’ll be presented with the option to enable Google authentication during the initial deployment wizard in the Google Cloud console. It’s a straightforward process to choose this option from the start.
Existing SecOps Customer Without a Linked GCP Project?
To use Google authentication, you’ll need to have a Google Cloud Platform (GCP) project linked to your SecOps tenant. If you haven’t done this yet, you’ll need to complete that step first.
Existing SecOps Customer with a Linked GCP Project?
Great news! If you’ve already linked a GCP project to your SecOps tenant, you’re ready to switch to Google authentication. You’ll find the option to make this change within the SecOps settings.

Create appropriate Google Groups

Using Google Groups for managing SecOps authorization is a recommended best practice as it’s simpler to maintain and less prone to errors than assigning permissions to individual users.

Google Groups can be created in either:

Google Workspace: This is often the most intuitive method if you’re familiar with Workspace’s administrative tools. You can easily manage group membership and settings alongside your other Workspace resources.
Google Cloud Console: The Cloud Console offers a streamlined interface for creating and managing groups specifically for Cloud Identity and IAM purposes.

In order to create Google Groups you’ll need certain permissions which are documented here.

Assigning Principals in Google Cloud IAM

Before enabling Google Authentication for SecOps you should configure authorization and access within GCP IAM. This step ensures that the right users and groups have the correct permissions within SecOps, and that you can login!

While the process is similar to configuring WIF for SecOps, there are a few key differences to keep in mind:

Principal Syntax: When assigning permissions in IAM for native Google authentication, you’ll use the email address format for Google Groups (e.g., secops_admins@yourdomain.com).
GCP Roles: You’ll need to use the specific predefined roles for Google SecOps for both SIEM and SOAR, where as with WIF you only need assign the SIEM predefined roles.

To get started, consider assigning the following predefined IAM roles in the Google Cloud Project linked to your SecOps tenant:

|------------------------ |-----------------------|
| Principal               | Role                  |
|------------------------ |-----------------------|
| secops_admins@acme.com  | Chronicle API Admin   |
| ------------------------| Chronicle SOAR Admin  |
                          |-----------------------|

You can efficiently apply these role assignments using the gcloud command-line interface (CLI) via CloudShell:

gcloud projects add-iam-policy-binding <GCP_PROJECT_ID> \
  --role roles/chronicle.viewer \ 
  --role roles/chronicle.soarAdmin \ 
  --member "group:secops_admins@acme.com"

Remember to replace <YOUR_GCP_PROJECT_ID> with the actual ID of your GCP project.

For info, alist of available predefined SecOps GCP IAM Roles can be found here:

Chronicle API Admin (chronicle.admin)
Chronicle API Editor (chronicle.editor)
Chronicle API Limited Viewer (chronicle.limitedViewer)
Chronicle API Restricted Data Access (chronicle.restrictedDataAccess)
Chronicle API Restricted Data Access Viewer (chronicle.restrictedDataAccessViewer)
Chronicle Service Agent (chronicle.serviceAgent)
Chronicle SOAR Admin (chronicle.soarAdmin)
Chronicle SOAR Service Agent (chronicle.soarServiceAgent)
Chronicle SOAR Threat Manager (chronicle.soarThreatManager)
Chronicle SOAR Vulnerability Manager (chronicle.soarVulnerabilityManager)

Once you’ve assigned the appropriate IAM roles in your linked GCP project, it’s time to enable Google authentication for SecOps:

Open the Google Cloud console.
Go to Security > Google SecOps

From the Single Sign-On tab select Google Cloud Identity

You’re now ready to test logging into your SecOps tenant using your Google identity.

Summary

Should I implement or migrate to use native Google authentication?

The answer depends on your specific situation and priorities:

New to SecOps or primarily using Google Workspace or GCP for identities?

Seamless Integration: Deploying SecOps with native Google auth streamlines integration with your existing Google environment.
Simplified Management: If your users already have Google accounts, it simplifies identity management and reduces reliance on third-party identity providers (IdPs).
Additional Functionality: It unlocks access to additional Google Cloud Platform (GCP) security features like Privileged Access Management (PAM), which from testing does not appear supported with WIF and SecOps.

Existing SecOps User with external identities?

Stick with WIF: If your identities are managed outside of Google (e.g., in Azure AD or Okta), WIF remains the recommended authentication method for SecOps.

Additional Considerations:

Audit Logging: While both methods offer audit logs, carefully evaluate the differences in granularity and detail based on your specific auditing requirements
Migration Effort: If you’re already using WIF, consider the potential disruption and effort involved in migrating to native Google authentication. Weigh this against the benefits it offers.