Operating in a locked down network
The CycleCloud application and cluster nodes can operate in environments with limited internet access, though there are a minimal number of TCP ports that must remain open.
Installing Azure CycleCloud in a locked down network
The CycleCloud VM must be able to connect to a number of Azure APIs to orchestrate cluster VMs and to authenticate to Azure Active Directory. Since these APIs use HTTPS, CycleCloud requires outbound HTTPS access to:
- management.azure.com (Azure ARM Management)
- login.microsoftonline.com (Azure AD)
- watson.telemetry.microsoft.com (Azure Telemetry)
- dc.services.visualstudio.com (Azure Application Insights)
- ratecard.azure-api.net (Azure Price Data)
The management API is hosted regionally, and the public IP address ranges can be found here.
The Azure AD login is part of the Microsoft 365 common APIs and IP address ranges for the service can be found here.
Azure CycleCloud must be able to access Azure Storage accounts. The recommended way to provide private access to this service and any other supported Azure service is through Virtual Network Service Endpoints.
If using Network Security Groups or the Azure Firewall to limit outbound access to the required domains, then it is possible to configure Azure Cyclecloud to route all requests through an HTTPS proxy. See: Using a Web Proxy
Configuring an Azure Network Security Group for the CycleCloud VM
One way to limit outbound internet access from the CycleCloud VM without configuring the Azure Firewall or an HTTPS proxy is to configure a strict Azure Network Security Group for the CycleCloud VM's subnet. The simplest way to do that is to use Service Tags in the subnet or VM level Network Security Group to permit the required outbound Azure access.
Configure a Storage Service Endpoint for the Subnet to allow access from CycleCloud to Azure Storage
Add the following NSG Outbound rule to Deny outbound access by default using the "Internet" destination Service Tag:
- Add the following NSG Outbound rules to Allow outbound access to the required Azure services by destination Service Tag:
Internal communications between cluster nodes and CycleCloud
These ports need to be open to allow for communication between the cluster nodes and CycleCloud server:
Launching Azure CycleCloud clusters in a locked down network
Running cluster nodes in a subnet without outbound internet access is fully supported today, but it is an advanced topic that often requires either a custom image or customization of the default CycleCloud cluster types and projects or both.
We are actively updating the cluster types and projects to eliminate most or all of that work. But, if you encounter failures with your cluster type or project in your locked down environment, please consider opening a Support request for assistance.
Running VMs or Cyclecloud clusters in a virtual network or subnet with outbound internet access generally requires the following:
- Azure Cyclecloud must be reachable from the cluster VMs for full functionality. Either:
- Cluster VMs must be able to connect to Azure Cyclecloud directly via HTTPS and AMQP, or
- The Cyclecloud ReturnProxy feature must be enabled at cluster creation time and Cyclecloud itself must be able to connect to the ReturnProxy VM via SSH
- All software packages required by the cluster must either be:
- Pre-installed in a custom Managed Image for the cluster VMs, or
- Available in a package repository mirror accessible from the VMs, or
- Copied to the VM from Azure Storage and installed directly by a Cyclecloud project
- All Cluster nodes must be able to access Azure Storage accounts. The recommended way to provide private access to this service and any other supported Azure service is to enable a Virtual Network Service Endpoint for Azure Storage.