One of the least anticipated security vulnerabilities in ingress control is the use of an https proxy. As with any proxy it splits the secure channel between sender and receiver. Since there is no more a single tunnel, we now have to secure not just the ends of the tunnel with the certificates for mutual authentication but also the https proxy.  

The role of an https proxy is that it consolidates calls to and from api endpoints that may even be hosted on different pods. This means that it is very similar to an api gatekeeper while allowing statistics, monitoring and troubleshooting of all applications.  

It is not enough to configure the gatekeeper without having an end to end security between external incoming traffic and internal api endpoints via and including the ingress control, the applications exposing the APi and the gatekeeper or any man-in-the-middle modules.

  

Firewalls and network routing control can control the ip layer and the ports. The above method only addresses the http and https which are mostly allowed as default in all rules. 

KeyCloak generates certificates. It is not necessary to use cert-manager if the application relies on an external OpenID provider like KeyCloak. However, passing the certificate via https through api during deployment and before the ingress control is in place is generally not preferable. A stock Kubernetes solution for deployment relieves this concern. On the other hand, changing the initial certificate for an application with the help of KeyCloak is always possible after the deployment in the form of custom code.  

KeyCloak is a complex software and so are the features for a gatekeeper. An end to end design will separate the concerns for deployment which should preferably be as no-brainer as possible. All the custom logic should be handled by the application and not the deployment code because they are likely tied to the application and not the Kubernetes platform.