Web application firewall for a self-hosted deployment
When you deploy BI Pixie on Azure with Private network access, the Network tab offers Add a web application firewall. The deployment then adds an Azure Application Gateway with a web application firewall, on a private address in your virtual network, in front of the BI Pixie event address. Most organizations do not need it.
Who this is for
This option is for organizations whose security policy requires every internal web service to sit behind a web application firewall, or to be reached under a host name in their own domain. It is offered only with Private network access.
What it costs
About $335 to $350 a month, on top of the private endpoints that Private network access adds. It is an Azure charge in your own subscription, billed to you by Microsoft, not by BI Pixie.
What changes for viewers
Viewers reach Pixies under a host name in your own domain, for example pixies.contoso.com, instead of the Function App address. As with Private network access, only viewers on your corporate network or VPN are tracked. Their devices must trust the certificate for that host name, or their activity is not recorded. Their reports open and work normally either way.
What to prepare
- A third free subnet in the same virtual network as the other two, used by the firewall alone. An Application Gateway cannot share a subnet with anything else. Enter its name in Subnet for the firewall.
- A free private IP address in that subnet, for example
10.0.3.10. Enter it in Firewall private IP address. - The host name viewers will reach Pixies under, in your own domain. Enter it in Host name for Pixies.
- A certificate for that host name, stored as a PFX in your Key Vault. A certificate from your internal certificate authority works when your viewers’ devices trust it. Enter its secret ID in Certificate secret ID in Key Vault, for example
https://myvault.vault.azure.net/secrets/pixies-cert. - A user-assigned managed identity with the Key Vault Secrets User role on the certificate. The firewall reads the certificate through it. Enter its full resource ID in User-assigned managed identity resource ID.
The firewall rules
The firewall uses the Microsoft Default Rule Set 2.1 in Prevention mode. A Pixie event carries report names, page names and, when you turn them on, filter values, and a standard rule can block a value that contains quotes or words that look like SQL. A blocked event is lost without any error. So these event parameters are excluded from the rules, and your security team can review each one: r, p, b, d, t, fc, fd, fv, fs, pi, w, u, ur, e and a.
Request bodies are not inspected, because report scans send semantic model expressions that resemble SQL. The event address limits a request body to 1 MB itself.
A public IP address that serves nothing. Azure requires every Application Gateway of this kind to have a public IP address. The deployment attaches one but puts no listener on it, so nothing is reachable through it.
After the deployment
Three steps complete the setup, in this order, before you add Pixies to any report:
- In your DNS, point the host name at the firewall’s private IP address.
- Find the new event address. The deployment shows it, without the key, as the wafEventAddress output:
https://[your host name]/api/send_event. - In the BI Pixie desktop tool, enter
https://[your host name]/api/send_event?code=[your send_event function key]in thepixies_flow_endpoint_urlsetting. The function key is the same one the Function App address uses.
From version 1.7.0, if you limit links to the reports that track them, enter https://[your host name]/api/send_inventory?code=[your send_inventory function key] in pixies_inventory_endpoint_url, because the firewall forwards every address under your host name to the Function App that holds both send_event and send_inventory.
Reports that already carry Pixies keep sending to the address they were given. To move them to the new address, run bi-pixie.exe on them again. Nothing about what Pixies write changes, and the function key stays the same.