Document BYOC Azure centralized egress with Azure Firewall#643
Document BYOC Azure centralized egress with Azure Firewall#643ppanagiotis wants to merge 1 commit into
Conversation
Add hub setup and configuration pages for the beta NAT Gateway-free egress feature on Azure, mirroring the existing AWS Transit Gateway and GCP VPC Peering equivalents. Unlike AWS/GCP, this is API-only today (no Cloud UI support), so the pages route through the Cloud API using egress_spec.azure.hub_vnet_id and firewall_private_ip. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
✅ Deploy Preview for rp-cloud ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
📝 WalkthroughWalkthroughAdds Azure BYOC centralized egress documentation covering hub VNet and Azure Firewall provisioning, traffic flow, prerequisites, limitations, troubleshooting, and API configuration through Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant Azure BYOC cluster
participant Azure spoke VNet
participant Azure hub VNet
participant Azure Firewall
participant Internet
Azure BYOC cluster->>Azure spoke VNet: Send internet-bound traffic
Azure spoke VNet->>Azure hub VNet: Forward traffic through peering
Azure hub VNet->>Azure Firewall: Route traffic to firewall private IP
Azure Firewall->>Internet: SNAT traffic through static public IP
Internet->>Azure Firewall: Return traffic
Azure Firewall->>Azure spoke VNet: Forward return traffic
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 8
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@modules/networking/pages/byoc/azure/azure-hub-egress.adoc`:
- Around line 358-366: Update the “Plan for high availability” section to state
that new Azure Firewall deployments are zone-redundant by default in regions
supporting availability zones. Clarify that explicit zone settings are only
needed for single-zone deployments or regions without zone support, and align
the Terraform reference module guidance with this behavior.
- Around line 270-285: Update the firewall deployment sequence after `az network
firewall ip-config create` and before collecting or using its frontend IP by
adding the `az network firewall update` step for `$FIREWALL_NAME` and
`$RESOURCE_GROUP`. Alternatively, verify and document that the targeted CLI
extension version no longer requires this step.
In `@modules/networking/pages/byoc/azure/nat-free-egress.adoc`:
- Around line 87-90: Update the warning in
modules/networking/pages/byoc/azure/nat-free-egress.adoc lines 87-90 to present
10.255.0.0/16 only as an example and require users to verify it does not overlap
existing network ranges. Update the default-values note in
modules/networking/pages/byoc/azure/azure-hub-egress.adoc lines 67-73 to warn
that this range may conflict with enterprise RFC 1918 networks.
- Around line 140-159: Align both Azure network examples with the API’s
canonical request envelope: in
modules/networking/pages/byoc/azure/nat-free-egress.adoc lines 140-159, wrap the
existing request fields under a network object; in
modules/manage/partials/controlplane-api.adoc lines 188-209, retain that
canonical envelope and update the Azure example fields to match the actual API
schema. Use the same envelope and Azure field structure in both examples.
- Around line 119-121: Update the Azure centralized-egress documentation to
consistently reflect dependency order: in
modules/networking/pages/byoc/azure/nat-free-egress.adoc lines 119-121, remove
the requirement to complete VNet peering before network creation; in
modules/manage/partials/controlplane-api.adoc line 188, state that VNet peering
is provisioned after the network request; in
modules/networking/pages/byoc/azure/azure-hub-egress.adoc lines 46-52, explain
that the hub and firewall are prepared first and the spoke ID is collected
afterward; and in lines 289-297, explicitly identify hub-side peering as
occurring after network provisioning.
- Around line 84-85: The Azure peering prerequisites incorrectly conflate
gateway transit with Azure Firewall forwarding. In
modules/networking/pages/byoc/azure/nat-free-egress.adoc lines 84-85, document
allow_forwarded_traffic for the firewall path and make allow_gateway_transit
conditional on exporting a VPN/ExpressRoute gateway; apply the corresponding
clarification at lines 101-106. Update
modules/networking/pages/byoc/azure/azure-hub-egress.adoc lines 293-321
consistently, preserving gateway transit only for hub gateway scenarios.
- Around line 165-178: The Internet endpoints section in
modules/networking/pages/byoc/azure/nat-free-egress.adoc lines 165-178 must
identify Azure Firewall application rules for hostname-based entries and
document the DNS proxy configuration required for FQDN filtering. In
modules/networking/pages/byoc/azure/azure-hub-egress.adoc lines 188-234, mark
the AllowAll policy as bootstrap-only or replace it with a restricted
production-oriented example so it is not presented as the default allowlist.
- Around line 180-182: Update the DNS resolution section to state that
Azure-provided DNS at 168.63.129.16 bypasses UDRs and does not depend on
0.0.0.0/0 being routed through the hub. If custom DNS is supported, document
that it requires a separate reachable network path; otherwise remove the
implication that hub routing controls DNS resolution.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: a6a2b2d4-7bcc-4481-89e1-644f1fecf66a
📒 Files selected for processing (7)
modules/ROOT/nav.adocmodules/get-started/pages/cloud-overview.adocmodules/get-started/pages/cluster-types/byoc/azure/create-byoc-cluster-azure.adocmodules/get-started/pages/whats-new-cloud.adocmodules/manage/partials/controlplane-api.adocmodules/networking/pages/byoc/azure/azure-hub-egress.adocmodules/networking/pages/byoc/azure/nat-free-egress.adoc
| az network firewall create \ | ||
| --name $FIREWALL_NAME \ | ||
| --resource-group $RESOURCE_GROUP \ | ||
| --location $LOCATION \ | ||
| --sku AZFW_VNet \ | ||
| --tier Standard \ | ||
| --firewall-policy $FIREWALL_POLICY_ID | ||
|
|
||
| az network firewall ip-config create \ | ||
| --firewall-name $FIREWALL_NAME \ | ||
| --name hub-fw-ipconfig \ | ||
| --resource-group $RESOURCE_GROUP \ | ||
| --vnet-name $VNET_NAME \ | ||
| --public-ip-address $FIREWALL_PIP_NAME | ||
|
|
||
| echo "Firewall created: $FIREWALL_NAME" |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
Complete the firewall deployment before collecting its IP.
Microsoft’s current CLI deployment sequence runs az network firewall update after az network firewall ip-config create and before reading the frontend IP. Add that step, or verify that the CLI extension version targeted by this guide no longer requires it. (learn.microsoft.com)
az network firewall update \
--name "$FIREWALL_NAME" \
--resource-group "$RESOURCE_GROUP"🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@modules/networking/pages/byoc/azure/azure-hub-egress.adoc` around lines 270 -
285, Update the firewall deployment sequence after `az network firewall
ip-config create` and before collecting or using its frontend IP by adding the
`az network firewall update` step for `$FIREWALL_NAME` and `$RESOURCE_GROUP`.
Alternatively, verify and document that the targeted CLI extension version no
longer requires this step.
| == Plan for high availability | ||
|
|
||
| The Azure Firewall Standard tier deployed by this guide already runs as a managed, zone-resilient service, but it is a single point of egress for every peered spoke. For production deployments: | ||
|
|
||
| * Deploy the firewall across availability zones by setting zones on the firewall and its public IP, if your region supports zones. | ||
| * Consider the Premium tier if you need TLS inspection or IDPS on egress traffic. | ||
| * Monitor firewall health and throughput using Azure Monitor metrics for the `Microsoft.Network/azureFirewalls` resource. | ||
|
|
||
| The <<automated-alternative,Terraform reference module>> deploys a single-zone Standard-tier firewall. Extend it with zone redundancy or the Premium tier if you need more resilience or inspection. |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect the referenced section with line numbers.
sed -n '345,375p' modules/networking/pages/byoc/azure/azure-hub-egress.adocRepository: redpanda-data/cloud-docs
Length of output: 1999
🌐 Web query:
Azure Firewall availability zones automatic zone-redundant new firewalls regions that support zones standard tier public IP docs
💡 Result:
Azure Firewall supports availability zones across its Basic, Standard, and Premium tiers [1][2]. Key details regarding availability zones and zone-redundancy for Azure Firewall include: Automatic Zone-Redundancy: In all Azure regions that support multiple availability zones, new Azure Firewall deployments are automatically zone-redundant by default [3][4]. This means the firewall instances are distributed across at least two availability zones to provide high availability and resiliency without requiring extra manual configuration [4][1]. Deployment and Configuration: - Default Behavior: When you create a new firewall in a region that supports availability zones, you do not need to specify zones to achieve zone-redundancy; the platform handles it automatically [3][4]. - Manual Control: While automatic, you can still explicitly specify availability zones during deployment if you choose, or opt to deploy into a single specific zone for proximity reasons [3][1]. - Public IP Requirements: When deploying a firewall with availability zones, ensure your public IP addresses are also configured with the same zone-redundancy (i.e., zone-redundant public IPs) [5]. - Limitations: In regions with specific zonal restrictions (e.g., due to capacity), a zone-redundant deployment might fail. In such cases, you can deploy to a single zone or a different region [3][5]. SLA Benefits: Deploying a firewall across multiple availability zones (zone-redundant) provides a 99.99% uptime SLA [3]. Regional Support: Azure Firewall supports availability zones in any Azure region that offers availability zones [3][4]. You should consult the official Azure documentation for the most current list of regional support, as the global footprint is continually expanding [6]. Existing Firewalls: Azure has performed platform-wide migrations for existing firewalls that did not have specific zones configured, converting them to be zone-redundant in supported regions. Existing firewalls that were specifically deployed into a single zone are not migrated automatically [3].
Citations:
- 1: https://learn.microsoft.com/en-us/azure/firewall/features-by-sku
- 2: https://learn.microsoft.com/en-us/azure/firewall/choose-firewall-sku
- 3: https://learn.microsoft.com/en-us/azure/firewall/deploy-availability-zone-powershell
- 4: https://learn.microsoft.com/en-us/azure/reliability/reliability-firewall
- 5: https://learn.microsoft.com/en-us/troubleshoot/azure/firewall/firewall-known-issues
- 6: https://github.com/MicrosoftDocs/azure-docs/blob/b1d16e529cc52d44f961e1387a3952c765b403e2/articles/reliability/regions-list.md
Clarify the zone-redundancy guidance. New Azure Firewalls are zone-redundant by default in regions that support availability zones, so call out that default behavior and reserve explicit zone settings for single-zone deployments or regions without zone support.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@modules/networking/pages/byoc/azure/azure-hub-egress.adoc` around lines 358 -
366, Update the “Plan for high availability” section to state that new Azure
Firewall deployments are zone-redundant by default in regions supporting
availability zones. Clarify that explicit zone settings are only needed for
single-zone deployments or regions without zone support, and align the Terraform
reference module guidance with this behavior.
| * You have created the VNet peering from the hub to the Redpanda spoke VNet, with `allow_forwarded_traffic` enabled on both sides and `allow_gateway_transit` enabled on the hub side. | ||
| * Your hub VNet address space and the planned Redpanda spoke VNet address space do not overlap. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n== File list ==\n'
git ls-files modules/networking/pages/byoc/azure/nat-free-egress.adoc modules/networking/pages/byoc/azure/azure-hub-egress.adoc
printf '\n== nat-free-egress.adoc (around cited lines) ==\n'
sed -n '70,120p' modules/networking/pages/byoc/azure/nat-free-egress.adoc
printf '\n== azure-hub-egress.adoc (around cited lines) ==\n'
sed -n '285,330p' modules/networking/pages/byoc/azure/azure-hub-egress.adoc
printf '\n== Search for allow-gateway-transit / allow-forwarded-traffic usage ==\n'
rg -n "allow-gateway-transit|allow_forwarded_traffic|forwarded traffic|gateway transit" modules/networking/pages/byoc/azureRepository: redpanda-data/cloud-docs
Length of output: 7725
🌐 Web query:
Azure virtual network peering allow-forwarded-traffic allow-gateway-transit documentation forwarded traffic gateway transit separate semantics
💡 Result:
In Azure virtual network (VNet) peering, allowForwardedTraffic and allowGatewayTransit are distinct settings that control different aspects of network traffic routing [1][2]. allowForwardedTraffic This setting determines whether a VNet will accept traffic that does not originate from within the directly peered VNet [1][3]. By default, this is disabled [1]. Enabling this is necessary in scenarios where you have network virtual appliances (NVAs) or other routing configurations that forward traffic from external sources (such as other peered networks or on-premises environments) into the local VNet through the peering [1]. It essentially tells the local VNet to permit packets where the source IP address belongs to a range outside of the directly peered VNet [1]. allowGatewayTransit This setting is a property of the peering connection that permits a VNet to use a VPN gateway or ExpressRoute gateway residing in the peered (remote) VNet [4][5]. Enabling this allows the peered VNet to act as a transit point for connectivity to on-premises networks or other VNets [4][6]. - For this to function, the gateway-hosting VNet must have allowGatewayTransit enabled [1][7]. - The VNet using the gateway must have the useRemoteGateways property set to true [3][2]. - A VNet cannot use a remote gateway if it already has its own local gateway configured [4][1]. Summary of Differences The key distinction is that allowForwardedTraffic manages the acceptance of traffic forwarded by internal network components (like NVAs) [1], whereas allowGatewayTransit manages the architectural ability of a VNet to leverage the routing infrastructure (gateway) of another VNet for external connectivity [4][5]. They are independent settings that serve different networking requirements in hub-and-spoke or complex topology designs [5][6].
Citations:
- 1: https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-manage-peering
- 2: https://learn.microsoft.com/en-us/rest/api/virtualnetwork/virtual-network-peerings/create-or-update?view=rest-virtualnetwork-2025-05-01
- 3: https://learn.microsoft.com/en-us/azure/templates/microsoft.network/2025-05-01/virtualnetworks/virtualnetworkpeerings
- 4: https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview
- 5: https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-peering-gateway-transit
- 6: https://learn.microsoft.com/en-us/training/modules/configure-vnet-peering/3-determine-gateway-transit-connectivity
- 7: https://learn.microsoft.com/en-us/powershell/module/az.network/set-azvirtualnetworkpeering?view=azps-15.5.0
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n== nat-free-egress.adoc (around lines 35-70) ==\n'
sed -n '35,70p' modules/networking/pages/byoc/azure/nat-free-egress.adoc
printf '\n== nat-free-egress.adoc (around lines 180-210) ==\n'
sed -n '180,210p' modules/networking/pages/byoc/azure/nat-free-egress.adoc
printf '\n== azure-hub-egress.adoc (around lines 1-60) ==\n'
sed -n '1,60p' modules/networking/pages/byoc/azure/azure-hub-egress.adocRepository: redpanda-data/cloud-docs
Length of output: 8271
Separate gateway transit from Azure Firewall forwarding. allow_forwarded_traffic is what lets the spoke’s UDR to the firewall cross the peering; allow_gateway_transit should only be required when the hub is actually exporting a VPN/ExpressRoute gateway.
📍 Affects 2 files
modules/networking/pages/byoc/azure/nat-free-egress.adoc#L84-L85(this comment)modules/networking/pages/byoc/azure/nat-free-egress.adoc#L101-L106modules/networking/pages/byoc/azure/azure-hub-egress.adoc#L293-L321
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@modules/networking/pages/byoc/azure/nat-free-egress.adoc` around lines 84 -
85, The Azure peering prerequisites incorrectly conflate gateway transit with
Azure Firewall forwarding. In
modules/networking/pages/byoc/azure/nat-free-egress.adoc lines 84-85, document
allow_forwarded_traffic for the firewall path and make allow_gateway_transit
conditional on exporting a VPN/ExpressRoute gateway; apply the corresponding
clarification at lines 101-106. Update
modules/networking/pages/byoc/azure/azure-hub-egress.adoc lines 293-321
consistently, preserving gateway transit only for hub gateway scenarios.
| [WARNING] | ||
| ==== | ||
| Azure rejects VNet peering when address spaces overlap. Use a non-overlapping range for your hub. The `10.255.0.0/16` range is a safe default because it rarely conflicts with typical RFC 1918 workload CIDRs. For background, see xref:networking:cidr-ranges.adoc#what-are-cidrs[What are CIDRs?] | ||
| ==== |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Do not describe 10.255.0.0/16 as safe by default.
modules/networking/pages/byoc/azure/nat-free-egress.adoc#L87-L90: call it an example only and require overlap checks.modules/networking/pages/byoc/azure/azure-hub-egress.adoc#L67-L73: update the default-values note to warn that the range may conflict with enterprise RFC 1918 networks.
📍 Affects 2 files
modules/networking/pages/byoc/azure/nat-free-egress.adoc#L87-L90(this comment)modules/networking/pages/byoc/azure/azure-hub-egress.adoc#L67-L73
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@modules/networking/pages/byoc/azure/nat-free-egress.adoc` around lines 87 -
90, Update the warning in
modules/networking/pages/byoc/azure/nat-free-egress.adoc lines 87-90 to present
10.255.0.0/16 only as an example and require users to verify it does not overlap
existing network ranges. Update the default-values note in
modules/networking/pages/byoc/azure/azure-hub-egress.adoc lines 67-73 to warn
that this range may conflict with enterprise RFC 1918 networks.
| == Configure egress at network creation | ||
|
|
||
| Centralized egress is set at network creation. Complete all hub-side setup, including the VNet peering and Azure Firewall, before you create the network. See xref:networking:byoc/azure/azure-hub-egress.adoc[Create an Azure Hub for Centralized Egress]. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Document the dependency order consistently.
The spoke VNet cannot be peered until Redpanda creates it.
modules/networking/pages/byoc/azure/nat-free-egress.adoc#L119-L121: remove the requirement to finish peering before network creation.modules/manage/partials/controlplane-api.adoc#L188-L188: change “provision ... VNet peering” to occur after the network request.modules/networking/pages/byoc/azure/azure-hub-egress.adoc#L46-L52: state that the hub/firewall is prepared first and the spoke ID is collected afterward.modules/networking/pages/byoc/azure/azure-hub-egress.adoc#L289-L297: make the hub-side peering step explicitly post-network provisioning.
📍 Affects 3 files
modules/networking/pages/byoc/azure/nat-free-egress.adoc#L119-L121(this comment)modules/manage/partials/controlplane-api.adoc#L188-L188modules/networking/pages/byoc/azure/azure-hub-egress.adoc#L46-L52modules/networking/pages/byoc/azure/azure-hub-egress.adoc#L289-L297
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@modules/networking/pages/byoc/azure/nat-free-egress.adoc` around lines 119 -
121, Update the Azure centralized-egress documentation to consistently reflect
dependency order: in modules/networking/pages/byoc/azure/nat-free-egress.adoc
lines 119-121, remove the requirement to complete VNet peering before network
creation; in modules/manage/partials/controlplane-api.adoc line 188, state that
VNet peering is provisioned after the network request; in
modules/networking/pages/byoc/azure/azure-hub-egress.adoc lines 46-52, explain
that the hub and firewall are prepared first and the spoke ID is collected
afterward; and in lines 289-297, explicitly identify hub-side peering as
occurring after network provisioning.
| Set `egress_spec.azure.hub_vnet_id` and `egress_spec.azure.firewall_private_ip` on the Network resource when you create a network. Both fields are required when `egress_spec.azure` is set. | ||
|
|
||
| [,bash] | ||
| ---- | ||
| curl -X POST https://api.redpanda.com/v1/networks \ | ||
| -H "Authorization: Bearer $REDPANDA_CLOUD_TOKEN" \ | ||
| -H "Content-Type: application/json" \ | ||
| -d '{ | ||
| "name": "prod-eastus2", | ||
| "cloud_provider": "CLOUD_PROVIDER_AZURE", | ||
| "region": "eastus2", | ||
| "cidr_block": "10.0.0.0/20", | ||
| "cluster_type": "TYPE_BYOC", | ||
| "egress_spec": { | ||
| "azure": { | ||
| "hub_vnet_id": "/subscriptions/<hub-subscription-id>/resourceGroups/hub-egress-rg/providers/Microsoft.Network/virtualNetworks/hub-vnet", | ||
| "firewall_private_ip": "10.255.0.4" | ||
| } | ||
| } | ||
| }' |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Align the Azure network request envelope across both guides.
The same /v1/networks request is documented with incompatible JSON shapes.
modules/networking/pages/byoc/azure/nat-free-egress.adoc#L140-L159: wrap the request fields under the API’s expected"network"object.modules/manage/partials/controlplane-api.adoc#L188-L209: retain the canonical envelope and ensure the Azure example matches the actual API schema.
📍 Affects 2 files
modules/networking/pages/byoc/azure/nat-free-egress.adoc#L140-L159(this comment)modules/manage/partials/controlplane-api.adoc#L188-L209
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@modules/networking/pages/byoc/azure/nat-free-egress.adoc` around lines 140 -
159, Align both Azure network examples with the API’s canonical request
envelope: in modules/networking/pages/byoc/azure/nat-free-egress.adoc lines
140-159, wrap the existing request fields under a network object; in
modules/manage/partials/controlplane-api.adoc lines 188-209, retain that
canonical envelope and update the Azure example fields to match the actual API
schema. Use the same envelope and Azure field structure in both examples.
| [#internet-endpoints] | ||
| == Internet endpoints required from your hub | ||
|
|
||
| Your hub Azure Firewall must provide internet egress for the following endpoints. If your firewall policy enforces an allowlist, allow outbound traffic to these endpoints from the Redpanda spoke address space: | ||
|
|
||
| [cols="1,1,2"] | ||
| |=== | ||
| | Endpoint | Protocol and port | Purpose | ||
|
|
||
| | `docker.cloudsmith.io` | TCP/443 | Redpanda container images | ||
| | `mcr.microsoft.com` | TCP/443 | AKS system images (CNI, kube-proxy, and other cluster add-ons) | ||
| | NTP servers | UDP/123 | Time sync | ||
| | `prometheus-community.github.io` and similar Helm repositories | TCP/443 | Monitoring stack Helm charts | ||
| |=== |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n## Files\n'
git ls-files modules/networking/pages/byoc/azure/*.adoc
printf '\n## Outline nat-free-egress.adoc\n'
ast-grep outline modules/networking/pages/byoc/azure/nat-free-egress.adoc --view expanded || true
printf '\n## Outline azure-hub-egress.adoc\n'
ast-grep outline modules/networking/pages/byoc/azure/azure-hub-egress.adoc --view expanded || true
printf '\n## Relevant line ranges\n'
sed -n '130,230p' modules/networking/pages/byoc/azure/nat-free-egress.adoc
printf '\n---\n'
sed -n '160,280p' modules/networking/pages/byoc/azure/azure-hub-egress.adoc
printf '\n## Search for DNS proxy / FQDN filtering references\n'
rg -n "DNS proxy|dns-proxy|FQDN|fqdn|allowlist|AllowAll|network rules|application rules|Azure Firewall" modules/networking/pages/byoc/azure -SRepository: redpanda-data/cloud-docs
Length of output: 17423
🌐 Web query:
Azure Firewall FQDN filtering network rules DNS proxy required documentation
💡 Result:
Yes, enabling the DNS proxy feature is required to use FQDN filtering in Azure Firewall network rules [1][2]. To ensure reliable and consistent FQDN filtering, Microsoft provides the following requirements and best practices: 1. Enable DNS Proxy: You must enable the DNS proxy setting in your Azure Firewall or Firewall Policy DNS settings [3][4]. When enabled, the firewall listens on port 53 and forwards DNS requests to configured upstream servers [3][4]. 2. Configure Client DNS: To prevent DNS resolution inconsistencies—where a client might resolve a domain to an IP address different from what the firewall sees—you must configure your client virtual machines (typically via the virtual network's DNS server settings) to use the Azure Firewall's private IP address as their DNS resolver [3][5][4]. 3. How it works: The firewall resolves the FQDN to an IP address (or addresses) and updates its network rules accordingly [1][6]. By acting as the DNS proxy for your clients, the firewall ensures that both the client and the firewall are working with the same resolution results, preventing traffic from being incorrectly denied [3][6][5]. If you use Infrastructure-as-Code (such as Bicep, ARM, or Terraform), you must explicitly set properties such as enableProxy to true and ensure the policy configuration supports FQDNs in network rules [7]. For HTTP/S or MSSQL protocols, Microsoft recommends using application rules instead of network rules for FQDN filtering, as application rules utilize a transparent proxy and SNI headers, providing more robust filtering capabilities [1][2].
Citations:
- 1: https://learn.microsoft.com/en-us/azure/firewall/fqdn-filtering-network-rules
- 2: https://learn.microsoft.com/en-us/azure/firewall-manager/fqdn-filtering-network-rules
- 3: https://learn.microsoft.com/en-us/azure/firewall/dns-settings
- 4: https://learn.microsoft.com/en-us/azure/firewall-manager/dns-settings
- 5: https://learn.microsoft.com/en-us/samples/azure/azure-quickstart-templates/azure-firewall-dns-proxy/
- 6: https://learn.microsoft.com/en-us/azure/firewall/dns-details
- 7: https://learn.microsoft.com/en-us/azure/templates/microsoft.network/firewallpolicies
Clarify the allowlist guidance.
modules/networking/pages/byoc/azure/nat-free-egress.adoc#L165-L178: say which Azure Firewall rule type to use for the hostname-based entries, and note the DNS-proxy setup needed for FQDN filtering.modules/networking/pages/byoc/azure/azure-hub-egress.adoc#L188-L234: markAllowAllas bootstrap-only, or replace it with a restricted example, so the default policy doesn’t read like a production allowlist.
📍 Affects 2 files
modules/networking/pages/byoc/azure/nat-free-egress.adoc#L165-L178(this comment)modules/networking/pages/byoc/azure/azure-hub-egress.adoc#L188-L234
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@modules/networking/pages/byoc/azure/nat-free-egress.adoc` around lines 165 -
178, The Internet endpoints section in
modules/networking/pages/byoc/azure/nat-free-egress.adoc lines 165-178 must
identify Azure Firewall application rules for hostname-based entries and
document the DNS proxy configuration required for FQDN filtering. In
modules/networking/pages/byoc/azure/azure-hub-egress.adoc lines 188-234, mark
the AllowAll policy as bootstrap-only or replace it with a restricted
production-oriented example so it is not presented as the default allowlist.
| == DNS resolution | ||
|
|
||
| Centralized egress does not affect DNS resolution. The Redpanda VNet uses Azure-provided DNS, which resolves both internal and external hostnames as long as `0.0.0.0/0` is routable through your hub. You do not need a separate DNS path or DNS resolver endpoint in your hub. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect the target file around the cited lines.
sed -n '160,205p' modules/networking/pages/byoc/azure/nat-free-egress.adoc
# Find any other DNS-related references in the page.
rg -n "DNS|168\.63\.129\.16|0\.0\.0\.0/0|resolver|custom DNS|Azure-provided" modules/networking/pages/byoc/azure/nat-free-egress.adocRepository: redpanda-data/cloud-docs
Length of output: 3596
🌐 Web query:
Azure-provided DNS 168.63.129.16 user-defined routes 0.0.0.0/0 custom DNS reachable path Microsoft documentation
💡 Result:
The Azure-provided DNS IP address, 168.63.129.16, is a static virtual IP used by the Azure platform to provide services, including DNS, to virtual machines [1][2]. According to Microsoft documentation, this IP address is a virtual IP of the host node and is not subject to user-defined routes (UDRs) [2][3]. Because communication to 168.63.129.16 occurs at the platform level, it bypasses UDRs [2][4]. Consequently, even if you implement a custom route for 0.0.0.0/0 (e.g., forcing traffic through a network virtual appliance), traffic destined for 168.63.129.16 will not be routed according to that UDR; it will continue to reach the Azure platform directly [2][5]. While UDRs do not affect reachability to this IP, other security controls still apply: 1. Network Security Groups (NSGs): DNS traffic to 168.63.129.16 can be blocked via NSGs if you target the AzurePlatformDNS service tag or explicitly deny outbound traffic on ports 53/TCP/UDP [2][5]. 2. Local Firewalls: You must ensure any local firewall policies on the virtual machine allow outbound communication to 168.63.129.16 if Azure-provided DNS is required [2][4]. If 168.63.129.16 becomes unreachable, it is often due to an explicit NSG deny rule or, in specific scenarios like VNet-integrated App Services, a misconfiguration in subnet delegation or unexpected routing behavior [5]. You should verify that no NSG rules are blocking the AzurePlatformDNS service tag and confirm that your networking configuration does not otherwise interfere with this platform-level communication [2][5].
Citations:
- 1: https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances
- 2: https://learn.microsoft.com/en-us/azure/virtual-network/what-is-ip-address-168-63-129-16
- 3: https://learn.microsoft.com/en-us/answers/questions/993401/azure-vm-cannot-telnet-to-port-80-on-168-63-129-16
- 4: https://acloudguy.com/2025/09/07/understanding-azures-special-ip-address-168-63-129-16/
- 5: https://learn.microsoft.com/en-us/answers/questions/5839349/azure-dns-(168-63-129-16)-unreachable-from-vnet-in
Clarify the DNS dependency. Azure-provided DNS (168.63.129.16) bypasses UDRs, so resolution doesn’t depend on 0.0.0.0/0 being routed through the hub. If custom DNS is supported here, call out that it needs its own reachable path.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@modules/networking/pages/byoc/azure/nat-free-egress.adoc` around lines 180 -
182, Update the DNS resolution section to state that Azure-provided DNS at
168.63.129.16 bypasses UDRs and does not depend on 0.0.0.0/0 being routed
through the hub. If custom DNS is supported, document that it requires a
separate reachable network path; otherwise remove the implication that hub
routing controls DNS resolution.
1 participant
Add hub setup and configuration pages for the beta NAT Gateway-free egress feature on Azure, mirroring the existing AWS Transit Gateway and GCP VPC Peering equivalents. Unlike AWS/GCP, this is API-only today (no Cloud UI support), so the pages route through the Cloud API using egress_spec.azure.hub_vnet_id and firewall_private_ip.
Description
Resolves https://redpandadata.atlassian.net/browse/DOC-2384
Page previews
https://deploy-preview-643--rp-cloud.netlify.app/cloud-data-platform/networking/byoc/azure/azure-hub-egress/
https://deploy-preview-643--rp-cloud.netlify.app/cloud-data-platform/networking/byoc/azure/nat-free-egress/
https://deploy-preview-643--rp-cloud.netlify.app/cloud-data-platform/get-started/cluster-types/byoc/azure/create-byoc-cluster-azure/
https://deploy-preview-643--rp-cloud.netlify.app/cloud-data-platform/get-started/whats-new-cloud/
https://deploy-preview-643--rp-cloud.netlify.app/cloud-data-platform/get-started/cloud-overview/#features-in-beta
Checks