Ingress NGINX 1.2.0 restricts the proxy filesystem

Ingress NGINX places a public HTTP proxy beside a controller that needs Kubernetes API access. In the architecture described by the project, both processes share a container filesystem. A configuration injection flaw can therefore reach beyond the website's content and expose files associated with the controller. That is the problem behind the opt-in chroot mode described in the April 28 announcement.

The project does not claim to have completed input sanitization. Its stated aim is to reduce the consequences of the remaining risk while working toward separating control and data plane processes. Version 1.2.0 adds a restricted filesystem environment for NGINX and a separate inspection mechanism for dangerous input. These changes operate at different stages of the path from an Ingress object to a running proxy.

I regard that distinction as essential. A controller's access to the Kubernetes API is justified by its reconciliation work. The web proxy should not inherit access to controller credentials merely because the processes share a packaging arrangement.

Why the shared filesystem matters

The controller watches Kubernetes objects and writes an NGINX configuration. NGINX then interprets that configuration to serve traffic. The announcement explains that incomplete sanitization can let supplied values become dangerous directives in the generated file. This is a boundary between structured cluster configuration and another program's configuration language.

The example in the announcement uses a location with an alias pointing at the filesystem root. If accepted into the configuration, that location can expose files through HTTP. The example matters because it connects the configuration problem to the process's actual filesystem access. The damage depends on both what directives can be injected and what the receiving process can read.

Before the new mode, the proxy can see the controller container's filesystem. That includes the service account token and other controller configuration identified in the announcement. A flaw in proxy configuration can therefore expose material whose purpose is unrelated to serving an application response.

The chroot arrangement gives NGINX a filesystem containing the files required for its own operation. The controller remains outside that restricted view. Changing the proxy's visible root reduces the files reachable through a successful file-disclosure path. It does not prove that malicious configuration has become safe.

This separation is narrower than splitting the processes into independent containers or pods. The project explicitly describes the arrangement as an intermediate response and warns that the informal analogy to a container inside a container is not strictly accurate. An operational description should retain that qualification.

The deployment opts into a different image

Version 1.2.0 does not enable this mode automatically for every installation. The announcement requires a chroot image and the SYS_CHROOT capability in the pod's container security context. The image name receives a -chroot suffix. Changing only the ordinary controller version is not the same as enabling the new mode.

For users of the official Helm chart, the announcement gives this setting:

controller:
  image:
    chroot: true

The manual deployment instructions retain the existing capability to bind a privileged port and add the capability needed for chroot. Their relevant fragment is:

capabilities:
  drop:
    - ALL
  add:
    - NET_BIND_SERVICE
    - SYS_CHROOT

These snippets describe the announced configuration, not a full deployment manifest. The chart setting and manual security-context change belong to their respective installation methods. The capability requirement also means cluster policy can affect whether the new deployment is permitted.

The implementation pull request records the effort to isolate NGINX within the controller container. Its discussion of security capabilities and seccomp compatibility shows why this is an operational change as well as a new image. Restricting one process's filesystem can require explicit permission to construct the isolation environment.

The opt-in choice therefore has a concrete purpose. Existing installations get time to reconcile the new image and its required capabilities with their environments. The additional capability is part of how the restriction is established, so evaluating only the final filesystem view omits a relevant deployment requirement.

Deep inspection works before NGINX reads the file

The other mechanism in 1.2.0 examines input. The announcement calls it deep inspection and says it runs during reconciliation and through the validating admission webhook. Unlike chroot, it is enabled by default, with --deep-inspect=false available to disable it.

Its purpose is to reject strings associated with dangerous directives or sensitive paths before they become usable configuration. The rules in the 1.2.0 source include regular expressions for alias and root directives. They also check selected paths under /etc, the Kubernetes secrets directory, and Lua directive patterns.

The implementation iterates through those expressions and returns an error when a value matches. That gives a more precise account than saying that the release validates configuration. It applies a defined set of pattern checks. The rule set describes what the mechanism detects, and should not be mistaken for a proof about every possible NGINX configuration.

The announcement also distinguishes this inspection from existing annotation validation. Moving that older validation into the new inspection mechanism is a future goal. As of this release, the mechanisms should not be described as already consolidated.

Deep inspection has a processing cost because it examines strings across relevant Ingress objects. The project warns of additional CPU use. Disabling it changes the input checks, while enabling chroot changes the proxy's filesystem view. One setting does not imply the other, and neither substitutes for the planned process separation.

The remaining control plane boundary

NGINX still needs its own configuration file inside the restricted filesystem. The announcement points out that an attacker who can inject suitable commands may still try to read that file and extract sensitive information. Filesystem reduction limits reachable material without eliminating the importance of configuration contents.

My preference is for the eventual process separation the maintainers describe. The current change is still useful because it ties mitigation to a specific exposure path. A request that obtains a proxy-visible file should have fewer opportunities to reach controller-only material.

The longer-term plan is to separate control and data plane processes, with the announcement also discussing how that could support a Gateway API implementation. That remains planned work on April 28. The release's present contribution is the deployable chroot option and the default inspection path, each with a stated scope and an identifiable configuration mechanism.