Security Boost for Ingress-NGINX: How the New Version Protects Your Kubernetes Applications

The Ingress is one of the most frequently targeted components in Kubernetes. An Ingress typically defines an HTTP reverse proxy exposed to the internet and contains multiple websites. Additionally, it has privileged access to the Kubernetes API, for example, to read Secrets for TLS certificates and their private keys.

Although this is a risky component in your architecture, it remains the most popular way to properly expose your services.

Ingress-NGINX was part of security assessments that pointed to a major issue: we do not perform all necessary sanitation measures before converting the configuration into an nginx.conf file, which can lead to information leaks.

We recognized this risk and understood the need to address it. However, this is a complex process, which is why in the current version (v1.2.0), we have taken a different approach to mitigate this risk (but not eliminate it!).

Meet Ingress-NGINX v1.2.0 and the chrooted NGINX Process

One of the biggest challenges is that Ingress-NGINX runs the web proxy server (NGINX) alongside the Ingress controller, which has access to the Kubernetes API and creates the nginx.conf file.

This means that NGINX has the same access to the controller’s file system as the Kubernetes service account token and other configurations from the container. While our goal is to separate these components, the project needed a quick response; this led us to the idea of using chroot().

Let’s take a look at what an Ingress-NGINX container looked like before this change:

As we can see, the same container (not the pod, the container!) that provides the HTTP proxy is the one that monitors Ingress objects and writes the container volume.

Now, get to know the new architecture:

What does this all mean? A basic summary is that we isolate the NGINX service as a container within the controller container.

While this is not entirely accurate, to understand what has been done here, it is important to know how Linux containers (and the underlying mechanisms like kernel namespaces) work. You can learn more about cgroups in the Kubernetes glossary: cgroup and more about how cgroups work with namespaces in the NGINX project article What are Namespaces and cgroups and how do they work?. (Please note that Linux kernel namespaces are different from Kubernetes namespaces).

With these changes, we aim to raise the security standard for your Kubernetes applications. ayedo supports you in implementing the best possible security practices in your infrastructure.

Source: Kubernetes Blog