NGINX: Bump to OpenResty v1.27.1.1.

[longwuyuan]

What this PR does / why we need it:

• A new Openresty release occurred https://openresty.org/en/ann-1027001001.html
• This PR attempts to bump OpenResty in the project as per above announcement's changelog
• There was a conversation on slack about uisng commit sha or version-number. Currently I have opted for version-number because it makes git the source of truth based on the changes here being a reflection of the Openresty v1.27.1.1 changelog
• Super important slack conversation on this here https://kubernetes.slack.com/archives/C021E147ZA4/p1729767000380529

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• CVE Report (Scanner found CVE and adding report)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation only

Which issue/s this PR fixes

fixes #12170

How Has This Been Tested?

• Changed registry in /images/nginx/Makefile to docker.io/longwuyuan
• Changed image in /images/nginx/Makefile to nginxbaseimage
• Executed make in the /images/nginx directory, on local clone
• It create a baseimage locally
• Changed /NGINX_BASE to longwuyuan/nginxbaseimage:v1.0.0
• Tested with "FOCUS=GRPC make kind-e2e-test". It passed
• Tested with full-suite "make kind-e2e-test
• Got a shell in the controller pod to confirm nginx version was v1.127.1
• grype is showing this status

NAME                   INSTALLED   FIXED-IN  TYPE       VULNERABILITY        SEVERITY 
grpc                   1.62.1-r0             apk        CVE-2024-7246        Unknown   
grpc-cpp               1.62.1-r0             apk        CVE-2024-7246        Unknown   
libaddress_sorting     1.62.1-r0             apk        CVE-2024-7246        Unknown   
libgpr                 1.62.1-r0             apk        CVE-2024-7246        Unknown   
libgrpc                1.62.1-r0             apk        CVE-2024-7246        Unknown   
libgrpc_unsecure       1.62.1-r0             apk        CVE-2024-7246        Unknown   
libupb_base_lib        1.62.1-r0             apk        CVE-2024-7246        Unknown   
libupb_json_lib        1.62.1-r0             apk        CVE-2024-7246        Unknown   
libupb_mem_lib         1.62.1-r0             apk        CVE-2024-7246        Unknown   
libupb_message_lib     1.62.1-r0             apk        CVE-2024-7246        Unknown   
libupb_textformat_lib  1.62.1-r0             apk        CVE-2024-7246        Unknown

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I've read the CONTRIBUTION guide
• I have added unit and/or e2e tests to cover my changes.
• All new and existing tests passed.

cc @rikatz @tao12345666333 @strongjz @Gacko

[netlify]

✅ Deploy Preview for kubernetes-ingress-nginx canceled.

Name	Link
🔨 Latest commit	bb15edb
🔍 Latest deploy log	https://app.netlify.com/sites/kubernetes-ingress-nginx/deploys/6761fcc30e70990008a7cab4

[longwuyuan]

/triage accepted

[strongjz]

need to bump the version TAG as well

https://github.com/kubernetes/ingress-nginx/blob/main/images/nginx/TAG

[strongjz]

That's how CI will start the build https://github.com/kubernetes/ingress-nginx/blob/main/.github/workflows/zz-tmpl-images.yaml#L41

[strongjz]

/kind feature
/priority backlog

[longwuyuan]

need to bump the version TAG as well

https://github.com/kubernetes/ingress-nginx/blob/main/images/nginx/TAG

@strongjz Bumped /images/nginx/TAG from v1.0.0 to v1.0.1. Please check

[Gacko]

Please do not bump the tag. Cloud Build triggers on any changes.

[longwuyuan]

@Gacko reset the TAG back to v1.0.0. Please check

[strongjz]

Please do not bump the tag. Cloud Build triggers on any changes.

Only on merges to main? Which we want to build the image and then cherry pick into a release.

[Gacko]

Currently Cloud Build is configured to trigger on any changes to the images, not only the TAG, on main and release-* branches. So merging to main would trigger it.

The thing about the TAG: It's part of the release and I'd rather not let it be changed by contributors as the decision to which version to bump to is being made during the release process. Like, last time I checked the changes of each image and then bumped the TAG depending on if it's only patches/dependency updates or real changes with more impact (minor version bumped then).

Also we're currently using different versions of the NGINX image across the branches as we removed Global Rate Limiting on v1.12 only, but still have it in v1.11 and v1.10. Therefore the former uses TAG v1.0.0 and the latter stay on v0.1.0.

tl;dr: IMHO the TAG should be bumped during release process only.

cherry pick into a release.

I'd not cherry-pick these changes to any of the release-* branches. It's a minor change and should only be released with a v1.13.

I hopefully find some time to review this PR this weekend. Please, if possible, do not merge before.

[strongjz]

We need the container built before the release.

1. Merge to main with tag update
2. cloud build runs
3. another pr to main to update nginx image sha
4. then cherry pick that to update it
5. release a new controller version

[Gacko]

I'm aware of that. But the container also builds if any file of the image changes: https://github.com/kubernetes/test-infra/blob/master/config/jobs/image-pushing/k8s-staging-ingress-nginx.yaml#L177.

So there is no need to bump the TAG, which's content should be decided by the ones forging the release, in this PR here.

Anyway, I hope I find some time to review it in the next days. Sorry for that!

[rikatz]

@longwuyuan please bump the TAG file at least to start the test build, we can figure out cloud-build after it.

Once the build passes, worst case we can revert before merging.

[Gacko]

There is no need to bump the TAG. Cloud Build is configured to trigger on any change in the whole directory, not just the TAG. Bumping the TAG to a proper version we then use in the NGINX_BASE is part of the release process, not part of development.

Also please do not merge this before we sorted v1.12 as we might build the NGINX base image from main and then populate everything to the other branches. With this PR merged before the v1.12 release, the base image will include unwanted changes.

/hold

[rikatz]

@Gacko the e2e tests runs with the new image when the TAG is bumped. I am not saying to merge, but I want to see the test passing

[littledan]

This patch is very important to land, to enable the security of ingress-nginx installations, given that nginx 1.25 is EOL. What will it take to land it?

[strongjz]

This patch is very important to land, to enable the security of ingress-nginx installations, given that nginx 1.25 is EOL. What will it take to land it?

We have spent the last few weeks debugging the nginx build in cloud build that was broken. We just got it working today. So we can start adding in PRs like this one. So soon. And most likely in 1.13.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: longwuyuan
Once this PR has been reviewed and has the lgtm label, please assign strongjz for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment