Nginx Ingress + Azure Front Door Security Hardening
Typical Architecture
In the typical architecture the security harden is achieved by allowing only Azure FrontDoor Service tag Inbound Traffic from the AKS Subnet NSG. AzureFrontDoor.Backend Service Tag
AKS Subnet NSG Inbound Rules
Known Vulnerability of the Above
Any Azure Front Door Profile can make requests to the Kubernetes Nginx Ingress Controller since AzureFrontDoor.Backend Service Tag is allowed.
The WAF can be bypassed when requests are initiated from another Azure Front Door profiles.
How to mitigate the Vulnerability
Azure Front Door runs in Multi Tenancy mode in shared infrastructure. Every Azure Front Door profile adds some unique headers that cannot be forged to the backend.
X-Azure-FDID header is a header added by Azure Front Door profile which adds the front door profile id to the requests forwarded to the Front Door backends.
In Azure Front Door documentation it has mentioned to mitigate this vulnerability in IIS using header value based authentication. 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.
How to perform the same in Kubernetes Nginx Ingress Controller ?
Nginx Ingres controller also can perform header value based validation and deny requests with no matching. Yet no official Microsoft documentation can be found on this case (27/11/2020).
Simply Deny any request which does not have the X-Azure-FDID header with your Azure Front Door profile ID.
Sample Ingress Level Implementation
metadata:
name: deny
annotations:
nginx.ingress.kubernetes.io/server-snippet: |
if ($http_x_azure_fdid !~* "55ce4ed1-4b06-4bf1-b40e-4638452104da" ) {
return 403;
}
Sample Ingress Controller Global Level Implementation
apiVersion: v1
data:
server-snippet: |
if ($http_x_azure_fdid !~* "55ce4ed1-4b06-4bf1-b40e-4638452104da" ) {
return 403;
}
use-forwarded-headers: "true"
kind: ConfigMap