[Feature Request] Support regulated and non-regulated multi-tenancy within a single GCP Organization

オープン
  • 何か問題がありますか？
#388 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
google-cloud, terraform
領域
cloud, infrastructure, security

調査の方向性

Start by reading the 0-bootstrap, 1-resman, 2-networking-*, and 3-security stages, especially the organization-level setup and tenant configuration described in the issue. Determine how folder-scoped deployment or per-tenant compliance profiles could fit the existing stages. Done means regulated and non-regulated tenants can coexist in one Google Cloud Organization with compliance controls scoped to the regulated hierarchy.

索引モデルが issue の本文から書いたものです。

説明

Enhancement

Feature Description

Enable Stellar Engine (fast/stages-aw/*) to support isolated multi-tenancy across regulated and non-regulated environments within a single Google Cloud Organization, without requiring separate Google Cloud Organizations per compliance tier.

Use Case

Many public-sector, higher-education, and research institutions operate under a single centralized Google Cloud Organization (bound to one primary identity domain) while running both regulated and non-regulated workloads side by side:

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

Today, Stellar Engine 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 and Stage 2 compliance controls and network perimeter.
  • 3-security enforces uniform security constraints (such as gcp.restrictNonCmekServices and gcp.restrictCmekCryptoKeyProjects).

Because of this coupling, adopting Stellar Engine for an organization with both HIPAA/regulated and non-regulated workloads currently forces deploying two separate Google Cloud Organizations or bypassing Stellar Engine in favor of upstream Cloud Foundation Fabric (FAST).

Proposed Solution

Support mixed-compliance multi-tenancy within a single Google Cloud Organization via one 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, enabling one or more regulated Stellar Engine enclaves to coexist alongside non-regulated folders/FAST stages within 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—provisioning Assured Workloads folders (e.g., HIPAA, FedRAMP Moderate/High, IL4/IL5) and scoped Organization Policies, Shared VPCs, and CMEK enforcement only on regulated tenant hierarchies while allowing non-regulated tenant folders under the same Stage 0 administrative foundation.

Compliance & Deployment Context

  • Target Deployment Type(s):
    • US Region Restricted (e.g., Access Policy constraint)
    • FedRAMP Moderate
    • FedRAMP High
    • DoD IL4
    • DoD IL5
    • All / General (including mixed HIPAA / Assured Workloads + non-regulated multi-tenant organizations)
  • Relevant NIST 800-53r5 Controls: AC-3 (Access Enforcement), AC-4 (Information Flow Enforcement), AC-6 (Least Privilege), SC-7 (Boundary Protection), CM-2 (Baseline Configuration) — scoping strict enclave controls to regulated tenant boundaries without over-constraining non-regulated tenants in the same GCP Organization.

Reusability Check

Stellar Engine prioritizes reusability.

  • I have checked if this functionality can be achieved by extending an existing module or blueprint.
  • I have verified that this does not duplicate existing functionality.

Alternatives Considered

  1. Two separate Google Cloud Organizations: Standing up one Stellar Engine GCP Organization for regulated (e.g., HIPAA) workloads and a second GCP Organization for non-regulated workloads. This duplicates Cloud Identity/SSO federation, billing administration, and platform operations.
  2. Using upstream Cloud Foundation Fabric (FAST) directly: Deploying standard FAST at the organization root and manually creating Assured Workloads folders for regulated workloads. While this supports mixed-tenancy in one organization, adopters lose Stellar Engine's turnkey stages-aw compliance automation and pre-mapped NIST SP 800-53r5 ATO artifacts.

Additional Context

Supporting coexisting regulated and non-regulated tenants within a single Google Cloud Organization aligns Stellar Engine with upstream Cloud Foundation Fabric (FAST) architectural flexibility while preserving Stellar Engine's ATO acceleration for regulated enclaves.

主要言語
HCL
スター
61
フォーク
28
平均マージ
1日 22時間
マージ済み PR（30日）
72

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

google/stellar-engine のほかの issue

google/stellar-engine の issue をすべて見る

似ている issue

Cloud の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。