Multi-Tenant Google Cloud Platform B2B SaaS Applications How-to

Isolation

Overview

This article addresses the isolation challenges described in the Concepts article.

To recap, Google Cloud Platform provides a number of isolation boundaries including projects, and now folders and organizations, in addition to ACL and network-based controls.

The documentation provides a good overview of ACL, project, folder and organization policy.

In this article we’ll focus on scalable project-based isolation, the relationship between organizations and domains, as well as on network based controls, and their implications for multi-tenant SaaS applications.

The way in which you choose to allocate your application and data services to projects and/or domains will depend on sovereignty and latency constraints in addition to the isolation constraints described here.

Projects

Projects are the original Google Cloud Platform isolation boundary; this is the same boundary Google uses for customers who aren’t associated with an organization.

We recommend using this boundary if it addresses your customers’ perceived security concerns, and you don’t need to support multiple SAML IDPs (see the Authentication and Authorization article), since it supports useful joint venture and data sharing constructs such as VPC Service Control security zones (see below).

One of the natural concerns with project-based isolation is project proliferation. Tenancy Units can help address mitigate this concern.

Tenancy Units

Tenancy units provides per-service, per-consumer isolated environments. When a new customer starts using your service, you can create all resources specific to that customer in a single tenancy unit.

Rather than build a natively multi-tenant managed service, you can create a separate instance of a single-tenant application inside a tenancy unit for each customer. Doing this, you’ve created a “multi-single-tenant” service: a service that is multi-tenant from the consumers’ perspective, but actually implemented as separate single-tenant applications.

This is most applicable to applications which either isolate data by customer, or isolate application infrastructure per user (ie. not full multi-tenant PaaS services built on App Engine or Google Kubernetes Engine).

Organizations and Domains

First, a bit of terminology: organization != organization.

• The Cloud Platform Organization resource represents an organization (for example, a company) and is the root node in the GCP resource hierarchy and IAM policy. It is associated with a Cloud Identity domain, which represents a virtual group of all Google accounts in an organization, and exposes domain-based policy and security controls such as SAML SSO and Admin Console Groups.
• Cloud Identity domains also include a resource called Organization (ignore the legacy G Suite branding; this applies to Cloud Identity as well); this is used to organize users and apply different sorts of policy to them: which Google products can they access (eg. G Suite, YouTube, Cloud Console), and who can administer them (eg. their password administrator).

We’ll focus primarily on Cloud Platform Organization resources and their associated Cloud Identity domains. From a Google Cloud Platform Organization policy perspective, sub-domains are equivalent to domains; however that is not the case from a Cloud Identity administration perspective.

The fact that Cloud Identity domains are the basis for user management and SAML SSO has a number of implications if you’re providing your customer with end-user management capabilities:

• Domains represent a very powerful isolation boundary: this is the same boundary Google uses for its enterprise customers. They’re also a boundary your customers are familiar with; while groups, folders and projects are also isolation boundaries, they require more explanation.
• You’ll need to allocate a separate domain or sub-domain for each IDP with which you wish to enable SAML SSO federation. As discussed in the Authentication and Authorization article, this constraint can be mitigated through the use of a SAML proxy.

There are a number of factors to consider in making the choice of multiple vs. single customer domain, in addition to the SAML federation implications discussed above.

Identity representation

The mapping between customer users and identities on domains allocated per customer are intuitive (eg. userid@customerdomain.mydomain.com).

In the case of a single domain representing all customers, you’ll need to include the customer information in the identity (eg. userid_customerdomain@mydomain.com). This is particularly problematic if you wish to expose some of GCP’s managed services directly to your customers’ end users, eg. upload files to Google Cloud Storage, run analytics on BigQuery without SAML federation.

Administrative scope

Google Cloud Platform administrative scope is managed through IAM roles; however, Google Cloud Identity default administrative scope is based on the domain, or in the case of Multiple Domain Support (ignore the legacy G Suite branding; this applies to Cloud Identity as well), on the account. You can define administrative roles which scope to an organizational unit (ie. set of users) within the domain, as well as to particular services (eg. manage passwords)(ignore the legacy G Suite branding; this applies to Cloud Identity as well).

Super-admins (ignore the legacy G Suite branding; this applies to Cloud Identity as well) have full scope across all users and Cloud Identity administrative services (eg. password reset, domain-wide delegation of authority). This can be a good reason to isolate customers by domain or sub-domain and not to implement Multiple Domain Support.

Scaling

Individual domains or sub-domains per customer naturally raise the question of manageability; there are a couple of mechanisms which can assist here:

• You can associate them all with a single account, and manage them from the same Google Admin console via Multiple Domain Support (ignore the legacy G Suite branding; this applies to Cloud Identity as well). This simplifies billing and administration, but comes with some constraints: if you’re implementing SAML federation, the domains must all share the same SAML IDP; the same administrators are responsible for all domains, ie. you can’t separate administrative scope by customer; user isolation is diminished since all domains share a single user directory (though this can be partitioned by sub-organization).
• The Admin SDK (ignore the legacy G Suite branding; this applies to Cloud Identity as well) provides the ability to create new customer subscriptions (eg. customerdomain.mydomain.com). Use of this API requires that you be enabled as Google reseller.

Billing

You can either allocate at least one Google Cloud Platform billing id per domain/organization, or share billing ids across domains/organizations. There are, as always, pros and cons to each approach.

• At least one Google Cloud Platform billing id per customer domain/organization: this simplifies pass-through billing and mitigates the billing short-coming of domain-wide delegation of authority. It also results in billing id proliferation.
• Google Cloud Platform billing ids shared across domains/organizations: this minimizes billing id proliferation, but has implementation complexities since a billing id belongs to the organization on which it is first created, so while you can’t directly link it to multiple orgs, you can use it for projects within a different org by linking it with the user within that org who creates the projects. Configuring this is sufficiently complex to be outside the scope of this article, and to indicate that either project-based isolation or Multiple Domain Support (see above) may be more appropriate choices.

Network-based Controls

VPC Service Controls

As we’d discussed in the Authentication and Authorization article, domain-wide delegation of authority poses data exfiltration challenges.

VPC Service Controls (in private beta) enable you to define a network-based security perimeter around Google Cloud Platform resources such as Cloud Storage buckets to constrain data within a Virtual Private Cloud (VPC) and help mitigate data exfiltration risks.

Your customers can put resources in secure zones and establish IP-based restrictions on access so their internal confidential information isn’t shared with your application.

Similarly, you can use VPC service controls to establish data isolation boundaries between multiple tenant projects, if you’ve chosen projects as as your customer isolation boundary. You can selectively enable sharing between VPC zones, for instance in the case of a joint venture.

There is a key caveat: VPC Service Controls are fail-open rather than fail-closed, so data which isn’t explicitly in a VPC security zone will be available across VPC boundaries. Robust governance processes and automation can help mitigate this risk.

What’s next

Determine which choices best match your use cases and start prototyping.

Try out the APIs in the API Explorer.

Read

• Managing Multiple Organizations to learn how to maintain sub-organizations or departments within your company as isolated entities with no central administration.
• Google Cloud Platform Cross Org Billing to learn how to use the same billing account across multiple GCP organizations.
• Share Data with Confidence: Cell-level Access Controls in BigQuery and Data Studio to learn about an approach to managing access controls, not only at the document level, but for individual results.

Acknowledgements

Many thanks to:

• Sam Srinivas for the identity representation ideas, and for broad support with multi-tenancy.
• Samrat Ray for helping me understand the nuances of VPC Service Controls.
• Rob Kochman for helping me wrap my head around Tenancy Units.