Your GKE Platform Is Not Finished When the Cluster Is Running

A Kubernetes cluster can be provisioned in less than an hour.

A usable application delivery platform usually takes much longer.

The difference is everything that must happen after the cluster exists:

• Developers need a repeatable way to onboard applications.
• Workloads need secure access to Google Cloud services.
• Infrastructure changes need controlled execution.
• Applications need consistent deployment patterns.
• Security policies need to be enforced automatically.
• Teams need a clear path from development to production.
• Platform operators need a reliable way to verify that everything is working.

This gap is why many Google Kubernetes Engine environments remain difficult to operate even when the underlying infrastructure appears healthy.

The cluster is running.

The platform is not.

The hidden work behind a GKE platform

A production GKE environment normally requires much more than a Terraform module for creating a cluster.

A complete foundation may include:

• GCP projects and folder placement
• VPCs, subnets and Cloud NAT
• Private GKE nodes
• Workload Identity Federation
• Artifact Registry
• GitHub Actions authentication through WIF
• Private self-hosted runners
• Config Sync
• Policy Controller
• Argo CD
• Internal Gateway infrastructure
• Private DNS
• TLS configuration
• Application namespaces
• resource quotas
• Pod security controls
• backup and recovery patterns
• platform verification

Each component is manageable independently.

The difficulty comes from integrating them into one repeatable delivery system.

A team may successfully provision GKE but still spend weeks answering questions such as:

• Where should application configuration live?
• Should Config Sync or Argo CD own a particular Kubernetes resource?
• How should GitHub Actions reach private clusters?
• How should applications authenticate to Google Cloud APIs?
• Who creates namespaces, service accounts and IAM bindings?
• How are policies applied consistently across environments?
• What happens when a team needs another environment?
• How do we prove that the platform is actually ready?

These are not isolated technical questions. They directly affect delivery speed, operational risk and engineering cost.

Why I started building Vertro

I built Vertro around a straightforward observation:

Most engineering teams do not need another collection of cloud modules. They need a standardized application delivery path.

Vertro is an opinionated Google Cloud and GKE platform implementation.

It is designed to help teams move from separately configured infrastructure components to a governed platform foundation that can support repeatable application onboarding.

The objective is not to hide Kubernetes or Google Cloud.

The objective is to remove unnecessary decisions from every new application.

Instead of asking each application team to design its own approach to identity, deployment, GitOps, policies and infrastructure, the platform establishes approved defaults.

A platform should make the correct path easier

Consider workload authentication.

A development team needs an application running in GKE to access Secret Manager or Cloud Storage.

Without a standard platform pattern, the team may:

1. create a Google Cloud service account;
2. generate a service account key;
3. store that key as a GitHub secret;
4. copy it into Kubernetes;
5. create a manual rotation process;
6. hope the key is eventually removed.

A platform-based approach uses Workload Identity Federation.

The application receives a Kubernetes service account. That identity is granted only the required Google Cloud permissions. No long-lived service account key is created.

The same principle applies across the delivery lifecycle:

• GitHub Actions authenticate through WIF.
• Infrastructure runs on private ARC runners.
• Kubernetes configuration is managed through Git.
• Policy Controller rejects non-compliant workloads.
• Argo CD manages application deployment.
• approved templates generate consistent starting points.

Security becomes part of the delivery system rather than a review performed after implementation.

What Vertro’s foundation currently includes

The Vertro base platform is structured around separate platform and application environments.

Each configured application environment receives its own GCP project and GKE cluster, while the underlying Terraform and Terragrunt modules remain shared.

The foundation includes:

Standardized GKE environments

• regional GKE clusters;
• private nodes;
• VPC-native networking;
• Dataplane V2;
• Workload Identity Federation;
• Shielded Nodes;
• Binary Authorization;
• Secret Manager CSI integration.

Controlled infrastructure execution

GitHub Actions workflows run on private Actions Runner Controller runners inside the platform GKE cluster.

The workflows authenticate to Google Cloud using Workload Identity Federation rather than stored service account keys.

GitOps with clear ownership

Config Sync manages platform-level Kubernetes configuration, including policies and cluster guardrails.

Argo CD manages Helm-based application deployment.

This separation avoids having multiple systems attempting to manage the same resources.

Enforced workload policies

Vertro uses Policy Controller and custom Gatekeeper policies to enforce requirements such as:

• no privileged containers;
• no host networking or host namespaces;
• CPU and memory requests and limits;
• read-only root filesystems;
• minimum replica counts;
• topology spread constraints;
• PodDisruptionBudgets.

These are hard controls, not documentation that application teams may or may not follow.

Internal application connectivity

Each application cluster includes a shared internal Gateway foundation, private DNS and standardized routing patterns.

Applications can attach HTTPRoutes to the shared Gateway instead of creating independent ingress infrastructure for every workload.

Repeatable environment creation

New environments are driven by configuration rather than copied Terraform roots.

The platform can scaffold the required Terragrunt configuration, Config Sync directory structure, GitHub environments and identity configuration from a small set of environment inputs.

The business outcome is consistency

The technical components matter, but the larger objective is consistency.

Without a platform, every new application creates another design exercise:

• a new repository structure;
• a new CI/CD approach;
• another IAM pattern;
• another Helm chart;
• another logging configuration;
• another security review;
• another set of operational assumptions.

That creates hidden engineering work.

It also makes future audits, upgrades and incident response more difficult because every application behaves differently.

A standardized platform reduces that variability.

Application teams receive a supported path.

Platform teams receive fewer one-off implementations.

Security teams receive controls that are enforced consistently.

Engineering leaders receive a delivery model that can scale beyond the knowledge of one or two senior engineers.

A successful Terraform apply is not enough

One of the lessons from building Vertro is that provisioning success does not prove platform readiness.

Terraform may complete while:

• Config Sync is unhealthy;
• Gatekeeper constraints are missing;
• an internal Gateway is not programmed;
• a required proxy-only subnet is absent;
• an ARC runner listener is unavailable;
• an Argo CD repository credential is incorrect;
• a workload policy is silently not evaluating dependent resources.

For that reason, Vertro includes post-bootstrap verification that checks the actual runtime state of the platform.

The goal is not merely:

Terraform returned exit code zero.

The goal is:

The platform is ready to onboard and operate applications.

Who Vertro is for

Vertro is intended for teams that:

• are standardizing application delivery on Google Cloud;
• use or plan to use GKE;
• have multiple applications or environments;
• want secure defaults without building an internal platform from scratch;
• need stronger consistency for compliance or audit readiness;
• lack the time or platform-engineering capacity to integrate every component themselves.

It is not intended to be a generic cloud-agnostic developer portal.

It is deliberately focused on Google Cloud, GKE and the operational patterns required to make them usable as a platform.

Where Vertro is heading

The base infrastructure is only one layer.

The broader Vertro platform is being designed to provide:

• guided application onboarding;
• Golden Path application templates;
• infrastructure provisioning workflows;
• standardized CI/CD;
• governed environment promotion;
• approval workflows;
• policy-aware application configuration;
• application lifecycle visibility.

The long-term objective is simple:

Make secure and repeatable application delivery the default path for teams using GKE.

Provisioning Kubernetes is no longer the difficult part.

Turning Kubernetes into a platform that teams can use consistently is where the real engineering begins.

If your organization is running GKE but every new application still requires weeks of coordination, custom infrastructure and security review, I would be interested in learning how your current onboarding process works.

Please visit https://vertro.io/ for more details

GoogleCloud #GKE #PlatformEngineering #DevSecOps #CloudSecurity #GitOps #Terraform #Kubernetes