1. Documentation
×

Deploying hosted control planes on Azure

With hosted control planes on Microsoft Azure, you can reduce the cost and overhead associated with dedicated control-plane node VMs for each cluster. You can provision compute nodes as Azure Virtual Machine Scale sets for dynamic scaling, and ensure credential isolation with per-cluster Azure service principals.

Hosted control planes on Azure is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

Overview of hosted control planes on Azure

You can deploy and manage hosted clusters on an OpenShift management cluster that runs in Microsoft Azure. With a self-managed deployment model, you manage your own OpenShift cluster.

Architecture of hosted control planes on Azure

At a high level, the architecture of hosted control planes on Azure consists of three layers:

Management cluster

An Azure OpenShift cluster that hosts the HyperShift Operator and the control planes for your hosted clusters.

Control plane

Kubernetes control-plane components that run as pods on the management cluster.

Data plane

Compute nodes that run as Azure virtual machines (VMs) in your Azure subscription.

The architecture uses Azure Workload Identity for secure, credential-free authentication between OKD components and Azure services. As a result, you do not need to manage long-lived service principal credentials, and you get better security through federated identity credentials.

Deployment workflow for hosted control planes on Azure

Deploying self-managed hosted control planes on Azure involves a three-phase process in the following order:

Phase 1: Set up Azure Workload Identity

This phase establishes secure authentication infrastructure so that OKD components can access Azure services. During this phase, the security infrastructure that your hosted clusters require is created:

  • Managed identities for each OKD component, including the image registry, ingress, CSI drivers, cloud provider, network operator, and so on

  • OIDC issuer in Azure Blob Storage for service account token validation

  • Federated credentials that establish trust relationships between Azure Entra ID and OKD service accounts

Phase 2: Set up the management cluster

In this phase, you prepare your OKD management cluster on Azure to host and manage hosted clusters. During this phase, you install the following components:

  • Azure DNS zones, for private and public-private topologies

  • External DNS, for private and public-private topologies

  • HyperShift Operator

Phase 3: Create hosted clusters

In this phase, you create and configure hosted clusters. This phase involves the following steps:

  1. Setting up infrastructure

  2. Creating a hosted cluster

  3. Integrating workload identity

  4. Configuring private endpoint access (optional)

Additional resources

Azure infrastructure and credentials

Before you get started with hosted control planes on Microsoft Azure, get familiar with the required Azure resources and the necessary permissions.

Summary of requirements

You need the following resources, tools, access, and permissions to set up hosted control planes on Azure:

Azure resources

  • An OKD management cluster on Azure.

  • An Azure subscription with contributor and user-access administrator permissions.

  • (Optional) A parent DNS zone in Azure for delegating cluster DNS records. This DNS zone is required only if you plan to use external DNS.

Tools and access

  • Azure command-line interface (CLI), az, configured with your subscription

  • OpenShift CLI (oc)

  • hosted control planes CLI, hcp

  • jq command-line JSON processor

  • Cloud Credential Operator utility (ccoctl)

  • A valid OKD pull secret

Permissions

  • Subscription-level contributor and user access administrator roles

  • Microsoft Graph API permissions for creating service principals

DNS management options

You can set up hosted control planes on Azure with or without external DNS. If you plan to use a private or a public-private topology, external DNS is required. See the following table for more information:

Table 1. DNS approaches for hosted control planes on Azure
With external DNS Without external DNS

Best for

Production, multi-cluster

Development, testing

API server DNS

Custom (api-cluster.example.com)

Azure Load Balancer (abc123.region.cloudapp.azure.com)

Setup complexity

Low, requires DNS zones and service principals

None

Management

Fully automatic

Manual or Azure-provided

Resource group strategy

Cluster-specific resource groups are created and deleted with each hosted cluster. These resources include managed resource groups for cluster infrastructure. If you use custom networking, these resources also include Virtual Network (VNet) resource groups and Network Security Group (NSG) resource groups.

Security considerations for hosted control planes on Azure

Hosted control planes on Azure employs the following security best practices:

  • Workload identity federation, which eliminates long-lived credentials by using OIDC-based authentication.

  • Least-privilege access, where each component has its own managed identity with minimal required permissions.

  • Network isolation, where you can use custom VNets and NSGs to implement network segmentation and security policies.

  • Federated credentials, where trust relationships are scoped to specific service accounts, preventing unauthorized access.

  • Private connectivity, available as an option through Azure Private Link, which provides private API server access to ensure that control-plane traffic never traverses the public internet. Private connectivity is available for private and public-private topologies only.