Simplify onboarding for new teams consuming Kubernetes clusters

[brettcurtis]

Repositories are relatively small in scope in the current implementation, mainly as a grouping of cognitive abilities. For example, networking is a complex platform layer, as is Kubernetes. Kubernetes comprises many technologies, fleets, Istio, cert-manager, etc. In most cases, the platform developers working in the Kubernetes space cannot switch contexts across the two well.

The repositories also limit the blast radius of change and preserve tight access controls. For example, Terraform state (sensitive data), Google Cloud organizational groups, and IAM roles for all resources.

A trade-off to these decisions is creating multiple pull requests across multiple repositories that may or may not have dependencies on each other:

• github-organization-management
• google-cloud-hierarchy
  • Depends on Terraform backend service account
• google-cloud-terraform-backend
  • Depends on hierarchy
• google-cloud-kubernetes
  • Depends on GitHub
  • Create a Google Cloud project (only)
• google-cloud-networking
  • Depends on the Google Cloud project
• platform-google-cloud-kubernetes
  • Create cluster

We need to add gke service account to registry readers groups.

What can be done to simplify and improve this workflow? Please keep in mind that the consumption of this is the platform developers eating their dog food and not a workflow targeted at stream-aligned teams.

### Google Cloud Hierarchy
- [ ] https://github.com/osinfra-io/google-cloud-hierarchy/issues/167