One of the first places technical debt will surface is during onboarding. A well-designed Google Cloud landing zone is fundamental for running workloads in the cloud and will prevent technical debt as you scale your cloud infrastructure. The landing zone will provide a defined team interaction mode of X-as-a-Service to stream-aligned and platform teams.

Let's dive into the open-source repositories that create our Google Cloud Landing Zone Platform. While looking at these repositories, understand they are examples and a set of sensible default practices. These repositories can be forked and customized to fit your organization's needs. A landing zone at its core should minimally consist of a few coverage areas, resource hierarchy, identity groups, IAM roles, audit logging, and continuous delivery enablement. We believe in platform as a product, so the primary customers for this product would be other platform teams. Giving them the ability to onboard into the cloud and use continuous delivery to build their platforms. 

Google Cloud Resource Hierarchy

Metaphorically speaking, the Google Cloud resource hierarchy resembles the file system found in traditional operating systems to organize and manage entities hierarchically.

This open-source repository creates a resource hierarchy that aligns with the business unit-oriented hierarchy. This hierarchy makes it easy to delegate IAM roles and limit access so users in one department can only access resources within the corresponding folder.

Currently, we have the following services interfaces defined by the beta GitHub Issue Forms:

• google_cloud_identity_group service interface: GitHub Issue
• google_folder service interface: GitHub Issue

Google Cloud Audit Logging

In the effort to answer the questions of who did what, where, and when? We will configure centralized audit logging projects to sink audit logs. 

This open-source repository creates audit logging projects for each environment in our resource hierarchy, sandbox, non-production, and production. You will see that this repository uses a child module to define the project. The child module has the logic to determine whether to create a google_logging_project_bucket_config or to sink project-level audit logs to a logging bucket. The creation of the logging bucket could be pulled out of the child module in the spirit of simplicity if you prefer that, and the frequency we build logging projects would be rare, given there is a max of 200 sinks per project. You will frequently be developing child modules to fit you organizational needs and consume them in root modules like this one.

Google Cloud Workload Identity

Secrets management should be centralized and owned by a platform team. However, we prefer to avoid long-lived credentials in favor of authentication protocols like OpenID. Initially, we will enable workload identity federation for GitHub Actions as part of our landing zone's core coverage area, continuous delivery enablement.

This open-source repository creates a workload identity pool and provider for GitHub Actions that align with the documentation linked above.

Google Cloud Terraform Backend

With Google Cloud Storage and object versioning, we can manage Terraform state using the GCS backend. 

This open-source repository builds the Terraform backend for state management. Terraform uses persisted state data to keep track of the resources it manages. Most non-trivial Terraform configurations use a backend to store state remotely. This approach lets multiple people access the state data and work together on that collection of infrastructure resources. We also need service accounts GitHub Actions will use to create cloud resources and the IAM roles on the correct folders to keep the blast radius under control.

Networking

NOTE: Networking may not fit well under the landing zone platform, depending on scale this is most likely a platform itself.

This layer provides common networking resources like VPCs, VPNs, DNS, NATs, and more to platform teams. It's a lower-level layer and, in most cases, isn't geared toward stream-aligned teams. Terraform manages this open-source repository and provides a consistent experience for developers to consume common resources.

Providing several common services across an organization is key to enabling fast flow and removing low-level tasks for teams. Things like VPCs, VPNs, DNS, and NATs can take up a lot of development time when the cloud resources they want to use require them.

Terraform Testing Resources

Development of Terraform child modules will require existing testing infrastructure setup. This open-source repository creates a projects and other required resources for testing Terraform child modules.