Controller release 1.8.0

[James Strong]

1.8.0

Images:

•     registry.k8s.io/ingress-nginx/controller:v1.8.0@sha256:744ae2afd433a395eeb13dc03d3313facba92e96ad71d9feaafc85925493fee3
•     registry.k8s.io/ingress-nginx/controller-chroot:v1.8.0@sha256:a45e41cd2b7670adf829759878f512d4208d0aec1869dae593a0fecd09a5e49e

Important Changes:

•     Validate path types (#9967)
•     images: upgrade to Alpine 3.18 (#9997)
•     Update documentation to reflect project name; Ingress-Nginx Controller

For improving security, our 1.8.0 release includes a new, optional validation that limits the characters accepted on ".spec paths.path" when pathType=Exact or pathType=Prefix, to alphanumeric characters only. More information can be found on our Google doc, our new ingress-nginx-dev mailing list, or in our docs

Community Updates

We are now posting updates and release to our Twitter handle, @IngressNginx, and

on our new ingress-nginx-dev mailing list

All Changes:

•     Add legacy to OpenTelemetry migration doc (#10011)
•     changed tagsha to recent builds (#10001)
•     change to alpine318 baseimage (#10000)
•     images: upgrade to Alpine 3.18 (#9997)
•     openssl CVE fix (#9996)
•     PodDisruptionBudget spec logic update (#9904)
•     Admission warning (#9975)
•     Add OPA examples on pathType restrictions (#9992)
•     updated testrunner image tag+sha (#9987)
•     bumped ginkgo to v2.9.5 (#9985)
•     helm: Fix opentelemetry module installation for daemonset (#9792)
•     OpenTelemetry default config (#9978)
•     Correct annotations in monitoring docs (#9976)
•     fix: avoid builds and tests for changes to markdown (#9962)
•     Validate path types (#9967)
•     HPA: Use capabilites & align manifests. (#9521)
•     Use dl.k8s.io instead of hardcoded GCS URIs (#9946)
•     add option for annotations in PodDisruptionBudget (#9843)
•     chore: update httpbin to httpbun (#9919)
•     image_update (#9942)
•     Add geoname id value into $geoip2_*_geoname_id variables (#9527)
•     Update annotations.md (#9933)
•     Update charts/* to keep project name display aligned (#9931)
•     Keep project name display aligned (#9920)

Dependencies updates:

•     Bump github.com/imdario/mergo from 0.3.15 to 0.3.16 (#10008)
•     Bump github.com/prometheus/common from 0.43.0 to 0.44.0 (#10007)
•     Bump k8s.io/klog/v2 from 2.90.1 to 2.100.1 (#9913)
•     Bump github.com/onsi/ginkgo/v2 from 2.9.0 to 2.9.5 (#9980)
•     Bump golang.org/x/crypto from 0.8.0 to 0.9.0 (#9982)
•     Bump actions/setup-go from 4.0.0 to 4.0.1 (#9984)
•     Bump securego/gosec from 2.15.0 to 2.16.0 (#9983)
•     Bump github.com/prometheus/common from 0.42.0 to 0.43.0 (#9981)
•     Bump github.com/prometheus/client_model from 0.3.0 to 0.4.0 (#9937)
•     Bump google.golang.org/grpc from 1.54.0 to 1.55.0 (#9936)

[Igor Constansia (I.C.E.C)]

Hi there , 

First off , Nice work on the new release and at the looks of it , a new form to disccuss about the package. 

Dont want to sound like the party crasher, but how can we make the process of bumping some packages even smoother.
I am using prisma cloud for container scanning so I,ll point out 4 vulnerabilities that it found for this 1.8.0 releaase
"sha256:ea299dd31352594c776cf1527b319fe3afb4b535bd9ba1e005a28983edf66330"

Vulnerabilities
- go version 1.20.1 has 8 vulnerabilities - all are fixed in 1.20.4

- github.com/emicklei/go-restful/v3 version v3.9.0 has 1 vulnerability - Fixed in: v3.10.0

- github.com/sirupsen/logrus version v1.8.1 has 1 vulnerability - still open

- openssl (used in libssl3, libcrypto3, openssl) version 3.1.0-r4 has 1 vulnerability - Fixed in: 3.1.1-r0

Compliance

- Private keys stored in image 

Found:

/etc/ingress-controller/ssl/default-fake-certificate.pem,

/etc/ingress-controller/ssl/primary-ingress-primary-default-ssl.pem,

/etc/nginx/lua/test/fixtures/default-cert.pem,

/etc/nginx/lua/test/fixtures/example-com-cert.pem

I know that those are placeholder certs, but it looks like not the best way from a compliance standpoint, keys should be mounted on runtime instead of baking them in the image.

I would argue that there are allot of easy version bump releases, if the proccess can improve on that. Not that I know what to do, hence asking as an open question

Thnx

Igor

[Jintao Zhang]

Hi Igor,

Thank you for raising this question.

We can indeed improve the process to make it better, such as checking that all dependencies have been upgraded to the latest version before each new release.

However, there is also a problem here. Some of our dependencies may have vulnerabilities but are not on our critical path. It is obviously unreasonable to frequently upgrade them just because they need updating.

---

Best regards

Jintao

Igor Constansia (I.C.E.C) <igorcon...@gmail.com> 于2023年5月31日周三 06:41写道：

--
To unsubscribe from this group and stop receiving emails from it, send an email to ingress-nginx-...@kubernetes.io.

[James Strong]

For the vulnerabilities, it is always a moving target. Unfortunately, Trivy didn't report any when we did the release, and we do not have access to Prisma, so thank you for the scan results.

Can you open an issue to track these for the 1.8.1 release?

That would be a great improvement regarding the compliance requests for the keys. Can you open a separate issue for that as well?  If you would like to see it prioritized, please join us in our community meetings every other Thursday at 11 am Eastern, and pull requests are always welcomed.

Thank you,

James

[Yuan]

Is the reported sha and the released sha matching ?

--

[Igor Constansia (I.C.E.C)]

Hi Jintao, 

Your welcome, 

And indeed i would agree with your way of looking at it.

I dont have the intimate knowledge to know if vulnerabilities are indeed also critical for the ingress itself to decide if its a worth a hotfix release or just update along with the next new release.

I do would argue, 

it would be good that all installed packages are updated to there latest versions (offcource no breaking upgrades etc) for any release, catching the non critical updates let say

how exactly to do that , im not sure as im unfamiliar with the complete release process,,  I would imagen its a ''--no-cache' flag somewhere or "go get -u ./..." orso

Best regards

Igor

[Igor Constansia (I.C.E.C)]

Hi James, 

Indeed always a moving target and a hard one to keep updated.

And sure , ill open 2 issues to track these. Do templates exist for these or just go do my best short explanation for it , good enough ?

And yes I would love to join in sometime, Can u point me to the right join link, not sure if ill make it this thursday , else ill join next week

Thanks,

Best regards

Igor

[Jintao Zhang]

Please refer to this document https://docs.google.com/document/d/1DKlpcV6DAW0DsBrzh-OLkZvJQmABCVfRIRWBWjc4zOs

Igor Constansia (I.C.E.C) <igorcon...@gmail.com> 于2023年6月1日周四 04:17写道：

--