Struggling to automate OpenShift Dedicated on GCP with pure Infrastructure as Code? We break down the real-world challenges and provide three practical solutions, from quick CLI scripts to robust Terraform strategies.

The IaC Holy Grail: Can You *Actually* Automate OpenShift Dedicated on GCP?

I remember the moment vividly. It was 2 AM, and a PagerDuty alert screamed about a catastrophic failure in our primary region. The disaster recovery plan was clear: spin up a new OpenShift Dedicated cluster in our secondary GCP region, `gcp-us-west1`. “Just run the Terraform,” the runbook said with a confidence I certainly didn’t feel. The problem? Our “IaC” for OSD was a house of cards—a messy collection of shell scripts calling the CLI, with a few manual steps in the OCM UI that “someone always remembers to do.” We got it done, but it was a frantic, error-prone scramble. That night, I swore we’d find a better, truly automated way.

So, Why Is This So Hard?

If you’ve tried to do this, you’ve felt the pain. You reach for the Google Terraform Provider, search for a resource like google_openshift_dedicated_cluster, and come up empty. Why? Because you aren’t really buying an OpenShift cluster *from* Google. You’re buying a managed service *from Red Hat* that runs *on* Google Cloud infrastructure.

The entire lifecycle of the cluster—creation, scaling, upgrading—is managed by Red Hat’s OpenShift Cluster Manager (OCM) control plane. OCM then makes API calls to GCP on your behalf to provision the underlying VMs, VPCs, and IAM roles. This means your IaC tool needs to talk to the OCM API, not the GCP API, to manage the cluster resource itself. This abstraction is the root of all the confusion.

The Solutions: From Duct Tape to Dedicated Pipelines

After that painful night, my team and I dug in and found there are a few ways to tackle this. None are perfect, but they range from “good enough for now” to “the way it should be.”

Solution 1: The ‘Get It Done’ CLI Wrapper

Let’s be honest: sometimes you just need to get the cluster built. The fastest, most direct way is to wrap the official Red Hat CLI tool (rosa) in a shell script. It’s not pure, declarative IaC, but it’s repeatable and a hell of a lot better than clicking around in a UI.

This approach is imperative—you’re telling it *how* to do something, step by step. It’s great for a V1 of your automation, but it can be brittle and doesn’t handle state management or drift detection.

#!/bin/bash
# A simple script to provision an OSD cluster on GCP
# NOTE: Assumes you've already run 'rosa login'

CLUSTER_NAME="prod-cluster-west1"
REGION="us-west1"
GCP_PROJECT_ID="techresolve-prod-12345"

echo "Creating OSD cluster on GCP..."

rosa create cluster --cluster-name=${CLUSTER_NAME} \
  --sts \
  --hosted-cp \
  --cloud-provider=gcp \
  --gcp-project-id=${GCP_PROJECT_ID} \
  --region=${REGION} \
  --compute-nodes=3 \
  -y

# You would add more steps here for creating IDPs, etc.
echo "Cluster creation initiated for ${CLUSTER_NAME}."

Warning: This is a fire-and-forget script. It has no concept of the cluster’s current state. If you run it again, it will fail. You’ll need to write separate scripts for updates and deletion, which is where this approach starts to fall apart.

Solution 2: The ‘Proper IaC’ Terraform Approach

This is the goal. For a truly declarative approach, you need to use the official Red Hat Cloud Services Terraform Provider. This provider is designed to talk directly to the OCM API, allowing you to define your cluster, identity providers, and machine pools as Terraform resources.

This is the way to go for any serious production setup. You get state management, planning, and the ability to integrate cluster creation into a larger Terraform run that also sets up GCP VPCs, DNS, and IAM roles.

terraform {
  required_providers {
    rhcs = {
      source  = "terraform-redhat/rhcs"
      version = "1.5.0"
    }
  }
}

provider "rhcs" {
  # Best to use an environment variable for the token:
  # export OCM_TOKEN="your_offline_token_here"
}

resource "rhcs_cluster_rosa_classic" "osd_gcp_prod" {
  name           = "prod-cluster-east1"
  cloud_region   = "us-east1"
  cloud_provider = "gcp"
  sts            = true
  
  gcp {
    project_id = "techresolve-prod-54321"
  }

  properties = {
    rosa_creator_arn = "arn:aws:iam::123456789012:user/Darian.Vance" # Still uses AWS ARN for creator identity
  }
}

Pro Tip: The `rhcs` provider authenticates using an OCM API token. Don’t hardcode this in your files! Generate an “Offline Token” from the Red Hat Hybrid Cloud Console and set it as an environment variable (OCM_TOKEN) in your CI/CD system.

Solution 3: The ‘Cloud Native’ Crossplane Method

If you’re already deep in the Kubernetes ecosystem and want to provide “Cluster-as-a-Service” to your internal teams, this is the power move. Crossplane allows you to build your own custom Kubernetes APIs. You can use the official `provider-jet-rhcs` to wrap the Terraform provider and create a custom `CompositeResourceDefinition` (XRD) called something like `CompositeOpenShiftCluster`.

Your developers can then request a new OSD cluster by applying a simple YAML manifest to a management Kubernetes cluster, just like they would a `Deployment` or `Service`.

# This is a 'claim' a developer would submit.
# The underlying Crossplane composition would translate this
# into the rhcs_cluster_rosa_classic resource from Solution 2.

apiVersion: techresolve.io/v1alpha1
kind: OpenShiftCluster
metadata:
  name: marketing-campaign-cluster
  namespace: team-marketing
spec:
  parameters:
    region: us-central1
    nodeCount: 3
  compositionSelector:
    matchLabels:
      provider: gcp
      type: dedicated
  writeConnectionSecretToRef:
    name: marketing-cluster-conn
    namespace: team-marketing

This is the most complex solution to set up, but it provides the ultimate abstraction and self-service experience.

Comparison at a Glance

Ultimately, there’s no single “right” answer, only the right answer for your team’s maturity and needs. We started with the CLI wrapper out of necessity after that 2 AM incident. Today, all our clusters are managed via the Terraform provider in a CI/CD pipeline. It wasn’t an overnight fix, but it means I can finally sleep through the night, even when things go wrong.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions