ARO HCP (Managed Azure) Infrastructure

This section describes the infrastructure requirements for ARO HCP (Azure Red Hat OpenShift Hosted Control Planes) deployments. ARO HCP uses an AKS (Azure Kubernetes Service) management cluster to host OpenShift control planes with Azure worker nodes.

Overview

ARO HCP deployments consist of:

1. Management Cluster: An AKS cluster that hosts the HyperShift operator and control planes
2. Control Plane: OpenShift control plane components running as pods on the AKS management cluster
3. Data Plane: Worker nodes running as Azure Virtual Machines in the customer's Azure subscription

The architecture uses Azure Managed Identities with certificate-based authentication for secure communication between OpenShift components and Azure services. Credentials are stored in Azure Key Vault and accessed via the Secrets Store CSI driver.

Infrastructure Stages

Pre-required Infrastructure (Unmanaged)

The following infrastructure must exist before creating an ARO HCP HostedCluster:

Required Azure Permissions

A service principal with the following permissions is required for creating infrastructure:

Additionally, Microsoft Graph API permissions are required:

Shared Resources (Per Management Cluster)

A resource group for shared resources that are reusable across HostedCluster creation and deletion cycles:

AKS Management Cluster

An AKS cluster that hosts the HyperShift operator and control planes. For production deployments, the following features are recommended:

Control Plane Identities

ARO HCP uses service principals with certificate-based authentication for control plane components. These credentials are stored in Azure Key Vault and mounted into pods via the Secrets Store CSI driver.

Each control plane identity includes:

• Client ID: UUID identifying the service principal
• Certificate: X.509 certificate for authentication
• Object Encoding: Format of the certificate in Key Vault (utf-8, hex, or base64)

The control plane identities are provided in a JSON file with the following format:

{
  "controlPlane": {
    "managedIdentitiesKeyVault": {
      "name": "<key-vault-name>",
      "tenantID": "<tenant-id>"
    },
    "cloudProvider": {
      "clientID": "<uuid>",
      "credentialsSecretName": "<secret-name>",
      "objectEncoding": "utf-8"
    },
    "nodePoolManagement": { ... },
    "controlPlaneOperator": { ... },
    "imageRegistry": { ... },
    "ingress": { ... },
    "network": { ... },
    "disk": { ... },
    "file": { ... }
  },
  "dataPlane": {
    "imageRegistryMSIClientID": "<uuid>",
    "diskMSIClientID": "<uuid>",
    "fileMSIClientID": "<uuid>"
  }
}

Data Plane Identities

Data plane identities are Azure managed identities with federated credentials for components running on worker nodes. Each managed identity is assigned an Azure built-in role that grants the specific permissions required by that component:

The data plane identities are provided in a JSON file with the following format:

{
  "imageRegistryMSIClientID": "<uuid>",
  "diskMSIClientID": "<uuid>",
  "fileMSIClientID": "<uuid>"
}

OIDC Issuer

An OIDC issuer is required for data plane workload identity federation (see Data Plane Authentication for how this works). Setting up an OIDC issuer requires:

• Azure Blob Storage account configured as OIDC issuer
• RSA key pair for service account token signing
• Created using the Cloud Credential Operator (CCO) tool

Infrastructure Required Before HostedCluster Creation

The following Azure infrastructure must exist before creating a HostedCluster resource:

Resource Groups

Networking Resources

DNS Resources

Internal cluster DNS resolution requires a Private DNS Zone and a Virtual Network Link connecting the worker VNet to that zone.

Load Balancer Resources

The load balancer is configured with:

• Frontend IP Configuration: Associated with the public IP
• Backend Address Pool: For worker node NICs
• Health Probe: HTTP probe on port 30595, path /healthz, 5-second interval
• Outbound Rule: All protocols, 1024 allocated ports per instance, TCP reset enabled, 4-minute idle timeout

Infrastructure Managed by Kubernetes

The following resources are created and managed by Kubernetes controllers running in the hosted cluster:

Networking

• Azure Load Balancers: Created for ingress (default router) and services of type LoadBalancer
• Public IP Addresses: Allocated for load balancer frontends
• Security Group Rules: Added to the NSG for service traffic

Storage

• Azure Disks: Managed disks for persistent volumes (via Azure Disk CSI driver)
• Azure File Shares: File shares for ReadWriteMany persistent volumes (via Azure File CSI driver)
• Storage Accounts: Created as needed for Azure File storage

Compute

• Azure Virtual Machines: Worker nodes managed by Cluster API Provider Azure
• Network Interfaces: NICs attached to worker VMs
• OS Disks: Managed disks for VM operating systems

Managed Identity Authentication

ARO HCP uses a two-tier authentication model:

Control Plane Authentication (Certificate-Based)

Control plane components authenticate using service principal certificates stored in Azure Key Vault:

The Key Vault integration uses:

• SecretProviderClass: Defines which secrets to mount from Key Vault
• CSI Volume: Mounts secrets into pod filesystem at /etc/kubernetes/azure/
• Managed Identity: AKS cluster identity authorized to read from Key Vault

Data Plane Authentication (Federated Identity)

Data plane components use federated managed identities similar to self-managed Azure:

Resource Group Strategy

ARO HCP deployments use multiple resource groups with different lifecycles:

Persistent Resources (Reused Across Clusters)

Persistent Resource Group (e.g., os4-common)
├── Azure Key Vault
│   └── Service Principal Certificates
├── OIDC Issuer Storage Account
├── Data Plane Managed Identities
│   ├── Image Registry Identity
│   ├── Disk CSI Identity
│   └── File CSI Identity
└── DNS Zones

AKS Management Cluster Resources

AKS Resource Group
├── AKS Cluster
├── Node Pools
├── Cluster Managed Identity
└── Kubelet Managed Identity

Cluster-Specific Resources (Created/Deleted Per Cluster)

By default, HyperShift creates separate resource groups for different resource types. However, all resources can be placed in a single managed resource group if preferred.

Default (Separate Resource Groups):

Managed Resource Group (<name>-<infra-id>)
├── Virtual Machines (worker nodes)
├── Managed Disks (OS and data disks)
├── Network Interfaces
└── Load Balancers (ingress, services)

VNet Resource Group (<name>-<infra-id>-vnet)
├── Virtual Network
├── Subnet
├── Private DNS Zone
└── Private DNS Zone Link

NSG Resource Group (<name>-<infra-id>-nsg)
└── Network Security Group

Single Resource Group (Alternative):

You can use an existing VNet and NSG from the same resource group, which places all cluster resources in a single resource group.

Related Documentation

• Create an Azure Hosted Cluster on AKS - Step-by-step setup guide
• Azure Hosted Cluster with Options - Advanced configuration options
• Self-Managed Azure Infrastructure - Alternative deployment model