Azure Red Hat OpenShift

A client wanted to migrate their IBM messaging solution to Kubernetes, but IBM only officially supports it on OpenShift. Since they were already running everything else on Azure, ARO was the obvious choice.

The interesting part wasn't deploying ARO itself. It was integrating it into the existing GitOps platform built around AKS. ARO has some quirks that made this tricky. Certificate management works differently, the ingress controller behaves differently, and authentication integration required some creativity to get working properly.

This collection documents the patterns I landed on for running ARO alongside AKS clusters through a unified GitOps control plane. It covers the cluster configuration, security setup, identity integration, and the Terraform module I built to automate it all.

Cluster Configuration

Cluster Deployment
Set up the ARO cluster using my custom terraform module that implements best practices for networking, security, and identity integration.

Configure API server certificates
Replace the default self-signed API server certificate with your own trusted certificate. This is essential for production environments.

Modify Default Ingress
Configure custom TLS certificates for the default ingress controller.

Identity & Security

Configure Entra ID Integration
Integrate ARO with Azure Entra ID (formerly Azure AD) for authentication. This connects your cluster authentication to your existing identity provider, enabling SSO and centralized access management instead of managing cluster-specific credentials.

Modify CA Bundle
Add custom certificate authority certificates to the cluster's trusted CA bundle if you are using a custom CA for your internal services.

Update Kubeconfig with CA Certificate
Properly configure your local kubeconfig with custom CA certificates. After implementing custom certificates, this ensures your kubectl and other tools can authenticate without having to bypass certificate validation.

Networking

CIDR Planner
Plan your IP address ranges to avoid conflicts with your existing network infrastructure. This is critical to ensure proper routing and connectivity for your cluster.

## Day-2 Operations

Modify worker SKU Size
Change the VM size of worker nodes after cluster creation. Useful when you need to scale to adjust compute resources based on actual workload requirements.

Onboarding in GitOps Controlplane
Onboard into argocd gitops controlplane using the new Argo CD Agent.