Prerequisites Checklist to Deploy ARO Cluster

This article was originally published on November 30, 2023, at https://cloud.redhat.com/experts/aro/prereq-list

Before deploying an ARO cluster, ensure you meet the following prerequisites:

Setup Tools

• Install Azure CLI: Essential for managing Azure resources. Refer to the official documentation

Verify Resources

• Core Quota: Confirm availability of at least 40 cores to create and run an OpenShift Cluster.

Permissions

• RBAC Settings:
  • Ensure you have Contributor and User Access Administrator roles on the cluster resource group.
  • Assign Network Contributor role on the virtual network, if using a separate resource group.
  • For stricter security policies, create a custom role with necessary permissions. Reference link.
• Microsoft Entra (Former Azure AD):
  • Have a member user of the tenant or a guest with Application administrator role for the tooling to create an application and service principal on your behalf for the cluster.
• Terraform: If you plan to use Terraform for the deployment of the cluster, see here the required permissions.

Azure Integration

• Resource Provider:
  • Register the Microsoft.RedHatOpenshift resource provider. Reference link.
• Red Hat Integration:
  • Obtain a Red Hat pull secret (Recommended for access to additional content like Operators and Container Registries).

Domain Configuration

This step is optional since you can use the built-in domain.

• Custom Domain:
  • Post-cluster creation, configure two DNS A records for the specified domain:
    • api pointing to the API server IP.
    • *.apps pointing to the ingress IP.
  • Retrieve IP addresses using: az aro show -n -g --query '{"api":apiserverProfile.ip, "ingress":ingressProfiles[0].ip}'.
  • Access OpenShift console via https://console-openshift-console.apps.example.com (instead of the built-in domain https://console-openshift-console.apps...aroapp.io)
  • If using custom DNS, set up a custom CA for your ingress controller and API server.

Network Configuration

• Virtual Network:
  • Create or provide a VNet with two subnets for master and worker nodes.
  • Ensure Pod and Service Network CIDRs do not overlap with other network ranges. Reference link.
• Outbound Traffic:
  • Default deployment is with outboundType: LoadBalancer, meaning that a Public IP is associated with the Load Balancer for the cluster egress connectivity.
  • To restrict Internet Egress, set --outbound-type to UserDefinedRouting.
  • Consider use a Firewall solution from your choice or Azure native solutions like Azure Firewall or NAT Gateway for enhanced security. Reference link.

Cluster Creation

• Private vs Public Clusters:
  • Private Cluster:
    • This is typically the most suitable option for production use. A Private Cluster makes the cluster API and *.apps endpoints private. Utilize Azure Frontdoor for Internet access to applications on a private cluster. This approach significantly enhances security by keeping the cluster and Azure resources private, managing traffic at the edge, and offering benefits such as Web Application Firewall (WAF), DDoS protection, SSL management, and offloading. For detailed implementation guidance, refer to Azure Frontdoor documentation.
  • Public Cluster:
    • Opt for a Public Cluster only in situations like a “sandbox cluster” or where establishing a private method for console and API access is not feasible or desired, since the cluster API and *.apps endpoints will be exposed to the Internet.
• Egress Lockdown:
  • Note that ARO clusters do not require Internet connectivity. Learn about Egress Lockdown.
  • All of the required connections for an ARO cluster are proxied through the service, see the list of endpoints here.
• Create the Cluster:
  • Proceed to create your ARO cluster once all prerequisites are met.

For a detailed step-by-step guide on creating your ARO cluster, refer to the official ARO documentation.