Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
When you create an Azure Red Hat OpenShift with hosted control planes (HCP) cluster, you set several configuration options permanently. To change these options later, you need to delete and recreate the cluster. Make informed decisions before you deploy. This article walks through each immutable option, explains the available values, and highlights the implications of each choice.
Important
You can't change the configuration options described in this article after you create your cluster. Review each option carefully before you begin cluster deployment.
Choose the cluster region
The Azure region determines where the cluster's worker nodes and infrastructure are deployed. Your choice of region constrains which VM sizes and availability zones are available for your node pools, and you can't change it after the cluster is created.
When choosing a region, consider the following factors:
- Proximity to users and services — Choose a region close to your end users or the Azure services your workloads depend on to minimize latency.
- Availability zone support — If you plan to deploy node pools across multiple availability zones for high availability, verify that your chosen region supports availability zones.
- VM size availability — Choose VM sizes from the Supported virtual machine sizes list, then verify that those sizes are available in your chosen region. Not all VM sizes are available in every region.
Choose the API server visibility
Every Azure Red Hat OpenShift with hosted control planes cluster exposes an API server that you and your tools use to manage workloads. You must decide whether this API server is reachable from the public internet or only from private networks. This choice determines how administrators, CI/CD pipelines, and automation tools connect to the cluster.
Choose one of the following visibility options:
| Option | Description |
|---|---|
| Public (default) | The API server is accessible from the public internet. |
| Private | The API server isn't exposed over the public internet and can only be reached through a private network connection to the cluster's virtual network, such as VNet peering, Azure Private Link, VPN gateway, or Azure ExpressRoute. |
Before deploying a cluster with a private API server, verify that you have network connectivity from your private network to the cluster's virtual network.
Note
Red Hat site reliability engineers (SREs) don't monitor private network connections. Monitoring private network connectivity is the customer's responsibility.
Choose the default ingress type
The default OpenShift ingress controller determines how application routes, including the OpenShift web console and your deployed applications, are exposed. You must decide whether the default ingress is reachable from the public internet or only from private networks. This choice is immutable after cluster creation.
Choose one of the following ingress types:
| Option | Description |
|---|---|
| Public (default) | Application routes are accessible from the public internet through a public Azure load balancer. |
| Private | Application routes aren't exposed over the public internet and can only be reached through a private network connection to the cluster's virtual network, such as VNet peering, VPN gateway, or Azure ExpressRoute. |
Note
After the cluster is created, you can create additional ingress controllers with different visibility settings by applying Kubernetes manifests against the API server. The ingress type set during cluster creation applies only to the default ingress controller and can't be changed.
Choose the cluster encryption strategy
Azure Red Hat OpenShift with hosted control planes stores all cluster state, including Secrets, ConfigMaps, and resource definitions, in an etcd database. The service encrypts data using a platform managed key but you additionally need to configure a customer-managed key for etcd encryption through Azure Key Vault.
Customer-managed encryption requires extra Azure infrastructure, including:
- An Azure Key Vault
- A KMS encryption key
- A KMS managed identity
- Role assignments for the KMS managed identity
You must also decide whether the Key Vault is publicly accessible or restricted to a private endpoint.
| Option | Description |
|---|---|
| Public | The Key Vault is accessible over the public internet. |
| Private | The Key Vault is accessible only through a private endpoint in the cluster's virtual network. This option deploys a private endpoint, a private DNS zone, and a virtual network link. |
Enable FIPS cryptographic compliance
Federal Information Processing Standard (FIPS) 140-2 cryptographic module compliance is required for regulated industries, including government agencies, financial services, and healthcare organizations. When you enable FIPS mode, all cryptographic operations on the cluster use FIPS 140-2 validated modules.
FIPS mode is a permanent setting. You must enable it when you create the cluster, and you can't change it after creation. To run a FIPS-compliant cluster after deploying without FIPS, you must delete and recreate the cluster with FIPS enabled.
When you enable FIPS mode:
- All worker node pools automatically inherit the cluster-level FIPS configuration and run on FIPS-enabled nodes.
- The API server accepts only FIPS-approved cipher suites.
- All certificates use FIPS-validated cryptography.
Important
The control plane is always hosted on a FIPS-enabled cluster, regardless of whether you enable FIPS during installation. The FIPS setting you choose at cluster creation applies to the worker node pools on the data plane. FIPS mode doesn't enforce FIPS compliance for your applications. Ensuring that your workloads use FIPS-compliant libraries and configurations is your responsibility.
Fixed configuration
The following aspects of the service are fixed and can't be changed. They're included here because they affect how you plan your cluster deployment.
Outbound connectivity model
Azure Load Balancer provides outbound internet connectivity for the cluster's compute nodes. When you create the cluster, you provision an outbound public IP address and direct it through the load balancer. This is the only supported outbound connectivity model, and you can't change it after cluster creation.
Authentication model
Azure Red Hat OpenShift with hosted control planes uses external authentication with an OpenID Connect (OIDC) identity provider. Unlike Azure Red Hat OpenShift (classic architecture), the built-in OpenShift OAuth server isn't available. You must configure an external OIDC identity provider to authenticate users to your cluster.
Managed identities
Azure Red Hat OpenShift with hosted control planes requires a set of user-assigned managed identities for its cluster operators to authenticate to Azure services.
You define these identities and assign each one the specific Azure roles it needs.
For a detailed description of each identity and its required role assignments, see Required managed identities and role assignments.
Choose the cluster networking plugin
Azure Red Hat OpenShift with hosted control planes uses a Container Network Interface (CNI) plugin to provide pod-to-pod networking, network policy enforcement, and other cluster networking features. You must decide whether to use the built-in OVN-Kubernetes plugin or deploy the cluster without a CNI so you can install your own. This choice affects which networking features are available by default and whether you're responsible for managing the cluster's network layer.
Choose one of the following networking options:
| Option | Description |
|---|---|
OVNKubernetes (default) |
Deploys the cluster with OVN-Kubernetes, the default CNI plugin for Azure Red Hat OpenShift with hosted control planes. OVN-Kubernetes provides a full-featured software-defined networking layer, including network policy enforcement, egress IP management, and multicast support. |
Other |
Deploys the cluster without a CNI plugin. You must install and manage your own CNI plugin after cluster creation, such as Cilium. |
If you select Other, the cluster's pod network isn't functional until you install a compatible CNI plugin.
Choose the cluster image registry configuration
Azure Red Hat OpenShift with hosted control planes includes a built-in container image registry that runs as a workload on the cluster. You must decide whether to deploy this internal registry or skip it entirely. The internal registry enables native build workflows and ImageStreams, but if your organization standardizes on an external registry like Azure Container Registry, you might not need it.
Choose one of the following registry options:
| Value | Description |
|---|---|
| Enabled (default) | The internal image registry is deployed. The registry allows you to build and store container images directly on the cluster using builds and ImageStreams. |
| Disabled | The internal image registry isn't deployed. Choose this option if you plan to use only external container registries, such as Azure Container Registry. |
You can't enable the internal registry after the cluster is created.
Choose the DNS base domain prefix
Your cluster's base domain name appears in the API server URL and in every application route that the cluster generates. You can set a custom prefix for this domain name, or let the service generate one automatically. A custom prefix makes it easier to identify your cluster in DNS records and URL bars, which is useful when you manage multiple clusters.
Choose a custom prefix, or let the service generate one automatically.
When specified, the prefix must meet the following requirements:
- Maximum length of 15 characters
- Starts with a lowercase letter
- Contains only lowercase letters, numbers, and hyphens (
-) - Ends with a lowercase letter or number