Network Requirements¶

CertifyClouds runs in your Azure tenant, inside your VNet, against your Key Vaults. This page lists every network path the application needs in order to function: what it talks to outbound, what reaches it inbound, and the NSG / firewall rules you'll need.

If activation or feature calls are failing on a fresh deploy, work through this page first.

Outbound: what CertifyClouds talks to¶

The Container App (or Container Instance) must be able to reach the following hosts on 443/tcp. If your subnet has an NSG with default-deny outbound, an Azure Firewall with FQDN filtering, or a corporate egress proxy, each of these has to be on the allowlist.

Required, core platform¶

Conditional, only required for specific features¶

NSG / firewall configuration¶

Option A: Azure Firewall with FQDN tags¶

Microsoft ships FQDN tags that cover many Microsoft endpoints automatically:

• AzureKeyVault covers *.vault.azure.net
• AzureContainerRegistry covers your ACR (only relevant if you've imported the image to a private ACR, separate from Docker Hub)

You still need to add the following manually as they are not covered by the standard FQDN tags:

• license.certifyclouds.com
• hub.docker.com, *.docker.io, auth.docker.io, production.cloudflare.docker.com
• graph.microsoft.com
• login.microsoftonline.com

Option B: Plain NSG outbound rules¶

NSGs do not support FQDN filtering, so allow outbound 443/tcp to the relevant Azure service tags plus Internet for the non-Azure endpoints. Adjust subnet, NSG names, and priorities to your environment:

# Azure AD authentication
az network nsg rule create \
  --resource-group <nsg-rg> \
  --nsg-name <nsg-name> \
  --name "Allow-AzureAD-Outbound" \
  --priority 100 \
  --direction Outbound \
  --destination-address-prefixes AzureActiveDirectory \
  --destination-port-ranges 443 \
  --access Allow --protocol Tcp

# Key Vault data plane
az network nsg rule create \
  --resource-group <nsg-rg> \
  --nsg-name <nsg-name> \
  --name "Allow-KeyVault-Outbound" \
  --priority 110 \
  --direction Outbound \
  --destination-address-prefixes AzureKeyVault \
  --destination-port-ranges 443 \
  --access Allow --protocol Tcp

# Azure Resource Manager (used by Dependencies feature)
az network nsg rule create \
  --resource-group <nsg-rg> \
  --nsg-name <nsg-name> \
  --name "Allow-AzureResourceManager-Outbound" \
  --priority 120 \
  --direction Outbound \
  --destination-address-prefixes AzureResourceManager \
  --destination-port-ranges 443 \
  --access Allow --protocol Tcp

# Generic internet, license server, Docker Hub, optional SendGrid, etc.
# Use Azure Firewall FQDN filtering for tighter control if needed.
az network nsg rule create \
  --resource-group <nsg-rg> \
  --nsg-name <nsg-name> \
  --name "Allow-Internet-HTTPS-Outbound" \
  --priority 200 \
  --direction Outbound \
  --destination-address-prefixes Internet \
  --destination-port-ranges 443 \
  --access Allow --protocol Tcp

Option C: Corporate egress proxy with allowlist¶

If outbound traffic forces through a corporate proxy with an allowlist, hand the list below to your network team:

license.certifyclouds.com
hub.docker.com
*.docker.io
auth.docker.io
production.cloudflare.docker.com
login.microsoftonline.com
*.vault.azure.net
graph.microsoft.com
*.azurewebsites.net          # Dependencies feature only
*.azure-api.net              # Dependencies feature only
management.azure.com         # Dependencies feature only
smtp.sendgrid.net            # If using SendGrid for email alerts
challenges.cloudflare.com    # If Turnstile is enabled

If a proxy is required, set HTTPS_PROXY and NO_PROXY environment variables on the Container App. NO_PROXY should include your Postgres FQDN and any internal Azure endpoints you do not want proxied.

Inbound: how users reach CertifyClouds¶

The deploy script creates the Container Apps Environment in internal-only mode by default, no public IP. Users reach the UI through one of several patterns; see Post-Install Reachability for the full breakdown.

For patterns that involve a reverse proxy inside your VNet (Application Gateway, an internal NVA, etc.), the CAE's NSG needs an inbound rule allowing 443/tcp from the proxy's subnet:

az network nsg rule create \
  --resource-group <nsg-rg> \
  --nsg-name <cae-nsg> \
  --name "Allow-ReverseProxy-Inbound" \
  --priority 100 \
  --direction Inbound \
  --source-address-prefixes <reverse-proxy-subnet-cidr> \
  --destination-port-ranges 443 \
  --access Allow --protocol Tcp

For Azure Front Door Premium with a Private Endpoint, the inbound flow is handled by the Private Endpoint itself, no NSG rule needed.

For VPN/ExpressRoute access, allow 443/tcp from your corporate IP ranges.

PostgreSQL subnet¶

The Postgres flexible server runs in its own delegated subnet (Microsoft.DBforPostgreSQL/flexibleServers). For normal operation it requires no outbound rules. If you enable customer-managed keys or geo-redundant backups, allow outbound to:

• *.blob.core.windows.net (backup destination, covered by the Storage service tag)
• login.microsoftonline.com (for CMK, covered by AzureActiveDirectory)

Diagnostic: is my egress working?¶

From any host inside the CAE VNet (jump VM, peered VNet, or az containerapp exec), run:

# License server reachable?
curl -sS -m 10 https://license.certifyclouds.com/health
# Expected: {"status":"ok",...}

# Docker Hub reachable?
curl -sS -m 10 -o /dev/null -w "%{http_code}\n" https://hub.docker.com/v2/
# Expected: 200 or 401 (auth challenge, proves connectivity)

# Microsoft Graph reachable?
curl -sS -m 10 -o /dev/null -w "%{http_code}\n" https://graph.microsoft.com/v1.0/
# Expected: 401 (auth challenge, proves connectivity)

# Azure AD reachable?
curl -sS -m 10 -o /dev/null -w "%{http_code}\n" https://login.microsoftonline.com/common/.well-known/openid-configuration
# Expected: 200

If license.certifyclouds.com does not respond, fix that first, the rest of the troubleshooting below assumes the license server is reachable.

Symptoms when egress is blocked¶

Why the deploy script doesn't create NSG rules¶

Network policy belongs to your team, not to a third-party deploy script. Automated NSG changes during a vendor tool's deploy frequently violate change-control rules, and different organisations use different egress mechanisms (NSG service tags vs Azure Firewall vs corporate proxy vs forced UDR) that we cannot autodetect.

The list above is what to give your network team.