58301c9eda
* Add ephemeral_storage_local_ssd_config support to modules/gke-nodepool Adds ephemeral_storage_local_ssd_count to node_config variable and the corresponding dynamic ephemeral_storage_local_ssd_config block in the node pool resource, enabling use of local SSDs as ephemeral storage. * feat(gke-nodepool): add flex_start support to node_config Add `flex_start` as an optional bool to the `node_config` variable type and wire it through to the `google_container_node_pool` resource's node_config block. This enables DWS (Dynamic Workload Scheduler) flex-start mode for node pools, used for on-demand capacity access without requiring ProvisioningRequest objects (e.g. spot TPU pools). * feat(gke-nodepool): add flex_start support to node_config Add `flex_start` as an optional bool to the `node_config` variable type and wire it through to the `google_container_node_pool` resource's node_config block. This enables DWS (Dynamic Workload Scheduler) flex-start mode for node pools, which allows the Cluster Autoscaler to request capacity on-demand without requiring ProvisioningRequest objects (unlike queued_provisioning). Typical use case is spot TPU node pools. * feat(gke-nodepool): add advanced_machine_features support to node_config Add `advanced_machine_features` as an optional object to the `node_config` variable type and wire it through to the `google_container_node_pool` resource via a dynamic block. This allows callers to configure `threads_per_core` (e.g. set to 1 to disable hyperthreading) and `enable_nested_virtualization` for node pools that require fine-grained CPU threading control or nested hypervisor support. GKE auto-sets `advanced_machine_features` (threads_per_core=1) on ct6e/TPU machine types; exposing this field also lets consumers add it to ignore_changes in their own lifecycle blocks to avoid forced replacements. * feat(gke-nodepool): add containerd_config support to node_config Add `containerd_config` as an optional object to the `node_config` variable and wire it through to the `google_container_node_pool` resource via a dynamic block. This allows callers to configure private registry mirrors or custom containerd registry hosts per node pool — useful for air-gapped environments and internal registry proxies. The `registry_hosts` list maps each upstream server to one or more mirror hosts, with optional `capabilities`, `override_path`, and `dial_timeout` fields (all defaulting to sensible values). * refactor(gke-nodepool): use maps for containerd_config registry_hosts and hosts Convert registry_hosts and hosts from lists to maps so that the registry server and host URLs serve as stable keys, avoiding index-shifting issues with for_each. Add default values for capabilities, override_path, and dial_timeout. Update README example and test inventory accordingly. * Remove default values from containerd_config hosts fields Leave capabilities, override_path, and dial_timeout without defaults so the provider/API picks them rather than the module imposing values. * Refine containerd_config variable interface - Simplify header to optional(map(list(string))) - Flatten ca, client cert/key to strings with descriptive names - Derive private_registry_access_config enabled from ca domain config list - Simplify writable_cgroups to optional(bool) - Flatten gcp_secret_manager_certificate_config to string - Remove redundant defaults where try() handles null in main.tf - Fix long lines in main.tf to stay within 79-char limit - Update copyright year to 2026 in inventory files * fix(gke-nodepool): run terraform fmt to fix attribute alignment in containerd_config * docs(gke-nodepool): regenerate README with updated variable line numbers * fix(gke-nodepool): use coalesce instead of try for null header map in for_each * tests(gke-nodepool): update containerd-config inventory to match actual plan output --------- Co-authored-by: Julio Castillo <jccb@google.com>
Terraform modules suite for Google Cloud
The modules collected in this folder are designed as a suite: they are meant to be composed together, and are designed to be forked and modified where use of third party code and sources is not allowed.
Modules try to stay close to the low level provider resources they encapsulate, and they all share a similar interface that combines management of one resource or set or resources, and the corresponding IAM bindings.
Authoritative IAM bindings are primarily used (e.g. google_storage_bucket_iam_binding for GCS buckets) so that each module is authoritative for specific roles on the resources it manages, and can neutralize or reconcile IAM changes made elsewhere.
Specific modules also offer support for non-authoritative bindings (e.g. google_storage_bucket_iam_member for service accounts), to allow granular permission management on resources that they don't manage directly.
These modules are not necessarily backward compatible. Changes breaking compatibility in modules are marked by major releases (but not all major releases contain breaking changes). Please be mindful when upgrading Fabric modules in existing Terraform setups, and always try to use versioned references in module sources so you can easily revert back to a previous version. Since the introduction of the moved block in Terraform we try to use it whenever possible to make updates non-breaking, but that does not cover all changes we might need to make.
These modules are used in the examples included in this repository. If you are using any of those examples in your own Terraform configuration, make sure that you are using the same version for all the modules, and switch module sources to GitHub format using references. The recommended approach to working with Fabric modules is the following:
-
Fork the repository and own the fork. This will allow you to:
- Evolve the existing modules.
- Create your own modules.
- Sync from the upstream repository to get all the updates.
-
Use GitHub sources with refs to reference the modules. See an example below:
module "project" { source = "github.com/GoogleCloudPlatform/cloud-foundation-fabric//modules/project?ref=v35.0.0&depth=1" name = "my-project" billing_account = "123456-123456-123456" parent = "organizations/123456" }
Foundational modules
- Billing account
- Cloud Identity group
- Folder
- Service accounts
- Logging bucket
- Organization
- Project
- Projects (data source)
Process factories
Networking modules
- Address reservation
- Cloud Endpoints
- DNS
- DNS Response Policy
- Firewall policy
- External Application Load Balancer
- External Passthrough Network Load Balancer
- External Regional Application Load Balancer
- Internal Application Load Balancer
- Cross-region Internal Application Load Balancer
- Internal Passthrough Network Load Balancer
- Internal Proxy Network Load Balancer
- NAT
- Service Directory
- VPC
- VPC firewall
- VPC peering
- VPN dynamic
- VPN HA
- VPN static
Compute/Container
- VM/VM group
- MIG
- COS container (coredns/mysql/nva/onprem/squid)
- GKE autopilot cluster
- GKE standard cluster
- GKE hub
- GKE nodepool
- GCVE private cloud
Data
- AlloyDB
- Analytics Hub
- BigQuery connection
- BigQuery dataset
- Bigtable instance
- Biglake catalog
- Cloud SQL instance
- Data Catalog Policy Tag
- Data Catalog Tag
- Data Catalog Tag Template
- Dataform Repository
- Datafusion
- Dataplex
- Dataplex Aspect Types
- Dataplex DataScan
- Dataproc
- Firestore
- GCS
- Looker Core
- Pub/Sub
- Spanner instance
AI
Development
- API Gateway
- Apigee
- Artifact Registry
- Cloud Build V2 Connection
- Container Registry
- Cloud Source Repository
- Cloud Deploy
- Secure Source Manager instance
- Workstation cluster
Security
- Binauthz
- Certificate Authority Service (CAS)
- KMS
- SecretManager
- VPC Service Control
- Secure Web Proxy
- Certificate Manager