{"id":13398348,"url":"https://github.com/terraform-google-modules/terraform-example-foundation","last_synced_at":"2025-05-15T02:09:00.770Z","repository":{"id":37048204,"uuid":"225491284","full_name":"terraform-google-modules/terraform-example-foundation","owner":"terraform-google-modules","description":"Shows how the CFT modules can be composed to build a secure cloud foundation","archived":false,"fork":false,"pushed_at":"2025-05-14T17:09:39.000Z","size":3322,"stargazers_count":1323,"open_issues_count":25,"forks_count":737,"subscribers_count":51,"default_branch":"main","last_synced_at":"2025-05-14T18:25:42.391Z","etag":null,"topics":["cft-terraform","end-to-end","operations"],"latest_commit_sha":null,"homepage":"https://cloud.google.com/architecture/security-foundations","language":"HCL","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/terraform-google-modules.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":"CODEOWNERS","security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2019-12-02T23:54:32.000Z","updated_at":"2025-05-13T23:14:52.000Z","dependencies_parsed_at":"2023-12-25T23:29:11.967Z","dependency_job_id":"a9aa6a9d-06be-4949-9e76-fdfdf7331dc2","html_url":"https://github.com/terraform-google-modules/terraform-example-foundation","commit_stats":{"total_commits":439,"total_committers":64,"mean_commits":6.859375,"dds":0.7995444191343963,"last_synced_commit":"8b7e50f853ca64906468833fda1f7ee9508317f6"},"previous_names":[],"tags_count":14,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/terraform-google-modules%2Fterraform-example-foundation","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/terraform-google-modules%2Fterraform-example-foundation/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/terraform-google-modules%2Fterraform-example-foundation/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/terraform-google-modules%2Fterraform-example-foundation/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/terraform-google-modules","download_url":"https://codeload.github.com/terraform-google-modules/terraform-example-foundation/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":254259384,"owners_count":22040820,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["cft-terraform","end-to-end","operations"],"created_at":"2024-07-30T19:00:23.395Z","updated_at":"2025-05-15T02:09:00.634Z","avatar_url":"https://github.com/terraform-google-modules.png","language":"HCL","funding_links":[],"categories":["Tools","HCL","Reference Guides / Frameworks / Docs"],"sub_categories":[],"readme":"# terraform-example-foundation\n\nThis example repository shows how the CFT Terraform modules can build a secure Google Cloud foundation, following the [Google Cloud Enterprise Foundations Blueprint](https://cloud.google.com/architecture/security-foundations) (previously called the _Security Foundations Guide_).\nThe supplied structure and code is intended to form a starting point for building your own foundation with pragmatic defaults that you can customize to meet your own requirements.\n\nThe intended audience of this blueprint is large enterprise organizations with a dedicated platform team responsible for deploying and maintaining their GCP environment, who is commited to separation of duties across multiple teams and managing their environment solely through version-controlled Infrastructure as Code. Smaller organizations looking for a turnkey solution might prefer other options such as [Google Cloud Setup](https://console.cloud.google.com/cloud-setup/overview)\n\n## Intended usage and support\n\nThis repository is intended as an example to be forked, tweaked, and maintained in the user's own version-control system; the modules within this repository are not intended for use as remote references.\nThough this blueprint can help accelerate your foundation design and build, we assume that you have the engineering skills and teams to deploy and customize your own foundation based on your own requirements.\n\nWe will support:\n - Code is semantically valid, pinned to known good versions, and passes terraform validate and lint checks\n - All PR to this repo must pass integration tests to deploy all resources into a test environment before being merged\n - Feature requests about ease of use of the code, or feature requests that generally apply to all users, are welcome\n\nWe will not support:\n - In-place upgrades from a foundation deployed with an earlier version to a more recent version, even for minor version changes, might not be feasible. Repository maintainers do not have visibility to what resources a user deploys on top of their foundation or how the foundation was customized in deployment, so we make no guarantee about avoiding breaking changes.\n - Feature requests that are specific to a single user's requirement and not representative of general best practices\n\n## Overview\n\nThis repo contains several distinct Terraform projects, each within their own directory that must be applied separately, but in sequence.\nStage `0-bootstrap` is manually executed, and subsequent stages are executed using your preferred CI/CD tool.\n\nEach of these Terraform projects are to be layered on top of each other, and run in the following order.\n\n### [0. bootstrap](./0-bootstrap/)\n\nThis stage executes the [CFT Bootstrap module](https://github.com/terraform-google-modules/terraform-google-bootstrap) which bootstraps an existing Google Cloud organization, creating all the required Google Cloud resources and permissions to start using the Cloud Foundation Toolkit (CFT).\nFor [CI/CD Pipelines](/docs/GLOSSARY.md#foundation-cicd-pipeline), you can use either Cloud Build (by default) or Jenkins. If you want to use Jenkins instead of Cloud Build, see [README-Jenkins](./0-bootstrap/README-Jenkins.md) on how to use the Jenkins sub-module.\n\nThe bootstrap step includes:\n\n- The `prj-b-seed` project that contains the following:\n  - Terraform state bucket\n  - Custom service accounts used by Terraform to create new resources in Google Cloud\n- The `prj-b-cicd` project that contains the following:\n  - A [CI/CD Pipeline](/docs/GLOSSARY.md#foundation-cicd-pipeline) implemented with either Cloud Build or Jenkins\n  - If using Cloud Build, the following items:\n    - Cloud Source Repository\n    - Artifact Registry\n  - If using Jenkins, the following items:\n    - A Compute Engine instance configured as a Jenkins Agent\n    - Custom service account to run Compute Engine instances for Jenkins Agents\n    - VPN connection with on-prem (or wherever your Jenkins Controller is located)\n\nIt is a best practice to separate concerns by having two projects here: one for the Terraform state and one for the CI/CD tool.\n  - The `prj-b-seed` project stores Terraform state and has the service accounts that can create or modify infrastructure.\n  - The `prj-b-cicd` project holds the CI/CD tool (either Cloud Build or Jenkins) that coordinates the infrastructure deployment.\n\nTo further separate the concerns at the IAM level as well, a distinct service account is created for each stage. The Terraform custom service accounts are granted the IAM permissions required to build the foundation.\nIf using Cloud Build as the CI/CD tool, these service accounts are used directly in the pipeline to execute the pipeline steps (`plan` or `apply`).\nIn this configuration, the baseline permissions of the CI/CD tool are unchanged.\n\nIf using Jenkins as the CI/CD tool, the service account of the Jenkins Agent (`sa-jenkins-agent-gce@prj-b-cicd-xxxx.iam.gserviceaccount.com`) is granted [impersonation](https://cloud.google.com/iam/docs/create-short-lived-credentials-direct) access so it can generate tokens over the Terraform custom Service Accounts.\nIn this configuration, the baseline permissions of the CI/CD tool are limited.\n\nAfter executing this step, you will have the following structure:\n\n```\nexample-organization/\n└── fldr-bootstrap\n    ├── prj-b-cicd\n    └── prj-b-seed\n```\n\nWhen this step uses the Cloud Build submodule, it sets up the cicd project (`prj-b-cicd`) with Cloud Build and Cloud Source Repositories for each of the stages below.\nTriggers are configured to run a `terraform plan` for any non-environment branch and `terraform apply` when changes are merged to an environment branch (`development`, `nonproduction` or `production`).\nUsage instructions are available in the 0-bootstrap [README](./0-bootstrap/README.md).\n\n### [1. org](./1-org/)\n\nThe purpose of this stage is to set up the common folder used to house projects that contain shared resources such as Security Command Center notification, Cloud Key Management Service (KMS), org level secrets, and org level logging.\nThis stage also sets up the network folder used to house network related projects such as DNS Hub, Interconnect, network hub and projects for each environment  (`development`, `nonproduction` or `production`).\nThis will create the following folder and project structure:\n\n```\nexample-organization\n└── fldr-common\n    ├── prj-c-logging\n    ├── prj-c-billing-export\n    ├── prj-c-scc\n    ├── prj-c-kms\n    └── prj-c-secrets\n└── fldr-network\n    ├── prj-net-hub-svpc\n    ├── prj-net-dns\n    ├── prj-net-interconnect\n    ├── prj-d-svpc\n    ├── prj-n-svpc\n    └── prj-p-svpc\n```\n\n#### Logs\n\nUnder the common folder, a project `prj-c-logging` is used as the destination for organization wide sinks. This includes admin activity audit logs from all projects in your organization and the billing account.\n\nLogs are collected into a logging bucket with a linked BigQuery dataset, which can be used for ad-hoc log investigations, querying, or reporting. Log sinks can also be configured to export to Pub/Sub for exporting to external systems or Cloud Storage for long-term storage.\n\n**Notes**:\n\n- Log export to Cloud Storage bucket has optional object versioning support via `log_export_storage_versioning`.\n- The various audit log types being captured in BigQuery are retained for 30 days.\n- For billing data, a BigQuery dataset is created with permissions attached, however you will need to configure a billing export [manually](https://cloud.google.com/billing/docs/how-to/export-data-bigquery), as there is no easy way to automate this at the moment.\n\n#### Security Command Center notification\n\nAnother project created under the common folder. This project will host the Security Command Center notification resources at the organization level.\nThis project will contain a Pub/Sub topic, a Pub/Sub subscription, and a [Security Command Center notification](https://cloud.google.com/security-command-center/docs/how-to-notifications) configured to send all new findings to the created topic.\nYou can adjust the filter when deploying this step.\n\n#### KMS\n\nAnother project created under the common folder. This project is allocated for [Cloud Key Management](https://cloud.google.com/security-key-management) for KMS resources shared by the organization.\n\nUsage instructions are available for the org step in the [README](./1-org/README.md).\n\n#### Secrets\n\nAnother project created under the common folder. This project is allocated for [Secret Manager](https://cloud.google.com/secret-manager) for secrets shared by the organization.\n\nUsage instructions are available for the org step in the [README](./1-org/README.md).\n\n#### DNS hub\n\nThis project is created under the network folder. This project will host the DNS hub for the organization.\n\n#### Interconnect\n\nAnother project created under the network folder. This project will host the Dedicated Interconnect [Interconnect connection](https://cloud.google.com/network-connectivity/docs/interconnect/concepts/terminology#elements) for the organization. In case of Partner Interconnect, this project is unused and the [VLAN attachments](https://cloud.google.com/network-connectivity/docs/interconnect/concepts/terminology#for-partner-interconnect) will be placed directly into the corresponding hub projects.\n\n#### Networking\n\nUnder the network folder, one project for shared vpc network, are created per environment (`development`, `nonproduction`, and `production`) which is intended to be used as a [Shared VPC host project](https://cloud.google.com/vpc/docs/shared-vpc) for all projects in that environment.\nThis stage only creates the projects and enables the correct APIs, the following networks stages, [3-networks-svpc](./3-networks-svpc/) and [3-networks-hub-and-spoke](./3-networks-hub-and-spoke/), create the actual Shared VPC networks.\n\n### [2. environments](./2-environments/)\n\nThe purpose of this stage is to set up the environments folders that contain shared projects for each environemnt.\nThis will create the following folder and project structure:\n\n```\nexample-organization\n└── fldr-development\n    ├── prj-d-kms\n    └── prj-d-secrets\n└── fldr-nonproduction\n    ├── prj-n-kms\n    └── prj-n-secrets\n└── fldr-production\n    ├── prj-p-kms\n    └── prj-p-secrets\n```\n\n#### KMS\n\nUnder the environment folder, a project is created per environment (`development`, `nonproduction`, and `production`), which is intended to be used by [Cloud Key Management](https://cloud.google.com/security-key-management) for KMS resources shared by the environment.\n\nUsage instructions are available for the environments step in the [README](./2-environments/README.md).\n\n#### Secrets\n\nUnder the environment folder, a project is created per environment (`development`, `nonproduction`, and `production`), which is intended to be used by [Secret Manager](https://cloud.google.com/secret-manager) for secrets shared by the environment.\n\nUsage instructions are available for the environments step in the [README](./2-environments/README.md).\n\n### [3. networks-svpc](./3-networks-svpc/)\n\nThis step focuses on creating a [Shared VPC](https://cloud.google.com/architecture/security-foundations/networking#vpcsharedvpc-id7-1-shared-vpc-) per environment (`development`, `nonproduction`, and `production`) in a standard configuration with a reasonable security baseline. Currently, this includes:\n\n- (Optional) Example subnets for `development`, `nonproduction`, and `production` inclusive of secondary ranges for those that want to use Google Kubernetes Engine.\n- Hierarchical firewall policy created to allow remote access to [VMs through IAP](https://cloud.google.com/iap/docs/using-tcp-forwarding), without needing public IPs.\n- Hierarchical firewall policy created to allow for [load balancing health checks](https://cloud.google.com/load-balancing/docs/health-checks#firewall_rules).\n- Hierarchical firewall policy created to allow [Windows KMS activation](https://cloud.google.com/compute/docs/instances/windows/creating-managing-windows-instances#kms-server).\n- [Private service networking](https://cloud.google.com/vpc/docs/configure-private-services-access) configured to enable workload dependant resources like Cloud SQL.\n- Shared VPC with [restricted.googleapis.com](https://cloud.google.com/vpc-service-controls/docs/supported-products) configured for restricted access to googleapis.com and gcr.io. Route added for VIP so no internet access is required to access APIs.\n- Default routes to internet removed, with tag based route `egress-internet` required on VMs in order to reach the internet.\n- (Optional) Cloud NAT configured for all subnets with logging and static outbound IPs.\n- Default Cloud DNS policy applied, with DNS logging and [inbound query forwarding](https://cloud.google.com/dns/docs/overview#dns-server-policy-in) turned on.\n\nUsage instructions are available for the networks step in the [README](./3-networks-svpc/README.md).\n\n### [3. networks-hub-and-spoke](./3-networks-hub-and-spoke/)\n\nThis step configures the same network resources that the step 3-networks-svpc does, but this time it makes use of the architecture based on the [hub-and-spoke](https://cloud.google.com/architecture/security-foundations/networking#hub-and-spoke) reference network model.\n\nUsage instructions are available for the networks step in the [README](./3-networks-hub-and-spoke/README.md).\n\n### [4. projects](./4-projects/)\n\nThis step is focused on creating service projects with a standard configuration that are attached to the Shared VPC created in the previous step and application infrastructure pipelines.\nRunning this code as-is should generate a structure as shown below:\n\n```\nexample-organization/\n└── fldr-development\n    └── fldr-development-bu1\n        ├── prj-d-bu1-sample-floating\n        ├── prj-d-bu1-sample-svpc\n        ├── prj-d-bu1-sample-peering\n    └── fldr-development-bu2\n        ├── prj-d-bu2-sample-floating\n        ├── prj-d-bu2-sample-svpc\n        └── prj-d-bu2-sample-peering\n└── fldr-nonproduction\n    └── fldr-nonproduction-bu1\n        ├── prj-n-bu1-sample-floating\n        ├── prj-n-bu1-sample-svpc\n        ├── prj-n-bu1-sample-peering\n    └── fldr-nonproduction-bu2\n        ├── prj-n-bu2-sample-floating\n        ├── prj-n-bu2-sample-svpc\n        └── prj-n-bu2-sample-peering\n└── fldr-production\n    └── fldr-production-bu1\n        ├── prj-p-bu1-sample-floating\n        ├── prj-p-bu1-sample-svpc\n        ├── prj-p-bu1-sample-peering\n    └── fldr-production-bu2\n        ├── prj-p-bu2-sample-floating\n        ├── prj-p-bu2-sample-svpc\n        └── prj-p-bu2-sample-peering\n└── fldr-common\n    ├── prj-c-bu1-infra-pipeline\n    └── prj-c-bu2-infra-pipeline\n```\n\nThe code in this step includes two options for creating projects.\nThe first is the standard projects module which creates a project per environment, and the second creates a standalone project for one environment.\nIf relevant for your use case, there are also two optional submodules which can be used to create a subnet per project, and a dedicated private DNS zone per project.\n\nUsage instructions are available for the projects step in the [README](./4-projects/README.md).\n\n### [5. app-infra](./5-app-infra/)\n\nThe purpose of this step is to deploy a simple [Compute Engine](https://cloud.google.com/compute/) instance in one of the business unit projects using the infra pipeline set up in 4-projects.\n\nUsage instructions are available for the app-infra step in the [README](./5-app-infra/README.md).\n\n### Final view\n\nAfter all steps above have been executed, your Google Cloud organization should represent the structure shown below, with projects being the lowest nodes in the tree.\n\n```\nexample-organization\n└── fldr-common\n    ├── prj-c-logging\n    ├── prj-c-billing-export\n    ├── prj-c-scc\n    ├── prj-c-kms\n    ├── prj-c-secrets\n    ├── prj-c-bu1-infra-pipeline\n    └── prj-c-bu2-infra-pipeline\n└── fldr-network\n    ├── prj-net-hub-svpc\n    ├── prj-net-dns\n    ├── prj-net-interconnect\n    ├── prj-d-svpc\n    ├── prj-n-svpc\n    └── prj-p-svpc\n└── fldr-development\n    ├── prj-d-kms\n    └── prj-d-secrets\n    └── fldr-development-bu1\n        ├── prj-d-bu1-sample-floating\n        ├── prj-d-bu1-sample-svpc\n        ├── prj-d-bu1-sample-peering\n    └── fldr-development-bu2\n        ├── prj-d-bu2-sample-floating\n        ├── prj-d-bu2-sample-svpc\n        └── prj-d-bu2-sample-peering\n└── fldr-nonproduction\n    ├── prj-n-kms\n    └── prj-n-secrets\n    └── fldr-nonproduction-bu1\n        ├── prj-n-bu1-sample-floating\n        ├── prj-n-bu1-sample-svpc\n        ├── prj-n-bu1-sample-peering\n    └── fldr-nonproduction-bu2\n        ├── prj-n-bu2-sample-floating\n        ├── prj-n-bu2-sample-svpc\n        └── prj-n-bu2-sample-peering\n└── fldr-production\n    ├── prj-p-kms\n    └── prj-p-secrets\n    └── fldr-production-bu1\n        ├── prj-p-bu1-sample-floating\n        ├── prj-p-bu1-sample-svpc\n        ├── prj-p-bu1-sample-peering\n    └── fldr-production-bu2\n        ├── prj-p-bu2-sample-floating\n        ├── prj-p-bu2-sample-svpc\n        └── prj-p-bu2-sample-peering\n└── fldr-bootstrap\n    ├── prj-b-cicd\n    └── prj-b-seed\n```\n\n### Branching strategy\n\nThere are three main named branches: `development`, `nonproduction`, and `production` that reflect the corresponding environments. These branches should be [protected](https://docs.github.com/en/github/administering-a-repository/about-protected-branches). When the [CI/CD Pipeline](/docs/GLOSSARY.md#foundation-cicd-pipeline) (Jenkins or Cloud Build) runs on a particular named branch (say for instance `development`), only the corresponding environment (`development`) is applied. An exception is the `shared` environment, which is only applied when triggered on the `production` branch. This is because any changes in the `shared` environment may affect resources in other environments and can have adverse effects if not validated correctly.\n\nDevelopment happens on feature and bug fix branches (which can be named `feature/new-foo`, `bugfix/fix-bar`, etc.) and when complete, a [pull request (PR)](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests) or [merge request (MR)](https://docs.gitlab.com/ee/user/project/merge_requests/) can be opened targeting the `development` branch. This will trigger the [CI/CD Pipeline](/docs/GLOSSARY.md#foundation-cicd-pipeline) to perform a plan and validate against all environments (`development`, `nonproduction`, `shared`, and `production`). After the code review is complete and changes are validated, this branch can be merged into `development`. This will trigger a [CI/CD Pipeline](/docs/GLOSSARY.md#foundation-cicd-pipeline) that applies the latest changes in the `development` branch on the `development` environment.\n\nAfter validated in `development`, changes can be promoted to `nonproduction` by opening a PR or MR targeting the `nonproduction` branch and merging them. Similarly, changes can be promoted from `nonproduction` to `production`.\n\n### Policy validation\n\nThis repo uses the [terraform-tools](https://cloud.google.com/docs/terraform/policy-validation/validate-policies) component of the `gcloud` CLI to validate the Terraform plans against a [library of Google Cloud policies](https://github.com/GoogleCloudPlatform/policy-library).\n\nThe [Scorecard bundle](https://github.com/GoogleCloudPlatform/policy-library/blob/master/docs/bundles/scorecard-v1.md) was used to create the [policy-library folder](./policy-library) with [one extra constraint](https://github.com/GoogleCloudPlatform/policy-library/blob/master/samples/serviceusage_allow_basic_apis.yaml) added.\n\nSee the [policy-library documentation](https://github.com/GoogleCloudPlatform/policy-library/blob/master/docs/index.md) if you need to add more constraints from the [samples folder](https://github.com/GoogleCloudPlatform/policy-library/tree/master/samples) in your configuration based in your type of workload.\n\nStep 1-org has [instructions](./1-org/README.md#deploying-with-cloud-build) on the creation of the shared repository to host these policies.\n\n### Optional Variables\n\nSome variables used to deploy the steps have default values, check those **before deployment** to ensure they match your requirements. For more information, there are tables of inputs and outputs for the Terraform modules, each with a detailed description of their variables. Look for variables marked as **not required** in the section **Inputs** of these READMEs:\n\n- Step 0-bootstrap: If you are using Cloud Build in the [CI/CD Pipeline](/docs/GLOSSARY.md#foundation-cicd-pipeline), check the main [README](./0-bootstrap/README.md#Inputs) of the step. If you are using Jenkins, check the [README](./0-bootstrap/modules/jenkins-agent/README.md#Inputs) of the module `jenkins-agent`.\n- Step 1-org: The [README](./1-org/envs/shared/README.md#Inputs) of the environment `shared`.\n- Step 2-environments: The READMEs of the environments [development](./2-environments/envs/development/README.md#Inputs), [nonproduction](./2-environments/envs/nonproduction/README.md#Inputs), and [production](./2-environments/envs/production/README.md#Inputs)\n- Step 3-networks-svpc: The READMEs of the environments [shared](./3-networks-svpc/envs/shared/README.md#inputs), [development](./3-networks-svpc/envs/development/README.md#Inputs), [nonproduction](./3-networks/envs/nonproduction/README.md#Inputs), and [production](./3-networks/envs/production/README.md#Inputs)\n- Step 3-networks-hub-and-spoke: The READMEs of the environments [shared](./3-networks-hub-and-spoke/envs/shared/README.md#inputs), [development](./3-networks-hub-and-spoke/envs/development/README.md#Inputs), [nonproduction](./3-networks/envs/nonproduction/README.md#Inputs), and [production](./3-networks/envs/production/README.md#Inputs)\n- Step 4-projects: The READMEs of the environments [shared](./4-projects/business_unit_1/shared/README.md#inputs), [development](./4-projects/business_unit_1/development/README.md#Inputs), [nonproduction](./4-projects/business_unit_1/nonproduction/README.md#Inputs), and [production](./4-projects/business_unit_1/production/README.md#Inputs)\n\n## Errata summary\n\nRefer to the [errata summary](./ERRATA.md) for an overview of the delta between the example foundation repository and the [Google Cloud security foundations guide](https://cloud.google.com/architecture/security-foundations).\n\n## Contributing\n\nRefer to the [contribution guidelines](./CONTRIBUTING.md) for information on contributing to this module.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fterraform-google-modules%2Fterraform-example-foundation","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fterraform-google-modules%2Fterraform-example-foundation","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fterraform-google-modules%2Fterraform-example-foundation/lists"}