Bootstrap in dependency order

The production root joins two kinds of resource: Google Cloud infrastructure and workloads installed through Kubernetes and Helm providers. The latter providers require a cluster endpoint and certificate authority that do not exist at the beginning. Bootstrap order follows that dependency, not the order in which the Terraform files appear.

Infrastructure dependencies determine order

Historical reproduction requires an owned environment and deliberate identity/source rebinding.

1. Configure owned billing/project/APIs and protected Terraform state before foundation resources.
2. Create networking and GKE before Kubernetes/Helm provider connections.
3. Establish image/metadata repositories, federated CI access and verifier registry read access.
4. Install/wire Kyverno, Argo CD and runtime components; then build, select and collect evidence.

Solid arrows indicate the stated handoff, not a claim of independent trust. Optional relationships are described in the text equivalent. Historical components are labeled in the caption.

1. Establish state ownership

The root uses an empty GCS backend block and expects the bucket and prefix at initialization. Create a dedicated, versioned bucket with uniform bucket-level access in your owned project. The bucket is not created by this root. Protect access and retention separately from workload lifecycle.

Prepare ignored local inputs from terraform.tfvars.example. Substitute owner-selected values, keep optional external alerting and legacy Ratify disabled, and review the complete configuration. Do not paste state, access tokens, a kubeconfig, or a webhook into Git or a public report.

2. Review the first foundation plan

The historical README documents a targeted first apply for required APIs, VPC, and GKE, followed by a full apply. The commands below prepare plans only. They still require credentials and can contact the live owned project; they are not part of safe offline inspection.

terraform -chdir=infrastructure/environments/prod init \
  -backend-config="bucket=YOUR_OWNED_STATE_BUCKET" \
  -backend-config="prefix=gcp-supply-chain-security/prod"
terraform -chdir=infrastructure/environments/prod plan \
  -target=google_project_service.required \
  -target=module.vpc \
  -target=module.gke

Review project, region, APIs, network ranges, endpoint exposure, node-pool size, and IAM grants before the separately authorized apply. Targeting intentionally omits resources; it is a bootstrap exception, not a routine deployment strategy. The full-root follow-up is necessary to reconcile what was omitted.

3. Reconcile the complete root

Once GKE exists, the providers can use module.gke.cluster_endpoint, its CA certificate, and the operator’s access token. A normal full plan should then cover the Artifact Registry repositories, GitHub federation, Kyverno reader identity, optional add-ons, Falco, and any explicitly enabled alerting resources. Review that plan and then perform the owned environment’s approved apply.

The root wires VPC → GKE → Kubernetes add-ons. The add-ons module contains optional metrics-server and ExternalDNS; it does not install Argo CD or Kyverno. Those admission and GitOps releases are separate operations. Avoid assuming that a successful Terraform apply has installed every security component depicted in the architecture.

4. Install the authority consumers deliberately

Read the cluster credentials command output before executing it; do not pipe an unreviewed Terraform output into a shell. Confirm that kubectl points to the intended project and cluster. Install reviewed Argo CD and Kyverno chart versions, adapt the verifier’s service-account annotation, and inspect registered webhooks. Use the checked-in config.maxContextSize: 8Mi as the historical setting, while checking the actual installed chart contract.

Build and verify a trusted artifact before enabling the application policy and reconciling the application. This separates a registry or identity configuration error from an expected admission denial. Apply the protected registry policy before allowing GitOps to create the application workload.

Checkpoint and failure boundary

The checkpoint is an owned cluster with inspected identities, a complete reviewed plan, and installed consumers whose scope matches the intended environment. A missing endpoint, unavailable API, or unaffordable plan is a reason to stop and diagnose, not to make the cluster broadly reachable or introduce long-lived credentials. Continue at wiring after the foundation is understood.

Source anchors

Bootstrap procedure, root dependency graph, and cluster-bound providers.