30-May-2023 05:00 - edited 29-Aug-2023 13:55
The target deployment environment has long been a critical factor in selecting WAF products as, typically, specific WAFs were better suited for some but not all environments. Appliance-based WAFs, with their superior throughput performance and larger footprint were perfect for on-prem deployments but not the best candidates for Cloud environments. As-a-service deployments where born in the Cloud but did not fit a lab-based Kubernetes use case very well.
Modern enterprises tend to deploy their applications in a variety on environments so selecting a WAF specialized for one (primary) environment would mean accepting limitations when deployed in others or buying separate products that would increase management complexity.
This should not be the case anymore as F5 Distributed Cloud (XC) can abstract away the underlaying environment and allow for to be deployed in a multitude of environments maintaining full functionality.
This is the first article in a series that will explore the various ways to deploy XC WAF and we will start with an overview of XC WAF deployment options.
This deployment mode is better suited when protecting backend applications which are already public (accessible from the Interned via FQDN or Public IP).
XC WAF is deployed on the REs, where the services are being advertised to the Internet through Anycast IPs. The end users will connect to their closest RE and the traffic will be inspected by the WAF security policy. The traffic will then be forwarded across the XC Global Network towards an egress RE and then towards the customer site as regular Internet traffic. The customer will filter the traffic, only allowing traffic forwarded by the XC platform.
This deployment model is the best solution when the backend applications are not yet accessible from the Internet (no FQDN / Public IP). In this case, CE (Customer Edge) sites can be deployed to connect these “private” customer sites to the XC Global Network via IPSEC tunnels opened from XC CE(s) to the closest two REs sites.
XC WAF is deployed on the REs, where the services are being advertised to the Internet through Anycast IPs. CE(s) are being deployed on the customer sites and connect to the closest two REs through IPSEC tunnels. The end users will connect to their closest RE and the traffic will be inspected by the WAAP security policy. The traffic will then be forwarded across the XC Global Network towards an egress RE and then tover an IPSEC tunnel to the CE site where it will be forwarded to the backend application as pure IP-based traffic.
This deployment mode is better suited when protecting backend applications that require Internet traffic to be directed to them with no intermediary processing, for security or privacy purposes. Another use case is local traffic (all traffic is sourced and destined for the same customer site).
XC WAF is configured on the CE(s) deployed on the customer sites. The end users will connect directly to the CEs, bypassing the XC Global Network. The CE sites will be still managed through the XC Cloud-based Console.
Best fit for closely-coupled protection of workloads deployed in Kubernetes environments.
XC WAF can be configured on CEs deployed either outside the Kubernetes cluster or inside, as a regular k8s workload. Through the XC Console, XC WAAP can be automated and integrated in CI/CD pipelines as required by the modern apps development methodologies.
F5 XC WAF presents a clear advantage over classical WAFs in that it can be deployed on a variety of environments without loss of functionality.
In this first article of a series, we presented an overview of the main deployment options for XC WAF while follow-on articles will dive deeper into the details of the deployment procedures.
For further information or to get started: