This sample creates an organizational layout with a single level, where each folder is usually mapped to one infrastructure environment (test, dev, etc.). It also sets up all prerequisites for automation (GCS state buckets, service accounts, etc.), and the correct roles on those to enforce separation of duties at the environment level.
This layout is well suited for medium-sized infrastructures managed by a small set of teams, where the complexity in application resource ownership and access roles is mostly dealt with at the project level, and/or in the individual services (GKE, Cloud SQL, etc.). Its simplicity also makes it a good starting point for more complex or specialized layouts.
Refer to the [section-level README](../README.md) for general considerations about this type of samples, and usage instructions.
## Managed resources and services
This sample creates several distinct groups of resources:
- one folder per environment
- one top-level project to hold Terraform-related resources
- one top-level project to set up and host centralized audit log exports (optional)
- one top-level shared services project
The number of resources in this sample is kept to a minimum so as to make it more generally applicable, further resources can be easily added by leveraging the full array of [Cloud Foundation Toolkit modules](https://github.com/terraform-google-modules), especially in the shared services project.
## Shared services project
This sample contains a single, top-level project used to host services shared across environments (eg GCS, GCR, KMS, Cloud Build, etc.). In our experience, that is enough for many customers, especially those using this organizational layout.
For more complex setups where multiple shared services projects are needed to encapsulate a larger number of resources, shared services should be treated as an extra environment so that they can be managed by a dedicated set of Terraform files, using a separate service account and GCS bucket, with a folder to contain shared projects.
If no shared services are needed, the shared service project module can of course be removed from `main.tf`.
| *generate_service_account_keys* | Generate and store service account keys in the state file. | <codetitle="">bool</code> | | <codetitle="">false</code> |
| *grant_xpn_folder_roles* | Grant roles needed for Shared VPC creation to service accounts at the environment folder level. | <codetitle="">bool</code> | | <codetitle="">true</code> |
| *grant_xpn_org_roles* | Grant roles needed for Shared VPC creation to service accounts at the organization level. | <codetitle="">bool</code> | | <codetitle="">false</code> |
| *project_services* | Service APIs enabled by default in new projects. | <codetitle="list(string)">list(string)</code> | | <codetitle="[ "resourceviews.googleapis.com", "stackdriver.googleapis.com", ]">...</code> |
| *shared_bindings_members* | List of comma-delimited IAM-format members for the additional shared project bindings. | <codetitle="list(string)">list(string)</code> | | <codetitle="">[]</code> |
| *shared_bindings_roles* | List of roles for additional shared project bindings. | <codetitle="list(string)">list(string)</code> | | <codetitle="">[]</code> |
| *terraform_owners* | Terraform project owners, in IAM format. | <codetitle="list(string)">list(string)</code> | | <codetitle="">[]</code> |