Corpus

GitHub Actions:

📄 Repository Description

This repository contains the Infrastructure as Code (IaC) that shapes the Corpus domain — the embodied layer of the platform where order takes form. In the wider hierarchy of the Platform Team, Corpus serves as the stratum where the abstract principles of Logos are translated into tangible, reliable infrastructure.

Here, Google Cloud projects are called into being according to shared patterns; CIS-aligned safeguards establish the boundaries that keep chaos at bay; and Datadog observability forms the eyes of attention through which the system perceives and regulates itself.

The Corpus layer is where structure becomes real, where governance becomes flesh, and where the platform’s foundational energies are harnessed so teams can build, act, and create within a world made stable enough for meaningful work.

The infrastructure automates the creation of:

• Google Cloud Project with CIS compliance features, budget controls, and required APIs
• Datadog Integration with Cloud Security Posture Management (CSPM) and Security Command Center
• Team Infrastructure using the logos foundational platform for consistent labeling and governance
• GitHub Actions Integration with service accounts, workload identity, and state storage buckets
• KMS Encryption for secure state file encryption and key management
• Multi-environment Support with sandbox, non-production, and production configurations

This establishes team-specific infrastructure while maintaining consistency with organizational standards and foundational platform practices.

🏭 Platform Information

• Documentation: docs.osinfra.io
• Service Interfaces: github.com

Development

Our focus is on the core fundamental practice of platform engineering, Infrastructure as Code.

Open Source Infrastructure (as Code) is a development model for infrastructure that focuses on open collaboration and applying relative lessons learned from software development practices that organizations can use internally at scale. - Open Source Infrastructure (as Code)

To avoid slowing down stream-aligned teams, we want to open up the possibility for contributions. The Open Source Infrastructure (as Code) model allows team members external to the platform team to contribute with only a slight increase in cognitive load. This section is for developers who want to contribute to this repository, describing the tools used, the skills, and the knowledge required, along with OpenTofu documentation.

See the documentation for setting up a development environment.

🛠️ Tools

• pre-commit
• osinfra-pre-commit-hooks

📋 Skills and Knowledge

Links to documentation and other resources required to develop and iterate in this repository successfully.

• google cloud platform projects
• google cloud platform iam
• google cloud platform cis benchmarks
• datadog cloud security posture management
• datadog google cloud integration

Architecture

The infrastructure creates:

• Google Cloud Project with standardized naming, CIS compliance logging, budget controls, and required APIs
• Datadog Integration with Cloud Security Posture Management (CSPM) and Security Command Center integration
• Team Infrastructure leveraging logos foundational platform for consistent labeling, environment detection, and governance
• GitHub Actions Infrastructure including service accounts, workload identity pools, and secure authentication
• State Storage with encrypted GCS buckets and KMS keys for secure OpenTofu state management
• Access Controls with team-based service accounts and repository-specific workload identity bindings
• Multi-environment Support with configurations for sandbox, non-production, and production deployments

Interface

Environment-Specific Configurations

Environment configurations are stored in the environments/ directory:

• sandbox.tfvars - Sandbox environment configuration
• non-production.tfvars - Non-production environment configuration
• production.tfvars - Production environment configuration

Core Helpers Configuration

The helpers.tofu file configures the OpenTofu Core Helpers module which provides:

• Logos workspace integration - Fetches team infrastructure data from pt-logos foundational platform
• Environment detection - Automatically determines environment from workspace name
• Project naming - Generates standardized project names and descriptions
• Labeling - Provides consistent labels for cost tracking and governance
• Team data - Exposes team folder hierarchy, identity groups, and GitHub repositories

Optional Variables

All variables have defaults and are optional:

• datadog_enable - Enable Datadog integration (default: false)
• datadog_api_key - Datadog API key (required if datadog_enable = true)
• datadog_app_key - Datadog APP key (required if datadog_enable = true)
• google_customer_id - Google Workspace customer ID (default: "C01hd34v8")
• project_billing_account - The billing account ID (default: "01C550-A2C86B-B8F16B")
• project_monthly_budget_amount - Monthly budget in USD (default: 5)

State Configuration Variables

These variables are required for backend configuration and are provided by GitHub Actions workflows:

• state_bucket - The name of the GCS bucket to store state files
• state_kms_encryption_key - The KMS encryption key for state and plan files
• state_prefix - The prefix for state files in the GCS bucket

Outputs for Downstream Consumption

This infrastructure provides outputs designed for consumption by downstream repositories:

project_id

The Google Cloud project ID for use in downstream resource creation.

project_number

The Google Cloud project number for use in IAM bindings and other resources requiring the numeric project identifier.

service_accounts

GitHub Actions service accounts created for each team with repositories, including email addresses, names, and unique IDs for downstream authentication and access control.

storage_buckets

Encrypted GCS buckets created for OpenTofu state storage, with bucket names and URLs for each team's infrastructure automation.

teams

Complete team infrastructure information from the logos foundational platform including:

• Team metadata (display name, team type)
• Folder hierarchy (team type folder, team folder ID, environment folder IDs)
• Identity groups with email addresses, display names, descriptions, and roles

workload_identity_pools

Workload Identity Pools created for secure external authentication, providing pool names and IDs for GitHub Actions integration.

workload_identity_providers

Workload Identity Pool Providers configured for OIDC authentication with GitHub Actions, including provider names and IDs.

These outputs provide downstream repositories with comprehensive infrastructure information for consistent resource deployment, secure authentication, and access control management.## Module Dependencies

This configuration leverages the following infrastructure modules:

opentofu-google-project

Provides Google Cloud project creation with:

• CIS compliance logging and monitoring
• Budget controls and cost management
• Required API enablement
• Standardized project configuration

opentofu-datadog-google-integration

Provides Datadog integration with:

• Cloud Security Posture Management (CSPM)
• Security Command Center integration
• Automated monitoring setup
• Compliance and security visibility

opentofu-google-storage-bucket

Provides encrypted GCS bucket creation with:

• KMS encryption for state file security
• Standardized bucket configuration
• Consistent labeling and naming
• Multi-environment support

opentofu-core-helpers

Provides foundational platform capabilities:

• Logos workspace integration for team data
• Standardized labeling and tagging
• Environment detection and naming
• Cross-workspace data sharing

Validation Rules

Project Configuration

• Project must be deployed within appropriate folder hierarchy
• CIS logging sink project must be accessible
• Workload identity pool must exist and be accessible
• Budget amount must be positive number

Environment Consistency

• Environment configurations must align with logos foundational platform
• Team naming must follow organizational standards
• Resource labeling must be consistent across environments

GitHub Actions Integration

• Service accounts are created only for teams with configured repositories
• Workload identity pools enforce organization-specific restrictions
• Repository access is limited to configured GitHub repositories per team
• KMS encryption keys are shared across all team service accounts for cost efficiency