What is a community cloud?

A community cloud is defined by NIST SP 800-145 as:

• Cloud infrastructure [that] is provisioned for exclusive use by a specific community of consumers from organizations that have shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be owned, managed, and operated by one or more of the organizations in the community, a third party, or some combination of them, and it may exist on or off premises.

The approach has been used for decades and offers potential  benefits such as:

• Members of the community operate under the same set of security controls
• The ability to support attributes like citizenship and authorization controls while maintaining limited physical and/or logical access to resources.
• The ability to support data localization and some data sovereignty requirements based on the location of the community cloud’s data centers
• A clearly-defined perimeter security model encompassing the community cloud

Challenges with legacy community cloud implementations

The definition and objectives of community clouds are well-intentioned, but often the implementation of community clouds have failed to meet specific objectives or required significant tradeoffs for adopters.

Most community clouds to-date have relied on physical separation as the primary means of establishing a security perimeter. While this approach offers benefits in simplicity and segregation, there are downsides. A perimeter security model, also referred to as a “castle wall model” often doesn’t yield significant advances in security, manageability, or compliance. The shortcomings of a perimeter model as the primary mode of protection is acknowledged across the industry and has accelerated adoption of alternative approaches such as Zero Trust architectures. This is the case for compliance as well – in models that are tied to physical perimeters (e.g., legacy “Gov Clouds”) control assumptions at the perimeter can lead to control failures on the interior that lead to potentially serious security problems. Having created a physical community cloud in the past, Google sought a new way to provide the benefits above along with scalable and lasting compliance implementations.

Software-defined community cloud

Like virtualization for servers or software-defined networking for switching and routing hardware, a software-defined community cloud is designed to deliver the benefits of a community cloud in a more modern architecture. Google Cloud’s approach provides security and compliance assurances without the strict physical infrastructure constraints of legacy approaches.

Google Cloud’s approach for offering software-defined community clouds is implemented using a combination of technologies referred to in aggregate as “Assured Workloads.” With Assured Workloads, Google Cloud can:

• Define communities around shared mission, security and compliance requirements, and policy.
• Separate those community projects from other projects.
• Add or remove capabilities from a community’s boundary with policy-controlled and audited configuration changes.

This software-defined approach yields several potential benefits to customers. But first, let’s consider community cloud characteristics mapped to traditional and software-defined implementations:

Software defined community cloud as a new type of “Government Cloud”

In Google Cloud Platform (GCP), a project is an isolated, logical grouping of “infrastructure primitives.” In this context, an infrastructure primitive is any atomic unit of capacity in GCP – a virtual machine (VM), a persistent disk (PD), a storage bucket, etc. Projects are “global resources” that can be assigned infrastructure primitives from any region or zone.

Every project is, by default, isolated from other customers’ projects. Low-level resources like hypervisors, blocks in our distributed blockstore that underlies Google Cloud Storage (GCS), and other components are isolated with resource abstractions that enforce the isolation both logically and cryptographically.

A Private Cloud deployment model is described in NIST SP 800-145 as:

• Cloud infrastructure [that] is provisioned for exclusive use by a single organization comprising multiple consumers (e.g., business units). It may be owned, managed, and operated by the organization, a third party, or some combination of them, and it may exist on or off premises.

When a project is created within GCP, the infrastructure primitives that are assigned to that project are scoped to only that project. This scoping of infrastructure primitives effectively creates an “enclave” per Project.

When overlaid with Assured Workloads constraints for data residency, support personnel attributes, and security controls common to that community, these per-project private cloud enclaves become software-defined community clouds.

Benefits of a software-defined community cloud

The approach Google Cloud has taken brings multiple benefits in addition to meeting security and compliance requirements. New hardware, new services, and improvements to existing services can be made available faster than in traditional community clouds. The process by which new cloud technology can be onboarded and made available is also faster. Overall efficiency is improved in this model due to the scale of infrastructure available to the community; this can translate to improved availability and performance. Security enhancements can be scaled and implemented more quickly.

Moving forward

At Google Cloud, we continue to advance the capabilities that enable our customers to create and operate within software-defined community clouds. Learn more about the capabilities currently delivered through Assured Workloads here.