Organization (Stage 1)

Repository: gcp-foundations-org

Purpose

The organization stage establishes org-wide governance: top-level folder structure, shared infrastructure projects, organization policies, centralized logging, Security Command Center (SCC) notifications, essential contacts, and resource tags. It reads bootstrap outputs for common configuration and creates the foundation upon which environments and networks are built.

Resources Created

Top-Level Folders

Folder	Purpose
fldr-common	Shared infrastructure projects (logging, KMS, secrets, etc.)
fldr-network	Network host projects (DNS hub, interconnect, shared VPCs)
fldr-pci-dss	PCI-DSS compliant workloads (excluded from restrictive org policies)

note

Environment folders (fldr-development, fldr-non-production, fldr-production) are created in Stage 2 - Environments, not in this stage.

Shared Projects

Projects are created using terraform-google-modules/project-factory/google (~> 18.0) with random 4-character suffixes.

Common Folder Projects

Project	Folder	Key APIs	Purpose
prj-c-logging	fldr-common	Logging, BigQuery	Centralized audit log storage
prj-c-billing-logs	fldr-common	Logging, BigQuery	Billing data export and analysis
prj-c-kms	fldr-common	Cloud KMS	Organization-wide encryption keys
prj-c-secrets	fldr-common	Secret Manager	Organization-wide secrets
prj-c-artifact-registry	fldr-common	Artifact Registry, IAM Credentials	Shared container and package registry
prj-c-scc	fldr-common	Security Center, Pub/Sub, Cloud KMS	SCC notification routing

Network Folder Projects

Project	Folder	Key APIs	Purpose
prj-c-dns-hub	fldr-network	Compute, DNS, Service Networking	Central DNS resolution hub
prj-c-interconnect	fldr-network	Compute	Cloud Interconnect attachments

Per-Environment Network Host Projects

Created for each of the 4 environments (development, non-production, production, common):

Project Pattern	Purpose
prj-{env_code}-shared-base	Base Shared VPC host project
prj-{env_code}-shared-restricted	Restricted Shared VPC host project

This yields 8 network host projects total (2 per environment).

Organization Policies

All org policies are applied at the organization level (or parent folder) and exclude the PCI-DSS folder to allow flexibility for compliance-specific workloads.

Boolean Policies (Enforced)

Constraint	Category	Effect
compute.disableNestedVirtualization	Compute	Prevents nested virtualization on VMs
compute.disableSerialPortAccess	Compute	Blocks serial port access to VMs
compute.skipDefaultNetworkCreation	Compute	Prevents auto-creation of default VPC
compute.restrictXpnProjectLienRemoval	Compute	Protects Shared VPC host project liens
compute.disableVpcExternalIpv6	Compute	Blocks external IPv6 on VPCs
compute.setNewProjectDefaultToZonalDNSOnly	Compute	Forces zonal DNS for new projects
compute.requireOsLogin	Compute	Requires OS Login for SSH
sql.restrictPublicIp	Cloud SQL	Prevents public IPs on SQL instances
sql.restrictAuthorizedNetworks	Cloud SQL	Restricts SQL authorized networks
iam.disableServiceAccountKeyCreation	IAM	Blocks creation of SA keys
iam.automaticIamGrantsForDefaultServiceAccounts	IAM	Prevents auto-grants to default SAs
iam.disableServiceAccountKeyUpload	IAM	Blocks upload of external SA keys
storage.uniformBucketLevelAccess	Storage	Enforces uniform bucket-level access
storage.publicAccessPrevention	Storage	Prevents public access to buckets

List Policies

Constraint	Type	Value	Effect
compute.vmExternalIpAccess	Deny all	--	Blocks external IPs on all VMs
compute.restrictProtocolForwardingCreationForTypes	Allow	INTERNAL	Restricts protocol forwarding to internal only
essentialcontacts.allowedContactDomains	Allow list	Configured domains	Restricts essential contact domains
cloudbuild.allowedWorkerPools	Allow list	Private pool ID	Restricts Cloud Build to private worker pools

Domain-Restricted Sharing

Domain-restricted sharing is enforced via the domain_restricted_sharing sub-module, restricting IAM policy membership to configured domains only.

Access Context Manager

An Access Context Manager policy is created at the organization level to support VPC Service Controls in the networks stage:

resource "google_access_context_manager_access_policy" "access_policy" {
  parent = "organizations/${local.org_id}"
  title  = "default policy"
}

Centralized Logging Architecture

The logging architecture captures audit logs from the entire organization and routes them to three destinations in the logging project:

Log Filter

The following log types are captured:

• Cloud Audit Logs (activity, system_event, data_access, access_transparency, policy)
• VPC Flow Logs
• Firewall Logs
• DNS Query Logs

Log Destinations

Destination	Resource	Purpose
Cloud Storage	bkt-{project}-org-logs-{suffix}	Long-term archival with configurable retention
Pub/Sub	tp-org-logs-{suffix}	Real-time streaming to SIEM or other consumers
Log Bucket	logbkt-org-logs-{suffix}	Analytics-enabled with linked BigQuery dataset

Billing Logs

A separate BigQuery dataset (billing_data) in the billing-logs project stores billing export data for cost analysis.

SCC Notification Configuration

Security Command Center is configured to stream all active findings to a Pub/Sub topic:

Resource	Name	Purpose
Pub/Sub Topic	top-scc-notification	Receives SCC finding notifications
Pub/Sub Subscription	sub-scc-notification	Pull subscription for consumers
SCC Notification Config	configurable	Streams all active findings

The default SCC notification filter captures all active findings. This can be customized via the scc_notification_filter variable.

Tags and Tag Enforcement

Resource tags are used to identify environments and enforce policies. The tag system has been migrated to a dedicated tag-enforcement module that manages:

• Tag Key: environment (at organization level)
• Tag Values: bootstrap, production, non-production, development

Tag bindings are applied to:

• The bootstrap folder (environment: bootstrap)
• The common folder (environment: production)
• The network folder (environment: production)
• Each environment folder (via Stage 2)

Tags are also used by the networks stage to bind environment context to tenant subnets.

PCI-DSS Folder

The fldr-pci-dss folder is created specifically for workloads that require PCI-DSS compliance. It is excluded from all boolean and list org policies defined at the organization level, allowing:

• External IP addresses on VMs
• Service account key creation
• Public Cloud SQL instances
• Nested virtualization
• Non-uniform bucket access

This exemption is achieved by passing the PCI-DSS folder ID to the exclude_folders parameter of each org policy module.

Directory Structure

gcp-foundations-org/
+-- envs/
|   +-- shared/
|       +-- folders.tf          # Top-level folders (common, network, pci-dss)
|       +-- projects.tf         # All shared projects + per-env network projects
|       +-- org_policy.tf       # Organization policies
|       +-- org_policy_tags.tf  # Tag-based policy enforcement
|       +-- log_sinks.tf        # Centralized logging configuration
|       +-- scc_notification.tf # SCC notification setup
|       +-- tags.tf             # Tag key/value definitions
|       +-- iam.tf              # IAM bindings
|       +-- essential_contacts.tf
|       +-- cai_monitoring.tf   # Cloud Asset Inventory monitoring
|       +-- remote.tf           # Remote state data sources
|       +-- outputs.tf          # Outputs for downstream stages
|       +-- variables.tf
+-- modules/
    +-- centralized-logging/    # Log sink module
    +-- network/                # Per-env network project creation
    +-- cai-monitoring/         # Cloud Asset Inventory monitoring
    +-- tag-enforcement/        # Tag key/value management