Protecting GCP Access with Okta and SGNL

Introduction

Protected Systems are applications, services, or infrastructure that you want to protect with SGNL. In this guide, we’ll describe how to achieve fine-grained access control inside of Google Cloud Platform with Okta and SGNL, enabling the right amount of access to infrastructure and data inside of GCP. Google Cloud recently released Workforce Identity Federation, enabling fine-grained access management for federated users, authenticating to GCP.

With this integration, GCP and Okta need not know about the policies, systems of record, or any of the data in SGNL - it simply needs to pass to SGNL:

Who/What is requesting the access (The Principal)
(Optional) What is attempting to be accessed (The Asset)
(Optional) What operation is being attempted on the asset (The Action)
An access token that ensures the Protected System is a legitimate caller into SGNL

Prerequisites

An GCP Organization
An Okta Tenant
A SGNL Client
A SGNL User Account with Admin privileges
At least 1 Okta system of record integrated to SGNL, containing principals and (optionally) assets that will be evaluated in access evaluations
(Optional) 1 or more policies that you want assigned to the integration

Creating a Protected System in SGNL

Log-In to your SGNL Client with an Admin Account
From the left navigation pane, select Protected Systems and Add, or simply click Add from the SGNL Dashboard
Select ‘Google Cloud Platform’ from the Infrastructure category in the list of integrations
Give your integration a descriptive display name and description
Specify the Default Policy to be applied to your App
- Allow: If no policies provide a decision for an access request, SGNL will respond to the access request with an Allow decision
- Deny: If no policies provide a decision for an access request, SGNL will respond to the access request with a Deny decision
Next, you’ll need to configure which identifier Okta is using to describe your user/principal
- This is likely your Okta user’s email address or login name. This should be in the format of the Principal ID of the user that will request access to the Protected System.
- e.g. If an Okta user will be requesting access to this Protected System, GCP, with the Principal ID as their email address, the principal identifier should be the Okta email address.
You’ll also need to define the identifiers for the types of Assets that you are looking to protect
- This might be customer identifiers sourced your CRM system, or products that your customers are buying
Once configured, click Continue to save your configuration and move on to other configuration steps

Configuring Authentication

Authentication ensures that only authorized systems can make requests into SGNL, as well as verifying the identity of an integration in order to effectively evaluate Policies - to access Authentication settings, open your GCP protected system and select the Authentication tab
Click Generate Token
Give your token a descriptive name so that you know how it’s being used in the future and click to Generate Token
On the next screen, copy the token - this will be used by Okta to make access requests to SGNL using the SGNL Access Service API
Note: The value of this token is not available again after this screen, so ensure you securely store it for steps later in this guide

Configuring GCP with Okta for SSO

Configuring Transforms

From within your Google Cloud Platform Protected System, select Transforms
Select Search Transforms, then Okta OIDC
SGNL uses JSONPath for Mapped Fields, in order to determine the attributes to map to the request in SGNL, from the Okta Inline Token Hook, some defaults are pre-selected, but for OIDC Token Hooks:

The principal Id as {$.data.context.session.login}
The IP Address is {$.data.context.request.ipAddress}
and the Action can be an action that feels appropriate for your organization, e.g. gcp-access

In the Response section of the Transform, you wil want to configure at least 2 operations, one for passing in a subject identifier to GCP, and one for modifying claims in GCP IAM. For the first operation:

You want to enusre you select an add operation
You have selected a type of com.okta.identity.patch
You are selecting an Asset that contains temporary information about a subject related to their access decision, such as the number of a ServiceNow Change Request temporarily assigned to a user
Your path is prefixed with /claims/... and includes the subject claim name you have related to the subject passed in to GCP (e.g. /claims/sgnlsubject), or will specify in Okta’s Workforce Identity Federation
Your value is the value of a subject identifier that maps to google.subject in GCP IAM

For example, if the Asset is a ServiceNow Change Request, the value could be: {$.SNOWCR.assignedTo}-{$.SNOWCR.number}

For the second operation:

You want to enusre you select an add operation (unless you have complex business logic necessary to replace existing claims)
You have selected a type of com.okta.identity.patch
You are selecting an Asset that contains the attribute you want to pass as a claim to GCP
Your path is prefixed with /claims/... and includes the claim name you have, or will specify in Okta’s Workforce Identity Federation (e.g. /claims/sgnlaccess)
Your value is the value of a claim you have or will configure in GCP IAM Policy

For example, if the Asset is a ServiceNow Configuration Item, the value could be: {$.SNOWCI.correlationId}

Integrating Okta Token Inline Hooks with SGNL to protect GCP

Integrating SGNL with Okta, for the purposes of securing GCP, relies on Okta Inline Hooks. Okta Inline Hooks enable Okta to make an outbound request that can be routed to SGNL, in order to determine:

a. whether a principal has access to a specific GCP environment b. what assets within an GCP environment a user should be able to access during a given session c. what roles to allocate to the user for the session, based on business context

A simple example of this in action is using Okta Hooks to ask whether a user can access a specific customer’s data in GCP for a given session. In this scenario, SGNL Customers have found that assigning Customer Identifiers as Claims in the OIDC Token offer the greatest level of flexibility and dyamism, when combined with existing GCP roles and permissions, to dynamically specify an individual principal’s (user, service, robot, etc) permissions for a given session.

Create an OIDC App

If GCP and Okta are not already integrated with OIDC in your environment, you’ll need to create a new OIDC Application within Okta to SSO into GCP, the complete set of steps may vary depending on your business needs, however this guide will provide many of the steps for a common deployment. Okta’s steps to configure an OIDC Integration are available on their Support Portal

From within Okta Applications, create a new App Integration
Select OIDC and Web Application
Specify a Name and Description for the App
You’ll need to specify a Redirect/Sign-in URI for Google Cloud, you won’t know that all yet, but to get started you can enable wildcard support and specify https://auth.cloud.google/signin-callback/*
Choose how you want users to be assigned to the App

Create a Token Inline Hook

You’ll need to create a Token Inline Hook for use by SGNL. Full Details of configuring an Inline Hook are available in Okta’s Support Portal

From Workflow select Inline Hooks
Create a new Inline Hook and Select Token Inline Hook
Give the Hook a name and description, and specify your SGNL Access API endpoint, appended to enable Transforms as your URL, for SGNL Cloud, this defaults to https://access.sgnlapis.cloud/access/v2/search?transform=true
Specify Authorization as your Authentication Field and Bearer <your integration token> as the Authentication value, the integration token is the one you copied earlier in this guide

Create an OAuth Authorization Server

Unfortunately, Okta doesn’t allow Token Inline Hooks with the Org Authorization Server, so you’ll need to create a new one. Okta’s steps to create an OAuth Authorization Server are on their Support Portal

Create the Authorization Server from Security - API - Authorization Servers
Specify the Audience as https://auth.cloud.google and change to the Okta URL as the issuer (from Dynamic)
Specify your Policies and Rules to allow (at a minimum) your GCP OIDC Client to use this authorization server
Finally, specify the Token Inline Hook you created earlier in the Access Policies -> Rules section of your Authorization Server, this will enable Okta to call SGNL at Authentication Time

Steps to Configure Google Cloud Platform

Configure Workforce Identity Federation

Workforce Identity Federation is a relatively new capability in GCP, enabling users to access Google Cloud without persistent identities, and leverage claims to manage access within the platform.

Create an Identity Pool

Within the GCP Console, browse to IAM and Workforce Identity Federation
Create a new Identity Pool given a name and description, as well as specifying the default lifetime for authenticated identities in this pool
Next, create a Provider associated with the pool – this will be the Okta Authorization Server you just finished creating
The issuer should take the form of your Okta URL, appended with oauth2/<some Okta Id, e.g. ausjnol9oaLuUuclw697>
Specify the Client Id and then Secret of the GCP OIDC App you created earlier
Choose the Response Type as Code and the Assertion claims behavior as User Info and Id Token
For the subject claim, you’ll want to map the inbound subject identifier to the Google subject value.

While creating the Transform in the SGNL Protected System, you specified /claims/<some subject claim> – you’ll likely want to use that same claim value in the OIDC 1 section, prefixed with assertion, e.g. assertion.sgnlsubject

Finally, you need to configure the claim that you want mapped from the Id Token

In the Google 2 (assuming only a subject claim exists), you’ll want to map the inbound claim to a Google Attribute, e.g. attribute.myClaim (assuming myClaim is the attribute you want to use)
While creating the Transform in the SGNL Protected System, you specified /claims/<some claim> – you’ll likely want to use that same claim value here, prefixed with assertion, e.g. attribute.sgnlaccess
In the OIDC 2 section, you’ll likely want to keep things consistent and use assertion.sgnlAccess (note attribute and assertion)

Grant Access in GCP IAM

You’re now ready to start granting access depending on the inbound claims, you do this directly inside of GCP IAM.

Browse to IAM and Grant Access
You’ll want to add the Identity Pool Principal Set directly in IAM – GCP provides thorough documentation for configuring IAM, however if you want to grant a role only to users who SGNL has added a sgnlAccess claim of value infra-admin, you might grant the principal:

principalSet://iam.googleapis.com/locations/global/workforcePools/<Your Workforce Pool ID>/attribute.sgnlaccess/infra-admin

Assigning Policies

Once the GCP integration is created, you can start assigning versions of Policies - to get started, select Policies from the tabs in your newly created integration
Select ‘Assign Policies’
Select:
- The Policies you want to apply to the integration with the check box
- The version of the Policy you want applied
Click Next once you have the Policies and Versions configured as is appropriate
Select the Enforcement mode for the Policies you chose in the previous step
- Simulated: Policy Versions that are being simulated will only log their access decision in the SGNL logs and will not impact the access decision that SGNL hands back to an integration. Simulated policies are useful for performing what-if analysis of new policy versions as well as debugging policy changes.
  Note: It’s considered best practice to start with policies in Simulated mode, to verify that policies have been created an applied as expected
- Enforced: Policy Versions that are being enforced will impact the access decisions that SGNL hands back to an integration. Enforced Policies will determine access for an integration
Select your desired Enforcement mode and select Assign
Versions of Policies will now be Assigned to your integration

Configuring Actions

As part of the SGNL CAEP Hub, GCP can be configured to receive session revokation events from SGNL. Follow the steps below to configure GCP to enable this integration.

Configuring GCP

Login to the Google Cloud Console with a user with permissions to manage Projects
Use an existing Google Cloud project that does not already have an OAuth consent screen configured, or create a new project following this documentation
From within the project, search for API & Services
Click “OAuth consent screen” from the left menu bar and configure it following this documentation with the below details:

Set your authorized domain as sgnl.cloud
For scopes, you should include:
- Non-sensitive scopes: ./auth/userinfo.email, ./auth/userinfo.profile, openid
- Sensitive scopes: .../auth/cloud-platform

Click on “Credentials” from the left menu bar and click on “Create Credentials”, then follow this documentation with the below details:

Choose type “OAuth Client ID”
Choose Application type “Web application”
For the Authorized redirect URI, go to SGNL and click on your Google Cloud Platform Protected System, then select Actions. You will fill in these fields as a next step, but for now, copy the Redirect URI shown at the bottom and paste it as your input for this input Authorized redirect URI field. Example value: https://console.sgnl.cloud/{client_name}/auth/oidcCallback

Copy your Client Secret and Client ID and store it temporarily somewhere safe, then click Save
From APIs & Services, search for “Identity and Access Management (IAM) API” and click ‘Enable’, you should see the setting switch to enabled if successful

Configuring SGNL

Log in to SGNL with the same user that you configured GCP with above
From your Google Cloud Platform Protected System (with a type of at least Google-1.0.0), select Actions
Specify the Address for the Action as https://admin.googleapis.com
Select OAuth2 Authorization Code as the Authentication Method
Paste in the Client ID and Client Secret from Step 6 of Configuring GCP above
Specify your Scope as https://www.googleapis.com/auth/cloud-platform
Specify your Token URL as https://oauth2.googleapis.com/token
Set the Auth Style as Auto Detect
Set the Auth URL as https://accounts.google.com/o/oauth2/v2/auth?access_type=offline&prompt=consent
Click on Authenticate and follow the consent screen. Once you seen the green check mark showing successful authentication, click Save.

Creating your first action

From within SGNL you can configure any change in the graph to trigger actions that are directed to downstream systems. For general documentation on how to configure Triggers and Rules that match your use-case, refer to our CAEP Hub documentation. In an example scenario, you may want to trigger an GCP Session Revocation event when an end-user ServiceNow Change Request is closed — as they should no longer have access to GCP since the request they were working on is no longer active. To complete this example integration, we assume someone has already configured ServiceNow ITSM as a System of Record in SGNL:

Select CAEP Hub from the SGNL nav
Select Triggers
Create a new Trigger:

Give the Trigger a Name and optionally a Description
Select ServiceNow User, ServiceNow ChangeRequest, ServiceNow Configuration Item as the Nodes
Select the CILinkedToChange and AssignedToUser relationships between the ServiceNow Configuration Item and ServiceNow ChangeRequest, and the ServiceNow ChangeRequest and ServiceNow User, respectively
Set the Condition to where ServiceNow ChangeRequest active is equal to “false”
Save the Trigger

Create a new Rule

Give the Rule a Name and optionally a Description
Select the Trigger you just created
Select the option for when the ‘Matches Trigger Scope’
Click the button to ‘Select an Action’
Choose ‘Google Cloud Platform’ and the ‘Generic Webhook’ Action

Configure the required and optional fields as follows

In the method field, input DELETE
In the address field, input https://iam.googleapis.com/v1/locations/global/workforcePools/<Your Workforce Pool ID>/subjects/<Value for Subject Claim Configured in Transform>, where the value for the subject claim comes from what you configured in the Transform from your Protected System (i.e. for the /claims/<some subject claim> path).
- Example address value: https://iam.googleapis.com/v1/locations/global/workforcePools/<Workforce Pool ID>/subjects/{$.SNOWCR.assignedTo}-{$.SNOWCR.number}

Save the Rule

That’s it. Once you’ve finished configuring your rule, the next time a User’s change request is closed in ServiceNow, SGNL will revoke their session in GCP.