Prepare key information
Last updated
Was this helpful?
Last updated
Was this helpful?
It is recommended to prepare the information below, before you start deployment, as it will help you in the configuration process.
Identify where you are going to install CloudGuard WAF and enforce security. The environment and deployment type will define which is applicable to your project. You can read more about the different enforcement points in the section.
Options are to deploy as:
A Gateway (Single VMWare or Auto Scaling Group) in AWS in a dedicated or in an existing VPC
A Gateway (Single VMWare or ScaleSet) in Azure in a dedicated or in an existing VNet
A Gateway in VMWare vSphere
WAF as a service (SaaS) in specified regions world-wide. Routing through the service is done by configuring the relevant DNS records for the site's domain.
A managed Reverse Proxy NGINX Docker Container with an agent.
An Agent on a Docker Container with a new NGINX reverse proxy/Kong API server container.
An Agent with an existing/new NGINX Kubernetes Ingress.
An Agent with an existing/new NGINX reverse proxy or Kong API server.
Data Residency refers to the physical or geographical location where your data is stored.
In the specific case of there are also separate supported regions for Points of Presence (PoPs). They refer to the physical locations where our Reverse Proxy and WAF agents are deployed, directly influencing your applications' security efficiency and response time.
According to your environment's location (for latency concerns) and, if applicable, regulation concerns, select the data region (and PoP if applicable) from the supported options.
At this time:
CloudGuard WAF supported data regions are : Europe, United States, India, Australia
CloudGuard WAF SaaS PoPs are supported in: Ireland, Milan, Mumbai, North Virginia, Osaka, Singapore, and Stockholm.
Collect the following information about the web application(s) or API(s) you are going to protect. You will need this to configure the CloudGuard WAF Assets.
What is the internal URL or IP address and port of the web application(s), API(s) or internal load balancer in front of them? These are often URLs that will only be accessible from your reverse proxy/security Gateway and not directly exposed to the Internet.
What is the external URL and port that you would like to expose to the users? For example - https://www.acme.com or https://acme.com/api.
In the common case you use HTTPS, then depending on the deployment type, you should have access to the SSL certificate and private key (some deployments, like SaaS, do not require that you provide your own certificates)
What is the best way to distinguish between users of the application or API? This is useful for the CloudGuard WAF machine learning process:
Specific header in the HTTP request
Specific key in an HTTP cookie
Specific key in HTTP JWT
IP address in X-Forward-For header
IP address of the request