Create an Azure Red Hat OpenShift 4 private cluster

Question

Create an Azure Red Hat OpenShift 4 private cluster

Alex 0

When provisioning a private ARO cluster, what is the reason for enabling the ACR service endpoint on the master node subnet? This step was not required for the public cluster configuration.

https://learn.microsoft.com/en-us/azure/openshift/howto-create-private-cluster-4x

Alex 0 Reputation points

2026-04-22T19:04:01.4533333+00:00

It is my understanding that egress lockdown proxies all necessary communications for the ARO cluster. Why are additional routes via service endpoints still required? If they are necessary, does that imply the egress lockdown feature is incomplete?

Also, regarding the ACR service endpoint, isn't this currently a preview feature? If we were to allow traffic through a firewall instead, what would be the recommended configuration? Furthermore, why is there no mention of these requirements in the documentation for private clusters?

3 answers

Your answer

Alex 0 Reputation points

2026-04-22T19:04:01.4533333+00:00

It is my understanding that egress lockdown proxies all necessary communications for the ARO cluster. Why are additional routes via service endpoints still required? If they are necessary, does that imply the egress lockdown feature is incomplete?

Also, regarding the ACR service endpoint, isn't this currently a preview feature? If we were to allow traffic through a firewall instead, what would be the recommended configuration? Furthermore, why is there no mention of these requirements in the documentation for private clusters?

Answer 1

Prashant Ranjan 0

This difference comes down to how networking works in a private ARO cluster vs a public one.

In a private ARO cluster, the cluster components (including the control plane / master nodes) don’t have public internet access. So anything they need — like pulling container images — has to go through private network paths.

That’s where the ACR service endpoint comes in. By enabling the service endpoint on the master subnet, you’re allowing the cluster to securely reach Azure Container Registry over the Azure backbone instead of the public internet.

In a public cluster, this isn’t required because the nodes can already access external endpoints over the internet, so they can reach ACR without additional configuration.

In short:

Private cluster → no outbound internet → needs service endpoints (or private endpoints) to reach ACR

Public cluster → has internet access → no extra setup needed

That’s why the step is required only for private cluster deployments.

Alex 0 Reputation points

2026-04-22T22:18:07.62+00:00

It is my understanding that egress lockdown proxies all necessary communications for the ARO cluster. Why are additional routes via service endpoints still required? If they are necessary, does that imply the egress lockdown feature is incomplete?

Also, regarding the ACR service endpoint, isn't this currently a preview feature? If we were to allow traffic through a firewall instead, what would be the recommended configuration? Furthermore, why is there no mention of these requirements in the documentation for private clusters?

Answer 2

Anonymous

Hello Alex,

Thank you for your question.

In a private Azure Red Hat OpenShift (ARO) 4 cluster, the control plane and worker nodes do not have direct access to the public internet by default. Because of this restricted network design, the cluster needs an approved and private path to reach Azure services such as Azure Container Registry (ACR).

Enabling the ACR service endpoint on the master node subnet ensures that the cluster can securely access ACR over the Azure backbone network instead of relying on public internet access. This is required for private clusters to pull container images from ACR in a supported and secure manner.

In contrast, for a public ARO cluster, nodes already have outbound internet connectivity, so they can access ACR directly without needing a service endpoint configuration.

So, in summary:

Public cluster: Internet access is available by default → no service endpoint needed for ACR
Private cluster: No public internet access → service endpoint (or private link) is required for ACR connectivity

This is why the additional configuration step is required only in the private cluster deployment scenario as described in the documentation.

Alex 0 Reputation points

2026-04-22T22:18:18.6366667+00:00

It is my understanding that egress lockdown proxies all necessary communications for the ARO cluster. Why are additional routes via service endpoints still required? If they are necessary, does that imply the egress lockdown feature is incomplete?

Also, regarding the ACR service endpoint, isn't this currently a preview feature? If we were to allow traffic through a firewall instead, what would be the recommended configuration? Furthermore, why is there no mention of these requirements in the documentation for private clusters?

@Jilakara Hemalatha
Anonymous

2026-04-23T15:40:07.29+00:00

With egress lockdown enabled in Azure Red Hat OpenShift, service endpoints are no longer required for accessing Azure services such as Azure Container Registry (ACR). In this mode, the platform logic that normally ensures service endpoints are configured on the associated subnets is intentionally not executed, since egress lockdown changes the outbound connectivity model for the cluster.

So, service endpoints are not an additional dependency on top of egress lockdown, and their presence is not required for this scenario.

Regarding your concern about whether this indicates a limitation in egress lockdown: it does not. This is expected behavior based on the design of the feature, where egress lockdown replaces the need for service endpoint-based connectivity in these scenarios.

For ACR connectivity in a private ARO cluster, the recommended and supported approach is to use Azure Private Link (Private Endpoints), especially when you are also using a private container registry. This provides fully private, supported connectivity between the cluster and ACR and aligns with Microsoft’s current guidance for private networking scenarios.

Reference: https://learn.microsoft.com/en-us/azure/container-registry/container-registry-vnet
Alex 0 Reputation points

2026-04-24T02:52:16.86+00:00

@Anonymous

Thank you for your reply

I would like to clarify the behavior of Azure Red Hat OpenShift (ARO) Egress Lockdown and request an update to the official documentation.

My Understanding:

It is my understanding that even when Egress Lockdown is intended, the ACR service endpoint (or an equivalent direct path) is mandatory during the cluster creation phase. This is because the Egress Lockdown feature, which proxies communication via private endpoints, only becomes fully operational after the cluster provisioning has succeeded. If these service endpoints are not configured in the VNet subnets during the initial setup, the cluster creation will fail because nodes cannot pull essential system images.

Request for Documentation Update:

I suggest adding these details to the documentation for ARO Egress Lockdown and Private Clusters. Specifically:

Clearly state that ACR service endpoints are required specifically for the provisioning/creation phase.

Clarify that Egress Lockdown (the proxy-based architecture) takes over communication only after the cluster is successfully established.

Providing this information would prevent confusion for users who expect Egress Lockdown to handle all traffic from the very beginning of the deployment process.
Anonymous

2026-04-28T09:31:23.1233333+00:00

We are currently reviewing this with our internal team
Anonymous

2026-04-29T03:24:15.9966667+00:00
Hello Alex,

Thank you for your patience while we validated this with our internal engineering team.

Based on the confirmation received, we would like to clarify the behavior of Azure Red Hat OpenShift (ARO) private clusters with Egress Lockdown:

Egress Lockdown is designed to handle outbound connectivity from the beginning of the cluster lifecycle, including during the provisioning (bootstrap) phase. There is no distinction between provisioning and post-provisioning traffic flow in this model.

Specifically:

ACR service endpoints are not required for ARO clusters with Egress Lockdown enabled — neither during cluster creation nor after provisioning.

All required outbound communication, including image pulls (such as from arosvc.azurecr.io), is handled through the egress lockdown infrastructure, which uses a private, platform-managed connectivity model (based on Private Link).

This behavior is by design, and a fully private connectivity approach is supported from the start — there is no dependency on service endpoints for cluster deployment.

There may be specific edge scenarios (for example, certain configurations involving private Azure services like Key Vault) where additional networking configurations such as service endpoints could be required. However, these are not part of the standard ARO cluster provisioning or ACR access requirements.

Regarding documentation, we acknowledge that the current guidance may not clearly reflect this behavior. The product team is actively working on updating the documentation to better clarify that service endpoints are not required when Egress Lockdown is used.

For more details on how Egress Lockdown manages outbound traffic, please refer to:

https://learn.microsoft.com/en-us/azure/openshift/concepts-egress-lockdown

Hope this helps! Please let me know if you have any queries.
Anonymous

2026-04-30T01:50:29.5433333+00:00

Hello Alex, Just checking if provided information was helpful! Please let me know if you have any queries.

Answer 3

Enabling the Microsoft.ContainerRegistry service endpoint on the master (control plane) subnet is required so that the private ARO control-plane nodes can reach Azure Container Registry (ACR) over the virtual network without using public IP connectivity.

In a private ARO cluster (--apiserver-visibility Private and --ingress-visibility Private), the control plane and worker nodes are placed in private subnets and are not exposed via public endpoints. To pull required container images (for the platform components and workloads) from ACR in this locked-down network model, the subnets hosting those nodes must have a direct, VNet-integrated path to ACR. The service endpoint Microsoft.ContainerRegistry on the master and worker subnets provides that path.

For public clusters, outbound connectivity to ACR is typically achieved via public IP and standard system routes, so explicitly enabling the ACR service endpoint on the master subnet is not mandatory. In contrast, for private clusters, configuring the service endpoint on the master subnet is a prerequisite so the control plane can reliably access ACR without relying on public internet egress.

References: