Credential isolation between clients on a shared GCP foundation

Thu, 26 Feb 2026 09:00:00 -0500

This post is for cloud engineers building a GCP foundation with Terraform that will host workloads for more than one client. Isolation between clients comes from giving each client principals and trust domains that cannot overlap. Naming conventions and the secrecy of identifiers do not provide it. If two clients’ workloads can end up as the same IAM principal, IAM cannot tell them apart, and a role granted to one applies to both. Below is how I would lay out service accounts, keys and pools so they can’t overlap, and when you can relax.

Terraform State on GCS: Treat the Bucket as Foundation Infrastructure

Thu, 05 Feb 2026 09:00:00 -0500

This post is for cloud engineers building a GCP foundation with Terraform. You will get a short, opinionated setup for keeping state in Cloud Storage. My argument is that the state bucket is foundation infrastructure in its own right. Create it first, guard it like production, and choose its encryption knowing which choices are hard to undo. The backend "gcs" block itself is the easy part.

Why state leaves your laptop

By default, Terraform keeps state locally in a file named terraform.tfstate. Google’s tutorial on storing Terraform state in a Cloud Storage bucket points out that this makes team use difficult when several people run Terraform at the same time, because each machine has its own picture of the infrastructure. A foundation is shared by definition, with an org, folders, networking and IAM that many people depend on. For a foundation, remote state is required from the first apply.

Iam on RLGeeX

Credential isolation between clients on a shared GCP foundation

Terraform State on GCS: Treat the Bucket as Foundation Infrastructure

Why state leaves your laptop