on
26-Apr-2023
08:59
- edited on
26-Apr-2023
09:17
by
Rebecca_Moloney
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.
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.
To begin your journey, you'll need to address the following minimum requirements:
gcloud organizations list
This command lists all of the organization resources to which you belong, and their corresponding resource IDs.
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.
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.
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”).
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
}
Here’s an example JSON value:
{
"resources": ["organizations/123456789", "organizations/1011121314"],
"options": "strict"
}
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
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.
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.