diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index 78d6a9346..e555d91b2 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -486,6 +486,8 @@ *** xref:networking:byoc/azure/index.adoc[Azure] **** xref:networking:azure-private-link-in-ui.adoc[] **** xref:networking:azure-private-link.adoc[] +**** xref:networking:byoc/azure/nat-free-egress.adoc[Configure Centralized Egress] +**** xref:networking:byoc/azure/azure-hub-egress.adoc[Create an Azure Hub for Centralized Egress] *** xref:networking:byoc/gcp/index.adoc[GCP] **** xref:networking:byoc/gcp/vpc-peering-gcp.adoc[Add a Peering Connection] **** xref:networking:configure-private-service-connect-in-cloud-ui.adoc[Configure Private Service Connect in the Cloud Console] diff --git a/modules/get-started/pages/cloud-overview.adoc b/modules/get-started/pages/cloud-overview.adoc index 634e60710..0708427f7 100644 --- a/modules/get-started/pages/cloud-overview.adoc +++ b/modules/get-started/pages/cloud-overview.adoc @@ -400,7 +400,7 @@ The following features are currently in beta in Redpanda Cloud: * BYOVNet for Azure * Secrets management for BYOVPC on GCP -* Centralized egress for BYOC on AWS and GCP +* Centralized egress for BYOC on AWS, GCP, and Azure * Several Redpanda Connect components include::shared:partial$suggested-video.adoc[] diff --git a/modules/get-started/pages/cluster-types/byoc/azure/create-byoc-cluster-azure.adoc b/modules/get-started/pages/cluster-types/byoc/azure/create-byoc-cluster-azure.adoc index d229b5055..65f518379 100644 --- a/modules/get-started/pages/cluster-types/byoc/azure/create-byoc-cluster-azure.adoc +++ b/modules/get-started/pages/cluster-types/byoc/azure/create-byoc-cluster-azure.adoc @@ -169,6 +169,11 @@ Optionally, click *Advanced settings* to specify up to five key-value custom tag Private access incurs an additional cost, since it involves deploying two network load balancers, instead of one. + NOTE: After the cluster is created, you can change the API Gateway access on the Dataplane settings page. If you change from public to private access, users without VPN access to the Redpanda VPC will lose access to these services. ++ +[TIP] +==== +To route all cluster egress through your own Azure Firewall and hub VNet instead of a per-cluster NAT Gateway, set `egress_spec.azure.hub_vnet_id` and `egress_spec.azure.firewall_private_ip` when you create the network with the Cloud API. This option is only available on clusters with a private connection type and a Redpanda-managed VNet, and is only enabled if centralized egress is enabled for your organization. This option is in beta and does not yet have Cloud UI support. See xref:networking:byoc/azure/nat-free-egress.adoc[]. +==== . Click *Next*. . On the Deploy page, follow the steps to log in to Redpanda Cloud and deploy the agent. + diff --git a/modules/get-started/pages/whats-new-cloud.adoc b/modules/get-started/pages/whats-new-cloud.adoc index 41d3fa830..5c0374998 100644 --- a/modules/get-started/pages/whats-new-cloud.adoc +++ b/modules/get-started/pages/whats-new-cloud.adoc @@ -18,6 +18,10 @@ For xref:reference:tiers/byoc-tiers.adoc#byoc-supported-regions[BYOC clusters], * ap-northeast-2 (Seoul) * ap-south-2 (Hyderabad) +======= +=== Centralized egress for BYOC on Azure: beta + +You can route all Azure BYOC cluster egress through your own Azure Firewall and hub VNet instead of a per-cluster NAT Gateway, so outbound traffic exits through your centralized inspection point. This is useful for regulated environments that require a single, predictable public IP for outbound allowlisting or that prohibit per-cluster NAT Gateways. Centralized egress is in a glossterm:beta[] release, is enabled per organization, and is configured through the Cloud API. Contact your account team for access. See xref:networking:byoc/azure/nat-free-egress.adoc[Configure Centralized Egress with Azure Firewall]. === Improved Serverless trial onboarding diff --git a/modules/manage/partials/controlplane-api.adoc b/modules/manage/partials/controlplane-api.adoc index 770e734ac..a80a52a2e 100644 --- a/modules/manage/partials/controlplane-api.adoc +++ b/modules/manage/partials/controlplane-api.adoc @@ -133,7 +133,9 @@ curl -d \ // To enable, set the attribute in the playbook or in this page header. // The GCP BYOC network example adds `egress_spec.gcp.hub_vpc_project` and // `egress_spec.gcp.hub_vpc_name` for centralized egress through a hub VPC. -// Also gated behind `:show-preview-api:`. +// The Azure BYOC network example adds `egress_spec.azure.hub_vnet_id` and +// `egress_spec.azure.firewall_private_ip` for centralized egress through a +// hub VNet and Azure Firewall. All are gated behind `:show-preview-api:`. ifdef::show-preview-api[] To route all cluster egress through your own AWS Transit Gateway and hub VPC instead of a per-VPC NAT Gateway, set `egress_spec.aws.transit_gateway_id` on an AWS BYOC network. Centralized egress is in beta. Before calling this endpoint, provision the hub VPC and Transit Gateway and share the Transit Gateway with the Redpanda cluster account. See xref:networking:byoc/aws/aws-hub-egress.adoc[Create an AWS Hub for Centralized Egress] and xref:networking:byoc/aws/nat-free-egress.adoc[Configure Centralized Egress with AWS Transit Gateway]. @@ -182,6 +184,30 @@ curl -d \ }' -H "Content-Type: application/json" \ -H "Authorization: Bearer " -X POST https://api.redpanda.com/v1/networks ---- + +To route all cluster egress through your own Azure Firewall and hub VNet instead of a per-cluster NAT Gateway, set `egress_spec.azure.hub_vnet_id` and `egress_spec.azure.firewall_private_ip` on an Azure BYOC network. Centralized egress is in beta. Before calling this endpoint, provision the hub VNet and Azure Firewall. Create the VNet peering to the Redpanda spoke VNet after this network is provisioned, once the spoke VNet's resource ID is available. See xref:networking:byoc/azure/azure-hub-egress.adoc[Create an Azure Hub for Centralized Egress] and xref:networking:byoc/azure/nat-free-egress.adoc[Configure Centralized Egress with Azure Firewall]. + +[,bash] +---- +curl -d \ +'{ + "network": { + "cidr_block": "10.0.0.0/20", + "cloud_provider": "CLOUD_PROVIDER_AZURE", + "cluster_type": "TYPE_BYOC", + "name": "", + "resource_group_id": "", + "region": "eastus2", + "egress_spec": { + "azure": { + "hub_vnet_id": "/subscriptions//resourceGroups/hub-egress-rg/providers/Microsoft.Network/virtualNetworks/hub-vnet", + "firewall_private_ip": "10.255.0.4" + } + } + } +}' -H "Content-Type: application/json" \ +-H "Authorization: Bearer " -X POST https://api.redpanda.com/v1/networks +---- endif::[] endif::[] diff --git a/modules/networking/pages/byoc/azure/azure-hub-egress.adoc b/modules/networking/pages/byoc/azure/azure-hub-egress.adoc new file mode 100644 index 000000000..0509af0c0 --- /dev/null +++ b/modules/networking/pages/byoc/azure/azure-hub-egress.adoc @@ -0,0 +1,395 @@ += Create an Azure Hub for Centralized Egress +:description: Provision a hub VNet and Azure Firewall so one or more BYOC clusters can route their internet egress through a single, predictable public IP. +:page-beta: true +:page-topic-type: how-to +:personas: platform_admin +:learning-objective-1: Provision a hub VNet with Azure Firewall +:learning-objective-2: Configure VNet peering so the hub exports connectivity to Redpanda spoke VNets +:learning-objective-3: Collect the hub VNet ID and firewall IPs needed for BYOC cluster configuration + +Use this guide to provision the customer-side infrastructure required for centralized egress on a Redpanda Bring Your Own Cloud (BYOC) cluster on Azure. After completing the procedure, you have a hub VNet with an Azure Firewall, a VNet peering to the Redpanda spoke VNet, and the IDs needed to configure your BYOC network. You can then follow xref:networking:byoc/azure/nat-free-egress.adoc[Configure Centralized Egress with Azure Firewall] to enable centralized egress at cluster creation. + +After reading this page, you will be able to: + +* [ ] {learning-objective-1} +* [ ] {learning-objective-2} +* [ ] {learning-objective-3} + +== What this sets up + +A hub VNet with Azure Firewall provides centralized internet egress for one or more Redpanda spoke VNets. All outbound traffic from clusters is routed through the hub and exits from a single, predictable public IP. + +---- +Redpanda BYOC VNet --> VNet Peering --> Hub VNet --> Azure Firewall --> Internet + (Route Table: 0.0.0.0/0 -> firewall private IP) +---- + +Traffic path: + +. Redpanda spoke subnets have a Route Table (UDR) with a `0.0.0.0/0` route pointing at the Azure Firewall's private IP. +. The route crosses the VNet peering into the hub VNet because both peerings allow forwarded traffic. +. The Azure Firewall in the hub receives the packet, evaluates it against its policy rules, and performs SNAT to its public IP. +. Return traffic arrives at the firewall's public IP. The firewall reverses the SNAT and forwards the packet back across the peering to the originating spoke subnet. + +[NOTE] +==== +Redpanda creates and manages the Route Table (UDR) on the spoke subnets, not you. This hub setup only needs to provide the Azure Firewall's private IP as the next hop, and the VNet peering that lets spoke traffic reach it. +==== + +[#automated-alternative] +== Automated alternative + +If you prefer to provision this infrastructure with Terraform, the configuration used to produce the setup in this guide is published in the Redpanda Cloud Examples repository: link:https://github.com/redpanda-data/cloud-examples/tree/main/azure-hub-egress[azure-hub-egress^] + +The rest of this guide covers the equivalent steps using the Azure Portal or Azure CLI. + +[#prerequisites] +== Prerequisites + +* The `az` CLI, configured with credentials for the hub subscription. +* Network Contributor permissions in the hub subscription. +* The Redpanda spoke VNet CIDR must not overlap your hub VNet CIDR. +* The Azure resource ID of the Redpanda spoke VNet, visible in the Redpanda Cloud console after the network is created, in the form `/subscriptions//resourceGroups//providers/Microsoft.Network/virtualNetworks/`. +* Centralized egress requires a Redpanda-managed VNet. It is not compatible with xref:get-started:cluster-types/byoc/azure/vnet-azure.adoc[BYOVNet clusters]. + +You provision the hub VNet and Azure Firewall first, then give Redpanda the hub VNet ID and firewall private IP to create the BYOC network with centralized egress. The Redpanda spoke VNet's resource ID becomes available only after that network is created, so you create the hub-side peering (see <>) after network creation, not before. + +[WARNING] +==== +Hub and spoke VNet CIDRs must not overlap. Azure rejects VNet peering when CIDRs conflict. Plan your CIDRs before you start. For background, see xref:networking:cidr-ranges.adoc#what-are-cidrs[What are CIDRs?] +==== + +== Default values + +The procedure uses the values in the following table. Replace any value that does not match your environment. + +[cols="2,2,3"] +|=== +| Parameter | Default | Notes + +| Hub subscription | `` | Replace with your Azure subscription ID +| Hub resource group | `hub-egress-rg` | +| Hub VNet name | `hub-vnet` | +| Hub VNet address space | `10.255.0.0/16` | Example only. It is a normal RFC 1918 range, so verify it does not conflict with existing enterprise networks before using it. +| Firewall subnet CIDR | `10.255.0.0/26` | Must be named exactly `AzureFirewallSubnet` and be at least `/26` +| Region | `eastus2` | Replace with your target region +| Spoke VNet resource ID | `/subscriptions//resourceGroups//providers/Microsoft.Network/virtualNetworks/` | Visible in the Redpanda Cloud console +|=== + +== Set environment variables + +Set these variables once and reuse them throughout the guide. + +[,bash] +---- +HUB_SUBSCRIPTION_ID="" +LOCATION="eastus2" +RESOURCE_GROUP="hub-egress-rg" +VNET_NAME="hub-vnet" +VNET_CIDR="10.255.0.0/16" +FIREWALL_SUBNET_CIDR="10.255.0.0/26" +FIREWALL_NAME="hub-fw" +FIREWALL_POLICY_NAME="hub-fw-policy" +FIREWALL_PIP_NAME="hub-fw-pip" + +az account set --subscription "$HUB_SUBSCRIPTION_ID" + +# Fill in after the Redpanda cluster network is provisioned +SPOKE_VNET_ID="/subscriptions//resourceGroups//providers/Microsoft.Network/virtualNetworks/" +PEERING_NAME="hub-to-redpanda-cluster-a" +---- + +== Create the hub resource group and VNet + +[tabs] +====== +Portal:: ++ +. Go to *Resource groups > Create*. +. Set the resource group name to `hub-egress-rg` and the region to `eastus2`. +. Click *Review + create*, then *Create*. +. Go to *Virtual networks > Create*. +. Select the `hub-egress-rg` resource group, set the name to `hub-vnet`, the region to `eastus2`, and the IPv4 address space to `10.255.0.0/16`. +. Click *Review + create*, then *Create*. You add the firewall subnet as a separate step. + +CLI:: ++ +[,bash] +---- +az group create \ + --name $RESOURCE_GROUP \ + --location $LOCATION + +az network vnet create \ + --name $VNET_NAME \ + --resource-group $RESOURCE_GROUP \ + --location $LOCATION \ + --address-prefix $VNET_CIDR + +echo "VNet created: $VNET_NAME" +---- +====== + +== Create the Azure Firewall subnet + +[NOTE] +==== +Azure requires this subnet to be named exactly `AzureFirewallSubnet`, and it must be at least `/26`. +==== + +[tabs] +====== +Portal:: ++ +. Open the `hub-vnet` VNet and go to *Subnets > + Subnet*. +. Set the name to `AzureFirewallSubnet`. +. Set the IPv4 address range to `10.255.0.0/26`. +. Click *Save*. + +CLI:: ++ +[,bash] +---- +az network vnet subnet create \ + --name AzureFirewallSubnet \ + --vnet-name $VNET_NAME \ + --resource-group $RESOURCE_GROUP \ + --address-prefixes $FIREWALL_SUBNET_CIDR + +echo "Firewall subnet created: AzureFirewallSubnet ($FIREWALL_SUBNET_CIDR)" +---- +====== + +== Reserve a public IP for the firewall + +This public IP becomes the single egress address for all Redpanda cluster traffic. + +[tabs] +====== +Portal:: ++ +. Go to *Public IP addresses > Create*. +. Set the name to `hub-fw-pip`, the SKU to *Standard*, and the assignment to *Static*. +. Select the `hub-egress-rg` resource group and the `eastus2` region. +. Click *Review + create*, then *Create*. + +CLI:: ++ +[,bash] +---- +az network public-ip create \ + --name $FIREWALL_PIP_NAME \ + --resource-group $RESOURCE_GROUP \ + --location $LOCATION \ + --sku Standard \ + --allocation-method Static + +echo "Public IP reserved: $FIREWALL_PIP_NAME" +---- +====== + +== Create the firewall policy + +The policy holds the network rules that control what the firewall allows to egress. The default rule in this guide allows all outbound traffic. Restrict it to the specific destinations your organization requires before using this hub in production. See xref:networking:byoc/azure/nat-free-egress.adoc#internet-endpoints[Internet endpoints required from your hub] for the minimum set Redpanda needs. + +[tabs] +====== +Portal:: ++ +. Go to *Firewall Policies > Create*. +. Set the name to `hub-fw-policy`, the resource group to `hub-egress-rg`, the region to `eastus2`, and the tier to *Standard*. +. Click *Review + create*, then *Create*. +. Open the policy and go to *Network rules > Add a rule collection*. +. Set the rule collection name to `AllowEgress`, the priority to `100`, and the action to *Allow*. +. Add a rule named `AllowAll` with protocol *Any*, source `*`, destination `*`, and destination ports `*`. Replace this with specific destinations before production use. +. Click *Add*. + +CLI:: ++ +[,bash] +---- +az network firewall policy create \ + --name $FIREWALL_POLICY_NAME \ + --resource-group $RESOURCE_GROUP \ + --location $LOCATION \ + --sku Standard + +az network firewall policy rule-collection-group create \ + --name DefaultRules \ + --policy-name $FIREWALL_POLICY_NAME \ + --resource-group $RESOURCE_GROUP \ + --priority 100 + +# Replace source-addresses/destination-addresses with specific ranges and +# endpoints before using this hub in production. +az network firewall policy rule-collection-group collection add-filter-collection \ + --resource-group $RESOURCE_GROUP \ + --policy-name $FIREWALL_POLICY_NAME \ + --rule-collection-group-name DefaultRules \ + --name AllowEgress \ + --collection-priority 100 \ + --action Allow \ + --rule-name AllowAll \ + --rule-type NetworkRule \ + --ip-protocols Any \ + --source-addresses '*' \ + --destination-addresses '*' \ + --destination-ports '*' + +echo "Firewall policy created: $FIREWALL_POLICY_NAME" +---- +====== + +== Create the Azure Firewall + +The firewall takes 5 to 10 minutes to provision. + +[NOTE] +==== +Azure Firewall Standard tier costs approximately $1.25 per hour while running. Destroy the firewall when you are not using it, or use the <> to make teardown repeatable. +==== + +[tabs] +====== +Portal:: ++ +. Go to *Firewalls > Create*. +. Select the `hub-egress-rg` resource group and set the name to `hub-fw`. +. Set the region to `eastus2`, the firewall tier to *Standard*, and the firewall management to *Use a Firewall Policy*. +. Select the existing `hub-fw-policy` policy. +. Under *Virtual network*, select `hub-vnet` (this populates from the `AzureFirewallSubnet` you created). +. Under *Public IP address*, select `hub-fw-pip`. +. Click *Review + create*, then *Create*. + +CLI:: ++ +[,bash] +---- +FIREWALL_POLICY_ID=$(az network firewall policy show \ + --name $FIREWALL_POLICY_NAME \ + --resource-group $RESOURCE_GROUP \ + --query id --output tsv) + +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 + +az network firewall update \ + --name $FIREWALL_NAME \ + --resource-group $RESOURCE_GROUP + +echo "Firewall created: $FIREWALL_NAME" +---- +====== + +[#peer-hub-vnet] +== Peer the hub VNet to the Redpanda spoke VNet + +Create this peering after the BYOC network has been provisioned with your hub's values, once the Redpanda spoke VNet's resource ID is available in the Redpanda Cloud console (see <>). Redpanda creates the reciprocal peering from the spoke side during cluster provisioning. + +[NOTE] +==== +Set `--allow-forwarded-traffic` on both sides so traffic that neither originates from nor is destined for the hub VNet's own address space (like the spoke's `0.0.0.0/0` route to the firewall) is allowed to cross the peering. This is what enables the Azure Firewall forwarding path; Redpanda sets the same flag on the reciprocal spoke-side peering. + +`--allow-gateway-transit` on the hub side is unrelated to firewall forwarding. It only lets the spoke use a VPN/ExpressRoute gateway attached to the hub VNet, and has no effect if the hub has no such gateway or the spoke doesn't opt in. It's safe to include even when the hub has no gateway. + +Both peerings must show `Connected` before traffic flows. The peering you create here stays in a non-connected state until Redpanda creates the reciprocal peering during cluster provisioning. +==== + +[tabs] +====== +Portal:: ++ +. Open the `hub-vnet` VNet and go to *Peerings > Add*. +. Set the peering link name (this VNet to remote VNet) to `hub-to-redpanda-cluster-a`. +. Under *Traffic to remote virtual network*, select *Allow*, and under *Traffic forwarded from remote virtual network*, select *Allow*. +. Under *Virtual network gateway*, select *Use this virtual network's gateway* if the hub has one (allows gateway transit to the spoke). +. For the remote virtual network, choose *Resource ID* and paste the Redpanda spoke VNet's resource ID. +. Set the peering link name for the remote VNet to this VNet as required by the portal, then click *Add*. + +CLI:: ++ +[,bash] +---- +az network vnet peering create \ + --name $PEERING_NAME \ + --resource-group $RESOURCE_GROUP \ + --vnet-name $VNET_NAME \ + --remote-vnet $SPOKE_VNET_ID \ + --allow-forwarded-traffic \ + --allow-gateway-transit + +echo "Peering created: $PEERING_NAME (hub -> $SPOKE_VNET_ID)" +echo "Status stays non-connected until Redpanda creates the reciprocal peering." +---- +====== + +[#collect-values] +== Collect the values to provide to Redpanda + +Record these values. Provide the hub VNet ID and the firewall's private IP when you configure centralized egress on your BYOC network. See xref:networking:byoc/azure/nat-free-egress.adoc[Configure Centralized Egress with Azure Firewall]. + +[,bash] +---- +HUB_VNET_ID=$(az network vnet show \ + --name $VNET_NAME \ + --resource-group $RESOURCE_GROUP \ + --query id --output tsv) + +FIREWALL_PRIVATE_IP=$(az network firewall show \ + --name $FIREWALL_NAME \ + --resource-group $RESOURCE_GROUP \ + --query 'ipConfigurations[0].privateIPAddress' --output tsv) + +FIREWALL_PUBLIC_IP=$(az network public-ip show \ + --name $FIREWALL_PIP_NAME \ + --resource-group $RESOURCE_GROUP \ + --query ipAddress --output tsv) + +echo "hub_vnet_id = $HUB_VNET_ID" +echo "hub_resource_group = $RESOURCE_GROUP" +echo "firewall_private_ip = $FIREWALL_PRIVATE_IP" +echo "firewall_public_ip = $FIREWALL_PUBLIC_IP" +---- + +All outbound internet traffic from every BYOC spoke that peers to this hub exits from the same firewall public IP. Use that public IP for outbound IP allowlisting on external services. + +== Plan for high availability + +New Azure Firewall deployments are zone-redundant by default in regions that support availability zones: Azure spreads the firewall (and a Standard SKU public IP) across multiple zones automatically, with no `zones` parameter required. You only need to set zones explicitly if you want a single-zone deployment, or if your target region does not support availability zones. The firewall is still a single point of egress for every peered spoke, so for production deployments: + +* Confirm your target region supports availability zones so the firewall and its public IP get zone-redundant placement by default. +* 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 <> does not set an explicit `zones` argument on the firewall or its public IP, so it inherits the same zone-redundant default in regions that support it. Only add explicit zones if you need a single-zone deployment or the Premium tier. + +== Troubleshooting + +[cols="2,2"] +|=== +| Symptom | Likely cause + +| Spoke cannot reach the internet | The spoke's Route Table is missing the `0.0.0.0/0` route to the firewall's private IP. Redpanda creates this route when the network is configured for centralized egress. +| Peering stays in a non-connected state | The reciprocal peering from the Redpanda spoke VNet has not been created yet. This is expected until cluster provisioning completes. If the cluster is already running, confirm that both peerings show `Connected` in *Peerings*. +| Peering creation fails with a CIDR conflict error | The spoke VNet address space overlaps the hub VNet address space `10.255.0.0/16`. Choose non-overlapping address spaces. +| Peering creation fails with a permissions error | The principal creating the peering needs Network Contributor permissions in the hub subscription. If the hub and spoke are in different subscriptions or tenants, the principal also needs access to create a peering that references the remote VNet's resource ID. +| Outbound traffic is intermittently dropped | The firewall policy's rule collection does not allow the third-party endpoints required by Redpanda. See xref:networking:byoc/azure/nat-free-egress.adoc#internet-endpoints[Internet endpoints required from your hub]. +| All traffic appears to come from one public IP | This is the expected behavior of centralized egress. Use that IP for outbound allowlisting. +|=== + +== Next steps + +* xref:networking:byoc/azure/nat-free-egress.adoc[Configure Centralized Egress with Azure Firewall] +* xref:get-started:cluster-types/byoc/azure/create-byoc-cluster-azure.adoc[Create a BYOC Cluster on Azure] diff --git a/modules/networking/pages/byoc/azure/nat-free-egress.adoc b/modules/networking/pages/byoc/azure/nat-free-egress.adoc new file mode 100644 index 000000000..57d335ab7 --- /dev/null +++ b/modules/networking/pages/byoc/azure/nat-free-egress.adoc @@ -0,0 +1,217 @@ += Configure Centralized Egress with Azure Firewall +:description: Route all BYOC cluster egress through your own Azure Firewall and hub VNet instead of a per-cluster NAT Gateway. +:page-beta: true +:page-topic-type: how-to +:personas: platform_admin +:learning-objective-1: Enable centralized egress on a new BYOC cluster using the Redpanda Cloud API +:learning-objective-2: Identify the shared responsibility boundaries between Redpanda and your hub subscription +:learning-objective-3: Troubleshoot egress failures caused by misconfigured hub routes or VNet peering + +[IMPORTANT] +==== +This feature is in beta and is available only on Azure BYOC clusters with private networking. Availability is controlled per organization. Contact your account team to request access to centralized egress. +==== + +Centralized egress lets your BYOC cluster send all internet-bound traffic through your own Azure Firewall and hub VNet instead of a Redpanda-managed NAT Gateway in the Redpanda VNet. When centralized egress is enabled, the Redpanda spoke VNet peers with your hub VNet, all outbound traffic exits through the Azure Firewall in your hub, and no NAT Gateway is created in the spoke. + +After reading this page, you will be able to: + +* [ ] {learning-objective-1} +* [ ] {learning-objective-2} +* [ ] {learning-objective-3} + +== When to use centralized egress + +Use centralized egress when: + +* Your security policy prohibits per-cluster NAT Gateways and requires all internet-bound traffic to traverse a centralized inspection point such as Azure Firewall or a third-party network virtual appliance (NVA). +* You already operate a hub-and-spoke network in Azure and want Redpanda to fit into that topology. +* You want to consolidate egress through a single, predictable public IP for outbound allowlisting on external services. +* You want to reduce NAT Gateway data-processing costs on high-throughput Redpanda workloads. + +If none of these apply, the default NAT Gateway egress used by standard BYOC clusters is simpler and requires no extra customer-managed infrastructure. + +== How it works + +Without centralized egress, the Redpanda agent creates one Azure NAT Gateway per availability zone in the Redpanda VNet. With centralized egress enabled, the agent skips NAT Gateway creation, peers the Redpanda VNet with your hub VNet, and creates a Route Table (UDR) on the Redpanda private subnets with a default route to your firewall's private IP. + +The following diagram shows the connectivity model: + +---- ++----------------------------------+ +----------------------------------+ +| Redpanda VNet | | Customer Hub VNet | +| (Redpanda subscription) | | (Customer subscription) | +| | | | +| VNet Peering +<------->+ VNet Peering | +| allow_forwarded_traffic=true | | allow_gateway_transit=true | +| Route Table (UDR) | | Azure Firewall (Standard) | +| 0.0.0.0/0 -> Firewall private IP | | SNAT to public IP | +| No NAT Gateway | | | +| AKS Worker Nodes | | | ++----------------------------------+ +-----------+----------------------+ + | + v + Internet + (Cloudsmith, mcr.microsoft.com, + NTP, Helm) +---- + +=== Outbound traffic flow + +. An AKS node in a Redpanda private subnet sends a packet destined for the internet. +. The subnet's Route Table forwards `0.0.0.0/0` to the Azure Firewall's private IP in the hub VNet. +. Because both sides of the VNet peering allow forwarded traffic, the packet crosses the peering even though its destination is outside either VNet's own address space. +. The packet arrives at the Azure Firewall, which evaluates it against your firewall policy and performs SNAT to the firewall's public IP. +. The packet exits to the internet. + +=== Return traffic flow + +. The internet response arrives at the firewall's public IP. +. The Azure Firewall reverses the SNAT and forwards the packet back across the peering to the originating subnet. +. The packet arrives at the originating AKS node. + +The hub VNet, Azure Firewall, and hub-side peering are your responsibility. Redpanda creates and manages the spoke-side peering and the Route Table (UDR). See xref:networking:byoc/azure/azure-hub-egress.adoc[Create an Azure Hub for Centralized Egress] for the full procedure. + +[#prerequisites] +== Prerequisites + +Before you configure centralized egress, confirm all of the following: + +* Centralized egress is enabled on your Redpanda Cloud organization. Contact your account team to request access. +* Your BYOC cluster uses private networking (connection type *Private*). Centralized egress is not available on clusters with a public connection type. +* Your BYOC cluster uses a Redpanda-managed VNet. Centralized egress is not available on xref:get-started:cluster-types/byoc/azure/vnet-azure.adoc[BYOVNet clusters]. +* You have an existing hub VNet in the same region as the Redpanda BYOC cluster, with an Azure Firewall (or other NVA) providing internet egress. See xref:networking:byoc/azure/azure-hub-egress.adoc[Create an Azure Hub for Centralized Egress] if you need to provision a hub. +* You have created the VNet peering from the hub to the Redpanda spoke VNet, with `allow_forwarded_traffic` enabled on both sides. This is what allows traffic forwarded by the Azure Firewall (a network virtual appliance) to cross the peering. `allow_gateway_transit` on the hub side is unrelated to firewall forwarding; enable it only if you also want the spoke to use a VPN/ExpressRoute gateway attached to the hub VNet. +* Your hub VNet address space and the planned Redpanda spoke VNet address space do not overlap. ++ +[WARNING] +==== +Azure rejects VNet peering when address spaces overlap. Use a non-overlapping range for your hub. The `10.255.0.0/16` range used in examples on this page is only an example: it is a normal RFC 1918 range, so verify it does not conflict with your existing networks before using it. For background, see xref:networking:cidr-ranges.adoc#what-are-cidrs[What are CIDRs?] +==== +* The hub VNet's Azure resource ID, in the form `/subscriptions//resourceGroups//providers/Microsoft.Network/virtualNetworks/`. +* The Azure Firewall's private IP address in the hub VNet. + +== Shared responsibility model + +[cols="2,1"] +|=== +| Component | Owner + +| Redpanda spoke VNet, subnets, and AKS cluster | Redpanda +| Spoke-side VNet peering with `allow_forwarded_traffic = true` | Redpanda +| Route Table (UDR): `0.0.0.0/0` -> firewall private IP | Redpanda +| No NAT Gateway created in the spoke | Redpanda +| Hub VNet | Customer +| Hub-side VNet peering with `allow_forwarded_traffic = true` (`allow_gateway_transit = true` too, only if the hub also shares a VPN/ExpressRoute gateway) | Customer +| Azure Firewall (or other NVA) and its policy rules | Customer +| Firewall public IP | Customer +| Egress path availability and HA | Customer +|=== + +Redpanda does not manage the availability of the egress path. Plan for zone redundancy or the Premium tier in your hub if you need high availability or deep packet inspection. See xref:networking:byoc/azure/azure-hub-egress.adoc[Create an Azure Hub for Centralized Egress] for sizing guidance. + +== Limitations + +* Centralized egress requires a Redpanda-managed VNet. It is not available on BYOVNet clusters. +* Centralized egress is set at network creation. Complete all hub-side setup before you start the network and cluster creation flow. +* Cloud UI support for centralized egress on Azure is not yet available. Configure it through the Cloud API. + +== Configure egress at network creation + +Centralized egress is set at network creation. Provision the hub VNet and Azure Firewall before you create the network, since the request requires the hub VNet ID and firewall private IP. Create the VNet peering to the Redpanda spoke VNet after the network is provisioned, once the spoke VNet's resource ID is available in the Redpanda Cloud console. See xref:networking:byoc/azure/azure-hub-egress.adoc[Create an Azure Hub for Centralized Egress]. + +[NOTE] +==== +Unlike AWS and GCP, centralized egress for Azure BYOC clusters does not yet have Cloud UI support. Configure it using the Cloud API, as shown below. +==== + +// The Cloud API path for centralized egress is intentionally hidden while the +// `egress_spec` field is in PREVIEW. To re-enable the section when the field +// graduates, set the :show-preview-api: attribute (either in this page's +// header as `:show-preview-api:` or as a build-time attribute in the playbook). +ifdef::show-preview-api[] +=== Use the Cloud API + +[IMPORTANT] +==== +The `egress_spec` field is in preview. Its shape and validation rules may change. Pin a specific API version when scripting against this field, and revisit your integration when the field graduates to general availability. +==== + +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 '{ + "network": { + "name": "prod-eastus2", + "cloud_provider": "CLOUD_PROVIDER_AZURE", + "region": "eastus2", + "cidr_block": "10.0.0.0/20", + "cluster_type": "TYPE_BYOC", + "resource_group_id": "", + "egress_spec": { + "azure": { + "hub_vnet_id": "/subscriptions//resourceGroups/hub-egress-rg/providers/Microsoft.Network/virtualNetworks/hub-vnet", + "firewall_private_ip": "10.255.0.4" + } + } + } + }' +---- + +For the surrounding workflow (authenticating to the Cloud API, creating the resource group, creating the cluster against this network, and running `rpk cloud byoc azure apply`) see xref:manage:api/cloud-byoc-controlplane-api.adoc[Use the BYOC Control Plane API]. After the network is created, create the cluster by calling the Cluster create endpoint with the new network ID. The Cloud UI create-cluster flow does not yet support selecting a centralized-egress network on Azure. +endif::[] + +[#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 +|=== + +[NOTE] +==== +`docker.cloudsmith.io`, `mcr.microsoft.com`, and the Helm repository hostnames are FQDNs on TCP/443. Allow them with Azure Firewall application rules, which filter HTTPS traffic by hostname using the TLS SNI and don't require DNS proxy. NTP is UDP-based, which application rules don't support, so allow it with a network rule using your NTP servers' actual destination IP addresses (or an FQDN in a network rule if you enable DNS proxy on the firewall). +==== + +== DNS resolution + +Centralized egress does not affect DNS resolution. The Redpanda VNet uses Azure-provided DNS at `168.63.129.16`. Azure resolves this address using a platform route that bypasses your subnet's UDRs entirely, so DNS resolution works regardless of whether `0.0.0.0/0` is routed through your hub. You do not need a separate DNS path or DNS resolver endpoint in your hub. + +== Troubleshooting + +[cols="1,1"] +|=== +| Symptom | Likely cause + +| Cluster creation does not complete +| The cluster cannot reach the external services it needs during bootstrap. On the hub side, verify all of the following: both the hub-side and spoke-side VNet peerings show `Connected`; the hub-side peering has `allow_gateway_transit` enabled; the firewall policy allowlist includes the endpoints in <>; and the hub VNet address space and the Redpanda spoke address space do not overlap. If these all look correct, contact Redpanda Support. + +| VNet peering stays in a non-connected state +| The reciprocal peering from the Redpanda spoke VNet has not been created yet. This is expected until cluster provisioning completes. If the cluster is already running, confirm that `allow_forwarded_traffic` is enabled on both peerings. + +| VNet peering creation fails with an address space conflict error +| The spoke VNet address space overlaps the hub VNet address space. Choose non-overlapping address spaces for the hub and every spoke. + +| Outbound traffic is intermittently dropped +| Your firewall policy is not allowlisting the endpoints required by Redpanda. See <>. + +| All traffic appears to come from one public IP +| This is the expected behavior of centralized egress. Use that IP for outbound allowlisting. +|=== + +== Next steps + +* xref:networking:byoc/azure/azure-hub-egress.adoc[Create an Azure Hub for Centralized Egress] +* xref:get-started:cluster-types/byoc/azure/create-byoc-cluster-azure.adoc[Create a BYOC Cluster on Azure]