Support Policy

This policy defines how HeroDevs ("we") support NES for Ingress NGINX, which Kubernetes releases we support for NES for Ingress NGINX, how we test NES for Ingress NGINX on currently supported and new upstream Kubernetes releases, customer obligations, how we add new upstream Kubernetes releases to the NES for Ingress NGINX support matrix, and a technical untenability escape and customer notice procedure for new upstream Kubernetes releases.

Currently Supported Kubernetes Distribution Matrix

We currently support NES for Ingress NGINX on Kubernetes versions 1.31 through 1.36.

NES for Ingress NGINX Testing and Validation

We test and validate against 1.31 through 1.36 and certify compatibility for all minor releases between 1.31 and 1.36.

Testing and validation includes:

• Full CI matrix testing, including unit, integration, and E2E testing on every pull request to NES for Ingress NGINX, on a weekly basis, and upon any release of NES for Ingress NGINX.
• Smoke tests of core Ingress flows and common annotations.
• Performance and stability checks on representative clusters.
• Security scanning of the entire NES for Ingress NGINX build pipeline, including the Alpine base Linux container, NGINX, Ingress NGINX controller, and dependencies therein.

NES for Ingress NGINX Security Posture

NES for Ingress NGINX explicitly covers CVEs in the Ingress NGINX controller and NGINX HTTP server component. The HeroDevs CVE response SLA applies to these components only.

HeroDevs makes best efforts to respond to Alpine Linux base CVEs (see Alpine Linux Base Container below), Go standard library CVEs, and other dependency CVE reports and remediate them in line with the HeroDevs SLA. If you require a guaranteed CVE remediation response in dependencies, please discuss this with your HeroDevs Account Executive.

Alpine Linux Base Container

In keeping with upstream EOL Ingress NGINX practice, we continue to base our NES for Ingress NGINX image on a minimal Alpine Linux base container. We make no substantive changes to the Alpine Linux base container template that Ingress NGINX had prior to EOL.

We rely upon the security patch backporting process by Alpine Linux for base container packages with reported CVEs. We do not alter the underlying Alpine base image beyond base container rebuilds to pull in upstream Alpine packages with backported security fixes. When an Alpine base image reaches EOL, we will migrate to a supported Alpine base image.

Fixes for CVEs in Alpine base packages go through the Alpine security process, which may take longer than the HeroDevs SLA timeline. If you require CVE remediation in Alpine base packages faster than the standard Alpine security process, please discuss this with your HeroDevs Account Executive.

Customer Obligations

Customers must run a Kubernetes release that is listed in the currently supported matrix to receive full product support for NES for Ingress NGINX.

Customers must monitor the NES for Ingress NGINX documentation and release notes.

New Upstream Kubernetes Versions

We conduct the same testing and validation described above against nightly releases, release candidates, and developer preview builds of kind, minikube, k3s, MicroK8s, and AKS-configured kind to detect signals of Kubernetes API drift that may affect NES for Ingress NGINX.

We also monitor Kubernetes SIG-Release and SIG-Networking notices including API removal proposals and KEPs that may affect NES for Ingress NGINX.

Reasonable Effort To Support New Upstream Kubernetes Versions

If signals of Kubernetes API drift in new upstream Kubernetes versions indicate that Ingress NGINX must be modified or patched to ensure continued drop-in replacement functionality of NES for Ingress NGINX, HeroDevs will take reasonable engineering efforts to make those modifications or patches and deliver a drop-in replacement to customers within 90 days of the general availability of the new upstream Kubernetes version, and update the currently supported matrix accordingly.

Technical Untenability For New Upstream Kubernetes Version

If, upon thorough investigation, any of the following occur:

• A new upstream Kubernetes version removes or fundamentally changes APIs or extension points that NES for Ingress NGINX depends on, and no reasonable patch or shim can restore drop-in replacement functionality, or
• The cost, risk, or engineering effort to maintain drop-in replacement functionality on a new upstream Kubernetes version requires a major refactor of NES for Ingress NGINX that would cause breaking changes, introduce unknown security risks, or cause NES for Ingress NGINX to no longer function as a drop-in replacement for EOL Ingress NGINX, or
• Security or stability constraints in the new upstream Kubernetes version make use of NES for Ingress NGINX unsafe on the new upstream Kubernetes version

HeroDevs will provide, via release notes and documentation updates, notice that the new upstream Kubernetes version cannot be supported by NES for Ingress NGINX, within 90 days of the general availability of the new upstream Kubernetes version, with full documentation of the investigation.