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 applies to your project. You can read more about the different enforcement points in the section.
Options are to deploy as:
As a Gateway/Virtual Machine in , or VMware.
As in specified regions worldwide. Routing through the service is done by configuring the relevant DNS records for the site's domain.
in Kubernetes environments - It integrates with the most popular , , and as well as Istio Ingress Controller.
Using Docker in one of two main configurations: - a single Docker image containing a managed reverse proxy server and the CloudGuard WAF Security agent, or as ocker - NGINX Reverse Proxy Docker or Kong API Gateway Docker + CloudGuard WAF Security Agent Docker.
As an , thus protects any applications and APIs served by NGINX Reverse Proxy.
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, the United States, India, and Australia.
CloudGuard WAF SaaS PoPs are supported in: Ireland, Milan, Montreal, Mumbai, North Virginia, Osaka, Singapore, Stockholm, and Sydney.
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 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 the X-Forwarded-For header
IP address of the request