Demilitarized zone (DMZ) represents a neutral zone and aims to isolate private network from the Internet by including redundancy in cloud infrastructure. The main idea is in creating an externally accessible reverse-proxy server to forward requests to a server in an internal network. There are different types of DMZ configuration that suit various cloud architectures depending on the security level and performance you want to have.
Consider the example of a service leg DMZ architecture with at least three
network interfaces to communicate with an external (for example, an Internet
border router), internal (API services endpoints and Dashboard),
and DMZ networks.
Even though, two-firewall DMZ is more secure,
the service leg DMZ with a single firewall requires less resources
and easy to manage.
However, the service leg DMZ can not protect against
DoS attacks that may affect an internal cloud services operation.
To fix this problem, use a DDoS protection tool.
Still, it may happen that DDoS will consume all incoming bandwidth
and overload a border router.
As a rule, Firewall is configured to permit external web traffic. This brings a risk of malformed HTTP packets entering the environment. That is why, IDPS system accompanies Firewall. IPS parses the most popular L7 protocols to detect and drop malicious streams minimizing the risk of compromise.
Place the OpenStack Dashboard service and OpenStack APIs endpoints behind Firewall and access the OpenStack services through reverse proxy hosts in DMZ.
WAF presence is mandatory. Consult with WAF vendor regarding options to protect public APIs.