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

  1. Log-In to your SGNL Client with an Admin Account
  2. From the left navigation pane, select Protected Systems and Add, or simply click Add from the SGNL Dashboard
  3. Select ‘Google Cloud Platform’ from the Infrastructure category in the list of integrations
  4. Give your integration a descriptive display name and description
  5. 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
  6. 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.
  7. 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
  8. Once configured, click Continue to save your configuration and move on to other configuration steps

Configuring Authentication

  1. 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

    SGNL - Authentication

  2. Click Generate Token

  3. Give your token a descriptive name so that you know how it’s being used in the future and click to Generate Token

    SGNL - Generate Token

  4. 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

    SGNL - Token

Configuring Transforms

  1. From within your Google Cloud Platform Protected System, select Transforms
  2. Select Search Transforms, then Okta OIDC
  3. 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:

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

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.

Steps to Configure Okta

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

  1. From within Okta Applications, create a new App Integration
  2. Select OIDC and Web Application
  3. Specify a Name and Description for the App
  4. 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/*
  5. 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

  1. From Workflow select Inline Hooks
  2. Create a new Inline Hook and Select Token Inline Hook
  3. 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
  4. 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

  1. Create the Authorization Server from Security - API - Authorization Servers
  2. Specify the Audience as https://auth.cloud.google and change to the Okta URL as the issuer (from Dynamic)
  3. Specify your Policies and Rules to allow (at a minimum) your GCP OIDC Client to use this authorization server
  4. 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

  1. Within the GCP Console, browse to IAM and Workforce Identity Federation
  2. Create a new Identity Pool given a name and description, as well as specifying the default lifetime for authenticated identities in this pool
  3. Next, create a Provider associated with the pool – this will be the Okta Authorization Server you just finished creating
  4. The issuer should take the form of your Okta URL, appended with oauth2/<some Okta Id, e.g. ausjnol9oaLuUuclw697>
  5. Specify the Client Id and then Secret of the GCP OIDC App you created earlier
  6. Choose the Response Type as Code and the Assertion claims behavior as User Info and Id Token
  7. For the subject claim, you’ll want to use assertion.sub to extract the subject from the Okta token, you can choose another claim but that configuration is out of scope of this guide
  8. 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.

  1. Browse to IAM and Grant Access
  2. 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

  1. 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

    SGNL - Policies

  2. Select ‘Assign Policies’

  3. Select:

    • The Policies you want to apply to the integration with the check box
    • The version of the Policy you want applied

    SGNL - Select Policies

  4. Click Next once you have the Policies and Versions configured as is appropriate

  5. 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

    SGNL - Set Enforcement

  6. Select your desired Enforcement mode and select Assign

  7. Versions of Policies will now be Assigned to your integration

    SGNL - Policy Assignments

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

  1. Login to the Google Cloud Console with a user with permissions to manage Projects
  2. Use an existing Google Cloud project that does not already have an OAuth consent screen configured, or create a new project following this documentation
  3. From within the project, search for API & Services
  4. 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: Admin SDK API: .../auth/admin.directory.user.security
  1. 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
  1. Copy your Client Secret and Client ID and store it temporarily somewhere safe, then click Save
  2. From APIs & Services, search for “Admin SDK API” and click ‘Enable’, you should see the setting switch to enabled if successful

Configuring SGNL

  1. Log in to SGNL with the same user that you configured GCP with above
  2. From your Google Cloud Platform Protected System (with a type of at least Google-1.0.0), select Actions
  3. Specify the Address for the Action as https://admin.googleapis.com
  4. Select OAuth2 Authorization Code as the Authentication Method
  5. Paste in the Client ID and Client Secret from Step 6 of Configuring GCP above
  6. Specify your Scope as https://www.googleapis.com/auth/admin.directory.user.security
  7. Specify your Token URL as https://oauth2.googleapis.com/token
  8. Set the Auth Style as Auto Detect
  9. Set the Auth URL as https://accounts.google.com/o/oauth2/v2/auth?access_type=offline&prompt=consent
  10. 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:

  1. Select CAEP Hub from the SGNL nav
  2. Select Triggers
  3. 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
  1. 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 ‘Google Revoke Session’ Action
  1. Configure the required and optional fields
  • The userKey should be the target user in the API request.The value can be the user’s primary email address, alias email address, or unique user ID, e.g. {$.snowUser.email}
  1. 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.