This is a continuation of a previous article on cloud resources, their IaC, shortcomings and resolutions with some more exciting challenges to talk about. The previous article cited challenges and resolutions with regards to Azure Front Door and its backend services aka origins. This article focuses on ip access restrictions of the origins such as app services but we resume from the earlier mentioned best practices that a good access restriction will not only specify the ip address range of the sender but also verify the header which in the case of Azure Front Door is x-Azure-FDID and is stamped by the Front Door with its GUID. Since the GUID is specific to the instance of the typically unique and global Front Door in most deployments, a rule that checks the header only needs one value to compare against.  This header is set by the Front Door on every request so the access restriction rule works against every request.

In this case, the app services must be configured to do IP address filtering to accept traffic from the Front Door’s backend IP address space and Azure’s infrastructure only. As pointed out earlier, this does not mean the ip addresses to which the Front Door’s endpoint resolves to. Instead a complete list of Ip addresses for the backend can be found with the use of a service tag named AzureFrontDoor.Backend which comes helpful not only to find the ip addresses but also to configure rules in the network security group, if desired. The backend ip addresses can be found from their publication at https://www.microsoft.com/download/details.aspx?id=56519 and appropriate CIDR ranges can be determined to encompass all. Note that these pertain to a large number of locations, specifically metros that are spread the world over.  Should an ipv6 CIDR be need for these ip ranges, they can be succinctly denoted by 2a01:111:2050::/44 range.

On the other hand, traffic from the Azure’s basic infrastructure services will originate from the virtualized host ip addresses of 168.63.129.16 through 169.254.169.254.