Skip to content

Feature Request: Support regulated and non-regulated multi-tenancy within a single GCP Organization #387

Open

Description

@johnlakeee

Summary

Enable Stellar Engine to support mixed-compliance multi-tenancy (regulated and non-regulated environments) within a single Google Cloud Organization, without requiring separate Google Cloud Organizations per compliance tier.

Problem Statement

Many public-sector, higher-education, and research institutions operate under a single centralized Google Cloud Organization (tied to one primary identity domain) while running two distinct classes of workloads side by side:

  1. Regulated workloads requiring Assured Workloads compliance boundaries and strict controls (for example, HIPAA, FedRAMP Moderate/High, or DoD IL4/IL5 enclaves with mandatory CMEK, regional restrictions, and dedicated Shared VPC inspection).
  2. Non-regulated workloads (for example, general academic research, open collaboration, or burst HPC/AI compute across multiple regions) where organization-wide Assured Workloads constraints, single-region lock-in, or mandatory CMEK create unnecessary operational friction and cost.

Today, Stellar Engine (fast/stages-aw/*) assumes a centralized, single-regime Organization deployment:

  • 0-bootstrap binds directly to the root organization (setIAM.sh, organization-level log_sinks, and org_policies_config) and configures a single global assured_workloads regime and location.
  • 1-resman provisions tenants that all inherit the same centralized Stage 0 / Stage 2 compliance controls and network perimeter.
  • 3-security enforces uniform security constraints (such as gcp.restrictNonCmekServices and gcp.restrictCmekCryptoKeyProjects).

As a result, organizations needing both regulated (e.g., HIPAA) and non-regulated tenants must currently either:

  • Stand up two separate Google Cloud Organizations (duplicating identity federation, billing setup, and two full Stellar Engine deployments), or
  • Bypass Stellar Engine in favor of upstream Cloud Foundation Fabric (FAST) and manually layer Assured Workloads folders on top.

Proposed Solution

Support isolated multi-tenancy across regulated and non-regulated boundaries within one Google Cloud Organization through either (or both) of the following patterns:

  1. Folder-Scoped (Sub-Org Enclave) Deployment Mode:
    • Allow 0-bootstrap and downstream stages (1-resman, 2-networking-*, 3-security) to target a designated parent Folder ID rather than requiring exclusive root Organization ownership, so one or more regulated Stellar Engine enclaves can coexist alongside non-regulated folders/stages in the same Organization.
  2. Per-Tenant / Per-Enclave Compliance Tiers in 1-resman, 2-networking, and 3-security:
    • Allow tenants (or tenant groups/folders) in 1-resman to specify distinct compliance profiles—e.g., provisioning Assured Workloads folders and scoped Organization Policies/Shared VPCs/CMEK only on regulated tenant folders while permitting standard non-regulated tenant folders under the same Stage 0 administrative foundation.

Additional Context

Supporting coexisting regulated and non-regulated tenants under a single Organization aligns Stellar Engine with upstream Cloud Foundation Fabric (FAST) flexibility while preserving Stellar Engine's compliance automation and NIST SP 800-53 control mappings for the regulated enclaves that require them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions