The Ingress may be one of the most targeted components of Kubernetes. An Ingress typically defines an HTTP reverse proxy, exposed to the Internet, containing multiple websites, and with some privileged access to Kubernetes API (such as to read Secrets relating to TLS certificates and their private keys). By Ricardo Katz (VMware), James Strong (Chainguard).
This is not our final goal. Our final goal is to split the control plane and the data plane processes. In fact, doing so will help us also achieve a Gateway API implementation, as we may have a different controller as soon as it “knows” what to provide to the data plane. Some other projects in Kubernetes already take this approach (like KPNG, the proposed replacement for kube-proxy), and we plan to align with them and get the same experience for Ingress-NGINX.
This article covers:
- Meet Ingress NGINX v1.2.0 and the chrooted NGINX process
- Skip the talk, what do I need to use this new approach?
- OK, but how does this increase the security of my Ingress controller?
- What about other security improvements in this release?
Source: https://kubernetes.io/blog/2022/04/28/ingress-nginx-1-2-0/
Ingress-NGINX has been part of security assessments that figured out we have a big problem: we don’t do all proper sanitization before turning the configuration into an nginx.conf file, which may lead to information disclosure risks. While it is a risky component in your architecture, it is still the most popular way to properly expose your services. Good read!
[Read More]