All you ever wanted to know about ingress-nginx for Viya (2): ingress-nginx 1.12 changes

[#1]

The Ingress Controller is a critical requirement and key component of the SAS Viya infrastructure. In the first part of the post (that you should read first 😊 ), I explained the concept of the Ingress Controller, made the distinction between "Ingress NGINX" and "NGINX Ingress", then discussed the version, how to install and configure ingress-nginx .

Note: [11-Feb-2026]  See Upcoming Changes to Kubernetes Ingress for SAS Viya 4 Deployments for recent announcement about how Contour ingress will replace ingress-nginx as the supported ingress controller in SAS Viya (as of 2026.03).

In this second and last part, I will focus on some changes that are needed to allow SAS Viya to work with the latest version of ingress-nginx (1.12 and later). We will also see that several CVEs (including a critical one) were recently fixed in the ingress-nginx project and what is the impact for SAS Viya.

Here is a little "ToC" table that lists the key points, for this second part of the post 😊

• Ingress NGNIX 1.12 breaking changes
• Ingress Common Vulnerability Exposures (CVEs)
  • Am I affected by this security issue?
  • Remediation: Upgrade version
  • Can I always upgrade to a patched ingress-nginx version to fix these security issues?
• The NSG rule deletion issue
  • Before ingress-nginx 1.12
  • ingress-nginx 1.12 and after
  • Solution
• Conclusion

Ingress NGNIX 1.12 breaking changes

Quite recently, a note has been added in the documentation in case you were using ingress-nginx 1.12.x and later for your Kubernetes cluster.

Some default values have been changed beginning with 1.12 and the new default values could cause problems and failures to deploy SAS Viya. (Remember that if you plan to deploy SAS Viya in Kubernetes 1.31, ingress-nginx 1.12.x or later is mandatory).

Some additional configuration of the ingress-nginx controller is required :

• For all Viya versions, you’ll need to set the value for annotations-risk-level to Critical
• If you deploy SAS Viya LTS 2024.09, or SAS Viya Stable 2024.10 or 2024.11 the strict-validate-path-type parameter must be set to false in the ConfigMap for the ingress-nginx controller in your Kubernetes cluster (when ingress-nginx 1.12.x or later is used).
• From stable 2024.12, SAS Viya works with the strict path validation that is enabled by default (strict-validate-path-type set to true).

The table below provides the commands to patch the ConfigMap depending on the SAS Viya version:

Viya Version	Commands
Any stable of LTS version before stable 2024.12	kubectl patch cm ingress-nginx-controller -n name-of-namespace -p '{"data":{"annotations-risk-level":"Critical", "strict-validate-path-type":"false"}}';
From  2024.12	kubectl patch cm ingress-nginx-controller -n name-of-namespace -p '{"data":{"annotations-risk-level":"Critical"}}'; Note : If the strict-validate-path-type configuration was modified for a previous SAS Viya platform deployment running ingress-nginx 1.12.x, it can be reverted with: kubectl patch cm ingress-nginx-controller -n name-of-namespace -p '{"data":{"strict-validate-path-type":"true"}}';

Ingress Common Vulnerability Exposures (CVEs)

Many versions of ingress-nginx are affected by several security vulnerabilities that could make it easy for attackers to take over your Kubernetes cluster.

See the Kubernetes announcement related to these vulnerabilities: Ingress-nginx CVE-2025-1974: What You Need to Know.

As a consequence, your SAS Viya platform deployment might be exposed to this vulnerability.

This security issue has the following associated CVEs:

• CVE-2025-1974 (Critical)
• CVE-2025-1098 (High)
• CVE-2025-1097 (High)
• CVE-2025-24514 (High)
• CVE-2025-24513 (Medium)

The best and easiest remedy is to upgrade to the new patched release of ingress-nginx .

Am I affected by this security issue ?

You can run this command to get the ingress-nginx version that you are running in your cluster:

kubectl get pods -A -l app.kubernetes.io/name=ingress-nginx -o jsonpath="{.items[*].spec.containers[?(@.name=='controller')].image}"

You should see something like this :

registry.k8s.io/ingress-nginx/controller:v1.12.1@sha256:d2fbc4ec70d8aa2050dd91a91506e998765e86c96f32cffb56c503c9c34eed5b registry.k8s.io/ingress-nginx/controller:v1.12.1@sha256:d2fbc4ec70d8aa2050dd91a91506e998765e86c96f32c

Look at the version after the "controller" word, in this example we are running ingress-nginx 1.12.1.

Remediation: Upgrade version

If, for your customer environment, you obtain a version listed below, SAS strongly recommends that you upgrade to a patched version of ingress-nginx (supported by the Kubernetes version on which your cluster is running).

  

The SAS Technical Support has published an article for the customers with all the required guidelines, SAS® Viya® platform guidance for Kubernetes Ingress-NGINX Controller CVEs.

Can I always upgrade to a patched ingress-nginx version to fix these security issues ?

Customers currently running Viya LTS 2023.03 cannot upgrade to an ingress-nginx version that includes the fixes for the CVEs. SAS Viya LTS 2023.03 supports K8s 1.23-1.25 but unfortunately the ingress-nginx maintainers did not provide a fix for the CVEs that is supported on Kubernetes versions older than K8s 1.26…This is outside of SAS's control.

SAS recommendation is to upgrade to a newer Viya LTS/Kubernetes version combination. SAS Viya LTS 2023.10, LTS 2024.03, LTS 2024.09 will all work with the CVE patched version of Ingress NGINX.

Note: Viya LTS 2023.03 is EOL in May 2025 (As soon as LTS 2025.03 will be released - which is currently planned for the 15th of May 2025), so the update to a newer version of  SAS Viya is inevitable to remain in standard support.

In the latest DaC tool (viya4-deployment) version (8.2.0), the default version of ingress-nginx delivered has been changed to one that contains the fix for the CVEs.

The NSG rule deletion issue

Finally, there is something else that changed with ingress-nginx 1.12. It affects sites running SAS Viya in Azure where firewall rules must be added to allow additional inbound access to the Ingress external address (for example to allow access from Microsoft Entra ID when SCIM is configured).

Before ingress-nginx 1.12

Before 1.12, if you had to allow both inbound access to the Ingress Controller:

• from Azure Entra ID (for the SCIM Client),
• AND from a range of IP address (corresponding to your clients IP addresses),

The proven practice was to :

1. Set the azure-allowed-service-tags annotation in your ingress-nginx controller definition (as shown below), for the inbound access from Azure Entra ID.

2. Then create your own Azure NSGs (Network Security Groups) - in the Azure portal or with the az CLI - to allow access from a specific range of client IP addresses…instead of using the LoadBalancerSourceRange specification in your ingress-nginx controller definition.

In the example below, you see the "manually created" NSG inbound security rule with a priority of 100 : it allows the access on port 80 and 443 from a range of IP addresses that correspond to our end-user’s IP addresses. But you also see the a rule generated (with a random name) from our azure-allowed-service-tag Ingress NGINX annotation which allow Azure Entra ID ("AzureActiveDirectory") to connect to our SAS Viya environment (for the SCIM push).

These guidelines are coming from this post written by Stuart Rogers.

In the post, Stuart explains in details, the reason to use "manually created" NSGs instead of the Ingress NGINX  controller.service.loadBalancerSourceRanges specification …basically loadBalancerSourceRanges uses IPTABLES to block any connection from outside of the defined range – hence preventing the access from Azure Entra ID !

This kind of setup has worked for several years.

However it was recently discovered that this setup would not work any longer with ingress-nginx 1.12 !

ingress-nginx 1.12 and after

What happens now, if you implement this setup with ingress-nginx 1.12 or later is that our "manually created" NSG rules is silently removed by Azure after some time  ! (1 to 3 days).

One of our colleague, at SAS, discovered the issue and, after some investigation, found out (from the ingress-nginx-controller logs) that Azure/AKS was periodically "reconciling" the ingress controller firewall rules with the NSG, with the changes being executed by the AKS service principal :

Warning ConflictConfiguration 3m15s azure-cloud-provider

Please use annotation service.beta.kubernetes.io/azure-allowed-ip-ranges instead of spec.loadBalancerSourceRanges while using service.beta.kubernetes.io/azure-allowed-service-tags annotation at the same time.

Solution

As suggested in the log message, the solution is to configure the ingress-nginx-controller service to use the   azure-allowed-ip-ranges annotation instead of creating the NSG rules directly in Azure.

This change allows Azure to properly create the required inbound NSG rules for both Entra/SCIM AND end-user source ranges.

Our colleague provided an example on how to patch a "DaC" deployed environment to implement the solution :

kubectl -n ingress-nginx describe svc ingress-nginx-controller

# add the "azure-allowed-service-tags" annotation to allow Azure Entra ID inbound access (SCIM)

kubectl -n ingress-nginx patch svc ingress-nginx-controller --type='json' -p='[{"op": "add", "path": "/metadata/annotations/service.beta.kubernetes.io~1azure-allowed-service-tags", "value":"AzureActiveDirectory"}]'

# remove the loadBalancerSourceRanges specification

kubectl -n ingress-nginx patch svc ingress-nginx-controller --type=json -p='[{"op": "remove", "path": "/spec/loadBalancerSourceRanges"}]'

# add the azure-allowed-ip-ranges annotation to allow a range of IP adresses to

kubectl -n ingress-nginx patch svc ingress-nginx-controller --type='json' \
-p='[
{
  "op": "add",
  "path": "/metadata/annotations/service.beta.kubernetes.io~1azure-allowed-ip-ranges",
  "value": "109.xxx.xxx.xxx/27,149.xxx.0.0/16,194.xxx.xx.xxx/28,10.0.0.0/16,13.xx.xxx.xxx/32,192.xx.xx.0/24,48.xxx.xxx.xxx/32,10.xx.xx.xx/16"
}
]'

But if you are not using the "DaC" tool (viya4-deployment) and want to install ingress-nginx on your own with Helm, you can use the script below (provided by Stuart Rogers) as a reference:

helm install  ingress-nginx --namespace ingress-nginx  \
--set controller.service.externalTrafficPolicy=Local \
--set controller.service.sessionAffinity=None \
--set controller.config.use-forwarded-headers="true" \
--set controller.autoscaling.enabled=true \
--set controller.autoscaling.minReplicas=2 \
--set controller.autoscaling.maxReplicas=5 \
--set controller.resources.requests.cpu=100m \

--set controller.resources.requests.memory=500Mi \
--set controller.autoscaling.targetCPUUtilizationPercentage=90 \
--set controller.autoscaling.targetMemoryUtilizationPercentage=90 \
--set-string
controller.service.annotations."service\.beta\.kubernetes\.io/azure-allowed-service-tags"="AzureActiveDirectory" \
--set-string
controller.service.annotations."service\.beta\.kubernetes\.io/azure-allowed-ip-ranges"="10.244.0.0/16, 149.xxx.xxx." \
--version 4.12.1 \
ingress-nginx/ingress-nginx

kubectl wait -n ingress-nginx --for=condition=available  --all deployments --timeout=60s

# Changed according to https://documentation.sas.com/doc/en/itopscdc/v_060/dplyml0phy0dkr/n02w9l89l6b6ttn1wncv617wndp3.htm

kubectl patch cm ingress-nginx-controller -n ingress-nginx -p '{"data":{"allow-snippet-annotations":"true", "annotation-value-word-blocklist":"load_module,lua_package,_by_lua,location,root,proxy_pass,serviceaccount,{,},\\"}}';

# Changes in 2025.02
if version_ge "$NGINX_Version" "4.12.0"; then
  # Changed according to https://documentation.sas.com/doc/en/itopscdc/default/dplyml0phy0dkr/p1deewvd9xtqiyn168adq6fu9msv.htm
  if version_ge "$CADENCE_VERSION" "2024.12"; then
    kubectl patch cm ingress-nginx-controller -n ingress-nginx -p '{"data":{"annotations-risk-level":"Critical"}}';
  else
    kubectl patch cm ingress-nginx-controller -n ingress-nginx -p '{"data":{"annotations-risk-level":"Critical", "strict-validate-path-type":"false"}}';
  fi
fi

In this case, the NSGs for both Entra ID and the range of allowed client IPs would be automatically generated in Azure as shown below:

Conclusion

That’s it for today…If you have read the whole post (part 1 and part 2) you should now be ready to move to the new ingress-nginx version 1.11.5 or 1.12.1 or later ! 😊 Thanks to Heather Hewlett, Tony Gianni and Stuart Rogers for sharing their knowledge and experience with the ingress-nginx setup and configuration.

Find more articles from SAS Global Enablement and Learning here.