https://github.com/emma-ola/terraform-platform-modules
Production-grade Terraform modules for building foundational GCP platform infrastructure. This repository provides opinionated yet flexible modules for core platform primitives such as networking, security, and shared cloud services, designed for reuse across teams and environments.
https://github.com/emma-ola/terraform-platform-modules
cloud-platform gcp google-cloud infrastructure-as-code terraform terraform-modules
Last synced: about 1 month ago
JSON representation
Production-grade Terraform modules for building foundational GCP platform infrastructure. This repository provides opinionated yet flexible modules for core platform primitives such as networking, security, and shared cloud services, designed for reuse across teams and environments.
- Host: GitHub
- URL: https://github.com/emma-ola/terraform-platform-modules
- Owner: emma-ola
- License: other
- Created: 2025-12-31T21:27:05.000Z (5 months ago)
- Default Branch: main
- Last Pushed: 2026-01-17T17:23:14.000Z (5 months ago)
- Last Synced: 2026-01-17T20:51:13.105Z (5 months ago)
- Topics: cloud-platform, gcp, google-cloud, infrastructure-as-code, terraform, terraform-modules
- Language: HCL
- Homepage:
- Size: 76.2 KB
- Stars: 0
- Watchers: 0
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- Changelog: CHANGELOG.md
- License: LICENSE
Awesome Lists containing this project
README
# Terraform Platform Modules (GCP)
Opinionated, reusable Terraform modules to provision **secure and consistent**
Google Cloud infrastructure.
Designed to reduce duplication, prevent configuration drift, and enable safe
upgrades via versioned releases.
---
## Modules
- **network**
- VPC creation
- Multi-region subnets with optional secondary ranges
- Firewall rules with validation and guardrails
- Cloud NAT with scoped subnet and IP-range support
- Routes and VPC Flow Logs
- **gke**
- Private GKE clusters
- Data-driven node pools
- Secure node defaults (COS, Shielded VMs, metadata hardening)
- Workload Identity enabled by default
---
## Philosophy
- Secure-by-default
- Minimal, well-validated inputs
- Clear separation of concerns (project → network → GKE)
- Versioned releases (teams pin module versions)
- CI guardrails (formatting, validation, linting, security scanning)
---
## Security & Guardrails
This repository is designed as a **production-grade Terraform platform**, not a
collection of ad-hoc modules. Security is enforced primarily through opinionated
defaults and module-level guarantees rather than relying on callers.
### Built-in security controls
- **GKE hardening**
- Private clusters by default
- Legacy metadata endpoints disabled on all nodes
- Workload Metadata configured (`GKE_METADATA`)
- Shielded nodes enabled (Secure Boot + Integrity Monitoring)
- Container-Optimized OS (`COS_CONTAINERD`) enforced for node images
- Network Policy support enabled at the cluster level
- **Network security**
- VPC Flow Logs supported and configurable per subnet
- Firewall rules validated to prevent conflicting or unsafe configurations
- Cloud NAT configurable with scoped subnet and IP-range selection
- **Platform standards**
- Baseline resource labels enforced at the module level
- Caller-supplied labels merged with platform defaults
- Guardrails implemented using Terraform preconditions
### Automated security scanning
- **Static analysis:** `tflint`
- **Security scanning:** `tfsec` with SARIF upload to GitHub Security
- Security findings are:
- Addressed through secure defaults where applicable, or
- Explicitly suppressed with documented justification
#### Suppressed tfsec rule
- **google-gke-enforce-pod-security-policy**
**Reason:**
PodSecurityPolicy (PSP) is deprecated and removed in modern Kubernetes and GKE.
Pod security is enforced via **Pod Security Admission (PSA)** and/or **Policy
Controller (Gatekeeper)** as a platform concern rather than legacy PSP.
All other security findings remain enabled and enforced.
---
## Usage
See `examples/dev` and `examples/gke-dev` for a reference implementation demonstrating composition of
the project, network, and GKE modules.
---
## Development
Common tasks are standardized using a Makefile.
```bash
make fmt # format Terraform files
make fmt-check # check formatting
make validate # validate Terraform configuration
make ci # run all CI checks locally
make help # show all available commands
```
---
## Maintenance Windows & Exclusions
The GKE module supports **maintenance policies** to control when Google may perform cluster and node upgrades.
Maintenance behavior is defined using:
- A **recurring maintenance window** (when upgrades are allowed)
- Optional **maintenance exclusions** (blackout periods when upgrades are blocked)
---
### Recurring maintenance window
A recurring maintenance window defines **when upgrades may occur**.
```hcl
maintenance = {
recurring_window = {
start_time = "2026-01-01T00:00:00Z"
end_time = "2026-01-01T06:00:00Z"
recurrence = "FREQ=WEEKLY;BYDAY=SA,SU"
}
}
```
**Behavior:**
- GKE may perform upgrades every **Saturday and Sunday**
- Only between **00:00–06:00 UTC**
- Outside this window, upgrades are deferred
This configuration provides 12 hours per week, which safely satisfies
GKE’s 48-hour / 32-day maintenance requirement.
**This applies to:**
- Control plane upgrades
- Node pool upgrades (when `auto_upgrade = true`)
- Routine cluster maintenance
---
### Maintenance exclusions (blackout periods)
Maintenance exclusions define periods where **no upgrades are allowed**, even if they overlap with a recurring maintenance window.
```hcl
maintenance = {
exclusions = {
black_friday = {
start_time = "2026-11-27T00:00:00Z"
end_time = "2026-11-30T23:59:59Z"
scope = "NO_UPGRADES"
}
}
}
```
**Behavior:**
- No upgrades will occur during the exclusion window
- Exclusions **always take precedence** over recurring windows
- Deferred upgrades resume during the next valid maintenance window
---
### How windows and exclusions interact
- **Recurring windows** define when upgrades are allowed
- **Exclusions** define when upgrades are forbidden
- If both apply at the same time, **exclusions win**
---
### Timezone considerations
All maintenance times must be specified in **UTC**.
For reference, 00:00–06:00 UTC corresponds to:
- **7pm–1am ET** during standard time (EST)
- **8pm–2am ET** during daylight time (EDT)
Always convert local maintenance windows to UTC before configuring