Self-Managed Azure Infrastructure

This section describes the infrastructure requirements for self-managed Azure HyperShift deployments. Self-managed Azure allows you to deploy hosted clusters with Azure worker nodes using an OpenShift management cluster that you provision and manage.

Overview

Self-managed Azure HyperShift deployments consist of:

1. Management Cluster: An OpenShift cluster (can run on any platform - AWS, Azure, bare metal, etc.) that hosts the HyperShift operator and control planes
2. Control Plane: Kubernetes control plane components running as pods on the management cluster
3. Data Plane: Worker nodes running as Azure Virtual Machines in your Azure subscription

The architecture uses Azure Workload Identity for secure, credential-free authentication between OpenShift components and Azure services.

Infrastructure Stages

Pre-required Infrastructure (Unmanaged)

The following infrastructure must exist before creating a self-managed Azure HostedCluster:

Management Cluster Requirements

Azure Subscription Requirements

Required Azure Permissions

The service principal or user creating infrastructure requires:

Persistent Resource Group (Optional)

A persistent resource group is not required, but is recommended for shared resources that can be reused across multiple HostedClusters:

OIDC Issuer

An OIDC issuer is required for workload identity federation. This is an Azure Blob Storage account configured to host:

• OIDC discovery document (.well-known/openid-configuration)
• JSON Web Key Set (JWKS) for token validation
• RSA key pair for service account token signing

The OIDC issuer is created using the Cloud Credential Operator (CCO) tool:

ccoctl azure create-oidc-issuer \
  --name=<name> \
  --region=<azure-region> \
  --subscription-id=<subscription-id> \
  --resource-group-name=<persistent-rg> \
  --storage-account-name=<oidc-storage-account> \
  --output-dir=<output-directory>

Workload Identities

Self-managed Azure requires 7 managed identities with federated credentials for OpenShift components:

Each identity is configured with:

• Federated Identity Credentials: Trust relationship between Azure Entra ID and OpenShift service accounts
• Audience: openshift
• Issuer: Your OIDC issuer URL

Role Assignment Scopes

Identities receive role assignments across multiple resource groups depending on their function:

Infrastructure Created by HyperShift

The hypershift create cluster azure command (or hypershift create infra azure) creates the following resources:

Resource Groups

Networking Resources

DNS Resources

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

Workload Identity Authentication

Self-managed Azure uses workload identity federation for secure authentication. This eliminates long-lived credentials and follows Azure's modern authentication best practices.

Authentication Flow

Federated Credential Configuration

Each managed identity has one or more federated identity credentials configured:

{
  "issuer": "https://<storage-account>.blob.core.windows.net/<container>",
  "subject": "system:serviceaccount:<namespace>:<service-account>",
  "audiences": ["openshift"]
}

Resource Group Strategy

Self-managed Azure deployments use multiple resource groups with different lifecycles:

Persistent Resources (Reused Across Clusters)

Persistent Resource Group (e.g., os4-common)
├── OIDC Issuer Storage Account
├── Workload Identities (7 managed identities)
├── Federated Identity Credentials
└── DNS Zones (optional, for External DNS)

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

• Azure Workload Identity Setup - Set up managed identities and OIDC federation
• Setup Azure Management Cluster for HyperShift - Install HyperShift operator
• Create a Self-Managed Azure HostedCluster - Deploy your first hosted cluster
• Self-Managed Azure Overview - Comprehensive overview