Lock access to your services only from Azure Front Door

Lock access to your services only from Azure Front Door

Azure Front Door (AFD) offers a global secure entry-point to the cloud. AFD has multiple features like WAF/CDN/Application acceleration at Microsoft’s edge etc.

However, AFD does not support Private IP as a backend. In this article, I will cover a few approaches on restricting traffic to your application exclusively from AFD.

How can I tell if the request is coming from Azure Front Door (can be any)?

There are few things you can do to verify; you do not necessarily have to implement all checks (you can though if that's what you need!)

1. IP Based Restriction

Azure publishes a range of IPs that Azure Front Door, you can restrict your backend to accept traffic from these whitelisted IPs. This approach is simple but also means anyone else can set up AFD instance into their subscription and still be allowed to call your services, also adds an overhead of keeping the IP ranges up to date as they change from time to time.

Here is how you can restrict IP:

  • VNET Inject Services

    In case, your service has a public load-balancer and runs into VNET [e.g. WebApp in ASE, AKS, ACI or APIM premium SKU injected in VNET or simply VM]. You can use Service tags to restrict traffic to eliminate management overhead of maintaining IP ranges up to date.
  • API Management: You can implement policy
  • Web Apps: You can implement IP based filtering, these work at load balance level (see more here)
Access Restrictions on Web Apps

How can I tell if the request is coming from my Azure Front Door Instance? ‌

Two points below are important to verify the request is coming from your AFD instance.

2. X-Azure-FDID header

Azure Front Door injects X-Azure-FDID header into every request it makes to the backend. X-Azure-FDID contains Azure Front Door ID.

You can find Front Door ID value under the Overview section from Front Door portal page or via GET operation on your Front Door with the Azure API version 2020-01-01 or higher.

Here is how you can verify this header:

  • API Management: You can implement policy
  • Web Apps: You can implement a rule in backend webserver to restrict traffic based on the resulting 'X-Azure-FDID' header value. Below is an example for IIS:

3. Inject Custom Header

At front door layer you can securely inject custom header for all incoming requests giving you the flexibility of changing header value in a case of compromise.

Here is how you can set the custom routing rule (see details here)

Here is how you can verify this header:

  • API Management: You can implement policy
  • Web Apps: You can implement a rule in backend webserver to restrict traffic based on the resulting Custom Header value. (for sample see above)

Concluding thoughts

Don't just rely on IP based whitelisting as it only restricts traffic from any instance of AFD (it can come from anyone outside your subscription).

In the case of PaaS services APIM, Public App Service etc., header-based whitelisting is easy to implement and manage.

I would strongly encourage to not just rely on immutable X-Azure-FDID but also injecting a mutable custom header to enable maximum flexibility.


Reference:

https://docs.microsoft.com/en-us/azure/frontdoor/front-door-faq#how-do-i-lock-down-the-access-to-my-backend-to-only-azure-front-door


Share Tweet Send
0 Comments
Loading...