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
✅ Deploy Preview for rp-cloud ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 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
| * 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.
67c460a to
caee206
Compare
|
@ppanagiotis I think we should also provide Terraform based docs as well, do you know how the TF provider is progressing? |
I will work on update the Terraform providers next week. And I will update docs also. |
PR Review (docs-team-standards)Critical issues (must fix)
Suggestions (should consider)
|
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 <[email protected]>
PR Review, round 2 (docs-team-standards)Thanks for the quick turnaround — the latest push addresses everything from my last review and all of the CodeRabbit comments. I verified the API surface this time (request envelopes, required fields, the Critical issues (must fix)
Suggestions (should consider)
What works well
Happy to push these edits to |
3 participants
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