Introduction, Pre-flight & Cluster Resource Group

Value Proposition

ARO HCP (Azure Red Hat OpenShift with Hosted Control Planes) eliminates the master node tier from a customer’s Azure subscription entirely. Red Hat owns, operates, and secures the control plane — etcd, the API server, the scheduler, and the controller manager — in a Red Hat-managed Azure service account. The customer’s operational surface begins at the worker node.

A 2026 Red Hat internal study found ARO HCP delivers up to 4x cost reduction on average and up to 55% faster cluster provisioning compared to standard ARO. The minimum cluster footprint drops from 6 nodes (3 masters + 3 workers in standard ARO) to 2 worker nodes — with no master infrastructure in the customer’s subscription at all.

ARO HCP architecture diagram showing control plane in Microsoft Subscription and worker NodePools in Customer Subscription

The diagram above captures the architectural split. The Microsoft Subscription on the left holds the entire control plane — api-server, oauth, Ignition, router, and supporting components — operated by Red Hat and connected to the customer’s infrastructure through a network interface. The Customer Subscription on the right contains only the data plane: worker nodes organised into NodePools, each independently scalable and configurable with its own VM SKU — general-purpose compute, memory-optimised, or GPU nodes. The boundary between the two subscriptions is exactly what the hands-on steps in this module verify: every resource on the left side of this diagram is absent from your Azure resource group.

For regulated industries — financial services, government, healthcare — this matters for three reasons. First, it removes a complex attack surface that most enterprise teams are not resourced to harden properly. Second, standard ARO requires Service Principals alongside Managed Identity and Workload Identity — ARO HCP eliminates Service Principals entirely, replacing them with managed identities and workload identities only, removing an entire class of credential-related compliance findings. Third, ARO HCP adds enterprise security controls including Bring Your Own Keys (BYOK) for key management, etcd encryption at rest, and Hardware Security Module (HSM) support — all without customer-managed control plane infrastructure.

This lab proves both claims through live inspection: you will query the actual Azure resource group and confirm the absence of master infrastructure, then trace the identity bindings that replace it.

Learning Objectives

By the end of this module you will be able to:

  • Verify that an ARO HCP cluster’s Azure resource group contains worker VMs but no master VMs, etcd disks, or control plane load balancers

  • Quantify the operational impact of the managed control plane model using a concrete multi-cluster calculation

  • Identify the OIDC Workload Identity model that replaces static Azure service principal credentials, using the cluster’s OIDC discovery document as evidence

Pre-flight: Confirm Environment Access

Before inspecting the cluster, confirm that your terminal has the tooling and access required.

  1. Verify Azure CLI authentication:

    az account show --output table

    Expected output:

    | EnvironmentName | HomeTenantId                         | IsDefault | Name        | State   | TenantDefaultDomain     | TenantDisplayName | TenantId                             |
| --------------- | ------------------------------------ | --------- | ----------- | ------- | ----------------------- | ----------------- | ------------------------------------ |
| AzureCloud      | 64dc69e4-d083-49fc-9569-ebece1dd1408 | True      | pool-01-316 | Enabled | redhat0.onmicrosoft.com | Red Hat, Inc      | 64dc69e4-d083-49fc-9569-ebece1dd1408 |

    Confirm the output shows your lab subscription and that State is Enabled.

  2. Verify OpenShift CLI access:

    oc whoami

    You should see your lab username.

  3. List all available resource groups in your active subscription:

    az group list --query "[].{Name:name, Location:location}" --output table

    Azure Red Hat OpenShift (including ARO HCP) automatically splits deployment assets across two distinct resource groups to separate user-managed configuration from dynamically provisioned cluster infrastructure: the primary customer resource group (aro_hcp_cluster_rg) houses top-level deployment components like the cluster resource definition, user-assigned managed identities, and customer-owned virtual networks/subnets, while the managed resource group (aro_hcp_cluster_managed_rg) is auto-generated by the provider to isolate worker virtual machine scale sets, OS disks, network interfaces, and ingress load balancers. This architectural division streamlines lifecycle operations by giving OpenShift a dedicated boundary to automatically scale worker compute and attach persistent storage via scoped managed identity permissions, while strictly maintaining the ARO HCP model where worker nodes reside in the managed resource group and master control plane virtual machines run entirely out of sight within a separate, internal Microsoft-managed subscription.

Inspect the Azure Resource Group

List All Resources

Run a full resource listing for your lab resource group:

az resource list --resource-group {aro_hcp_cluster_rg} --output table

Scan the Type column. You will see entries for network security groups, virtual networks, vaults, managed identities, HCPOpenShiftClusters & Nodepools.

Confirm No Master VMs

Filter specifically for Virtual Machine resources:

az vm list --resource-group {aro_hcp_cluster_managed_rg} --output table --query "[].{Name:name, Size:hardwareProfile.vmSize}"

Every VM listed is a worker node. None will have a master, control-plane, or etcd naming pattern — those VMs run in Azure and are invisible to your subscription.

Confirm No etcd Disks

az disk list --resource-group {aro_hcp_cluster_managed_rg} --output table --query "[].{Name:name, SizeGB:diskSizeGb}"

All disks belong to worker OS volumes. No etcd data disks are present.

Confirm No Control Plane Load Balancers

az network lb list --resource-group {aro_hcp_cluster_managed_rg} --output table

Any load balancers present are for worker-tier ingress. The API server load balancer lives in Azure, not your subscription.

Operational Impact Calculation

The managed control plane model has a concrete cost and staffing implication. Standard ARO requires a minimum of 6 nodes (3 masters + 3 workers). ARO HCP requires a minimum of 2 worker nodes — the control plane runs in Red Hat’s managed Azure service account and contributes zero nodes to the customer’s footprint.

At multi-cluster scale, the elimination of master VMs compounds quickly:

  • 5 clusters → 15 master VMs eliminated from customer-managed infrastructure

  • 15 clusters → 45 master VMs eliminated

  • 50 clusters → 150 master VMs eliminated

A 2026 Red Hat internal study quantifies the impact: up to 4x cost reduction on average and up to 55% faster cluster provisioning. At enterprise scale, this is a meaningful reduction in patching, monitoring, backup, and incident-response scope — and every eliminated master VM was a potential pivot point for an attacker who compromised a node credential.

Examine Identity Bindings

How ARO HCP Authenticates to Azure

Standard ARO authenticates to Azure using a combination of Service Principals, Managed Identities, and Workload Identities. Service Principals — static client ID and secret credentials — must be rotated manually or via automation and represent a persistent compliance finding in most Azure security baseline audits. ARO HCP eliminates Service Principals entirely. Authentication uses Managed Identities and Workload Identities only: per-component managed identities, each scoped to exactly the Azure permissions that one operator requires, with no static secret stored anywhere.

List the Per-Component Managed Identities

az resource list --resource-group {aro_hcp_cluster_rg} \
  --resource-type Microsoft.ManagedIdentity/userAssignedIdentities \
  --output table

The output lists one identity per control plane or data plane operator. The naming prefix tells you where each component runs:

  • cp- — *control plane components (cluster API, cloud controller manager, ingress, CSI drivers, image registry, network config, KMS) running in Red Hat’s managed infrastructure

  • dp- — *data plane components running on the customer’s worker nodes

  • service-managed-identity — used by the ARO HCP service itself for lifecycle operations

No single shared credential exists. If one identity were compromised, it would have access only to the Azure resources that one operator is permitted to touch — not the entire cluster’s infrastructure.

Verify the OIDC Issuer from the Cluster

The managed identities are attached to VMs managed by Red Hat — the customer does not manage their bindings or rotation. From the customer’s cluster context, the evidence of this trust model is the cluster’s OIDC discovery document:

oc get --raw '/.well-known/openid-configuration' | jq .

The issuer field is the OIDC endpoint that backs service account token exchange for the cluster. Red Hat provisions and operates this endpoint. The customer neither owns it nor rotates the credentials that depend on it.

Summary

What You Learned

  • An ARO HCP cluster’s primary resource group contains per-component managed identities — one scoped identity per operator, not a single shared credential. Master VMs, etcd disks, and the API server load balancer are absent from the customer subscription because they run in Azure.

  • The managed control plane model scales the operational simplification linearly: every additional cluster eliminates three master VMs from customer scope.

  • OIDC Workload Identity Federation replaces static Azure service principal credentials with short-lived token exchanges backed by the cluster’s OIDC issuer — satisfying zero-static-credential requirements without any customer-side secret management.

Key Takeaways for Customer Conversations

  • "Where are my master nodes?" — In Azure infrastructure. You pay for them through the subscription, but you never patch, monitor, or recover them. Your SRE team’s on-call scope ends at the worker tier.

  • "What happens if a control plane component fails?" — Red Hat’s SRE responds under the ARO SLA. The customer is not paged and does not need a runbook for etcd recovery.

  • "How does this affect our compliance posture?" — Per-component managed identities eliminate the single shared service principal credential rotation finding that appears in nearly every Azure security baseline audit. Each operator’s blast radius is limited to its own scope — a compromised identity cannot pivot to the full cluster infrastructure.

  • "Is this suitable for regulated workloads?" — ARO HCP is FedRAMP-authorized for GovCloud regions and satisfies common FSI controls around credential management and infrastructure access. The absence of customer-managed control plane VMs reduces the scope of your own compliance boundary.