SSL Orchestrator Advanced Use Cases: Enabling GCloud Organization Restrictions

Introduction

Back in SSL Orchestrator Advanced Use Cases: Fun with SaaS Tenant Isolation, I walked through a use case, enabled through SSL Orchestrator 10.1, to support SaaS tenant restrictions. As a quick recap, think of a tenant restriction as a way to isolate a tenant (i.e., a set of enterprise accounts) for a SaaS platform. This is super useful for SaaS resources where your enterprise users will have corporate access to the SaaS platform, but may also have their own personal accounts, or accounts with another corporate entity. A tenant restriction essentially prevents users from accessing any SaaS accounts other than those specifically allowed. Most important, a tenant restriction is a really good way to prevent some forms of data exfiltration - i.e., by preventing users from saving proprietary information to a personal or other non-sanctioned account.

This article extends on the above fundamental idea to include Google Cloud (GCloud) Organization Restrictions, and describes how to deploy F5 BIG-IP SSL Orchestrator to support egress proxy organization restrictions. Working together with Google Cloud administrators, a BIG-IP SSL Orchestrator administrator can easily configure decrypted inspection and egress proxy organization restrictions for Google Cloud services.

Why F5?

F5 BIG-IP provides various services to help you enhance the security, availability, and performance of your apps. These services include L7 load balancing, network firewalling, web application firewalling (WAF), and DNS services. BIG-IP SSL Orchestrator on BIG-IP provides protection against encrypted malware and enables dynamic, policy-based traffic steering to an optimized security inspection stack.

Before you begin

To begin your journey, you'll need to address the following minimum requirements:

• Access to a BIG-IP instance (version 17.0 and higher) and BIG-IP SSL Orchestrator (version 10.1 and higher).
• If the Google Cloud administrator and BIG-IP administrator roles are different in your organization, ensure that the Google Cloud administrator engages with the BIG-IP administrator to provide necessary organization information.
• BIG-IP SSL Orchestrator can be configured as a transparent gateway for outbound traffic or as an explicit HTTP forward proxy. If the former is required, configure your organization firewall rules or configure the managed devices to ensure that the outbound traffic from all users in your organization pass through BIG-IP. If the latter is required, configure the endpoint user agents, manually, through administrative scripts, and/or proxy PAC configurations to ensure that user agents communicate with the BIG-IP SSL Orchestrator HTTP proxy to access remote resources.
• Get the organization ID. A Google Cloud administrator must provide the organization ID, which can be found by running the following command:

gcloud organizations list

This command lists all of the organization resources to which you belong, and their corresponding resource IDs.

Configuring BIG-IP SSL Orchestrator to enable GCloud organization restrictions

BIG-IP SSL Orchestrator is configured as an egress proxy through the creation of outbound traffic “topologies.” These are described in detail in the BIG-IP SSL Orchestrator deployment guide. Client traffic to remote sites passes through a topology, is decrypted for inspection, and re-encrypted. During the decrypted inspection phase, additional third-party security tools can also be injected into the traffic flow to enable dynamic defense-in-depth protection against malware and other exploits. Also, during this phase, BIG-IP SSL Orchestrator injects the Google Cloud organization restrictions headers when the client attempts to access a specific Google resource.

Step 1: Create the SSL Orchestrator tenant restrictions service

Within the BIG-IP SSL Orchestrator topology configuration, an “Office 365 Tenant Restrictions” security service is available on the F5 tab of the Service Properties page, which enables the creation of SaaS tenant isolation controls. Out of the box, it creates the headers and access contexts for Microsoft Office 365 but is easily modified to support any SaaS product. We will do just this to configure Google Cloud organization restrictions. On the F5 tab in the BIG-IP SSL Orchestrator UI “Security Services” section, click on the “Office 365 Tenant Restrictions” tile and click the Add button.

• Name: The name is arbitrary, but it may be useful to rename it to something like “GCOR.”
• Restrict Access to Tenant: This is specific to Office 365. Enter any string of text here.
• Restrict Access Context: This is also specific to Office 365. Enter any string of text here.
• iRules: The service creation will create an iRule, so nothing is required here. It does, however, provide an option to enable additional programmable logic on the decrypted traffic flow.

Click Save & Next and add this new service to a service chain. As described in more detail in the BIG-IP SSL Orchestrator deployment guide, the service chain is attached to a security policy that enables TLS intercept (decryption) for outbound traffic flows. The headers will only be injected for specific Google Cloud requests. Once deployed, navigate through the BIG-IP UI to Local Traffic -> iRules and on that page, click the corresponding iRule to edit (it will be the one with the service label you just created and ending with “-f5-tenant-restrictions”).

Step 2: Define the header

The Google Cloud organization restriction header is made up of a header name (X-Goog-Allowed-Resources) and a base64-encoded JSON header value. The header value has the following JSON structure:

{
 "resources": [string…],
 "options": string
}

• "resources": A list of strings. Each string in this list must refer to a Google Cloud organization ID. Organization IDs in this list are considered authorized organizations during evaluation.
• "options": A string that contains one of the following values:
• "strict": Enforces the organization restrictions header for all request types to the supported Google Cloud services.
• "cloudStorageReadAllowed": Allows read requests to Cloud Storage but enforces organization restrictions header for all request types to the supported Google Cloud services. This option allows access for the following Cloud Storage read operations:
• storage.objects.get
• storage.objects.list
• storage.objects.getIamPolicy
• storage.buckets.get
• storage.buckets.list
• storage.buckets.getIamPolicy

Here’s an example JSON value:

{
 "resources": ["organizations/123456789", "organizations/1011121314"],
 "options": "strict"
}

Step 3: Encode the header

Encode the organization IDs in web-safe base64 format. The encoding must follow the RFC 4648 Section 5 specifications. For example, if the above JSON representation for the header values is stored in a file named “authorized_orgs.json”, to encode the file with the base64 command line tool use:

cat authorized_orgs.json | base64

Here’s an example header after encoding the organization ID:

X-Goog-Allowed-Resources: ewogInJlc291cmNlcyI6IFsib3JnYW5pemF0aW9ucy8xMjM0NTY3ODkiLCAib3JnYW5pemF0aW9ucy8xMDExMTIxMzE0Il0sCiAib3B0aW9ucyI6ICJzdHJpY3QiCn0K

Step 4: Add the header to the BIG-IP SSL Orchestrator iRule

Back in the BIG-IP iRule editor, replace the existing Office 365 tenant restrictions code with the following. Replace the “…base64-encoded JSON value…” in the curly braces with your own encoded JSON value.

when HTTP_REQUEST {
    switch -glob [string tolower [HTTP::host]] {
        "*.google.com" -
        "*.googleapis.com" -
        "*.gcr.io" -
        "*.pkg.dev" -
        "*.cloudfunctions.net" -
        "*.run.app" -
        "*.tunnel.cloudproxy.app" -
        "*.datafusion.googleusercontent.com" {
            HTTP::header replace "X-Goog-Allowed-Resources" {…base64-encoded JSON value…}
        }
    }
}

The iRule, when injected into the decrypted egress traffic flow, will look for any of the provided URLs, and if matching, insert the X-Goog-Allowed-Resources header into the request to enable the organization restrictions. 

Summary

With an iRule and just a few configuration changes we have been able to implement a capability on top of SSL Orchestrator to extend the built-in Office 365 Tenant Restrictions service to support a set of additional SaaS applications. This flexibility is just one of the many interesting benefits of and SSL Orchestrator solution.