custom-error-pages: Add an ability to disable "/metrics", "/healthz" and "/debug/vars" endpoints

[ucinskij]

The custom-error-pages backend does it job pretty well, however during a security scan it was detected that it exposes three endpoints: /metrics /healthz /debug/vars

/metrics and /healthz are implemented by https://github.com/kubernetes/ingress-nginx/blob/499dbf57af5d0d7eb2fdb298cc89b5f4bf179854/images/custom-error-pages/rootfs/main.go#L78

/debug/vars at a first sight seems to be coming with github.com/prometheus/client_golang which includes expvar: https://pkg.go.dev/expvar

Especially the first and last ones expose information that might be considered as 'sensitive' by some organizations. Hence why I would like to ask for a feature toggle that would allow to disable those endpoints. It is to be considered if those should be exposed by default or not.

[longwuyuan]

@rikatz seems like one reason to focus on this, like you had suggested. Will do as per your advise

[strongjz]

/triage accepted /priority backlog /kind feature /assign @strongjz

[Routhinator]

FYI I've just had this bug raised from a OpenBugBounty. None of the things exposed are overly sensitive here, but this does leave an operator unexpectedly exposed to any CVE related to these endpoints. They are exposed publicly and reachable from the internet as soon as someone uses the custom-error-pages container.

[Routhinator]

Defaults should definitely prevent these from being reachable by the internet. Scrapeable by internal services by default, sure - but never exposed to the internet by default.

[ucinskij]

Hi @strongjz, I don't intend to put any pressure here but perhaps you know when we could expect this to be done? Unfortunately internal security scans within the company reqiure an action on this from our side, the security team simply complains too much about this.

[Hexcles]

You can use my fork https://github.com/Hexcles/nginx-errors

---

Sent from my cellphone.

On Thu, Feb 9, 2023, 02:37 ucinskij @.***> wrote:

Hi @strongjz https://github.com/strongjz, I don't intend to put any pressure here but perhaps you know when we could expect this to be done? Unfortunately internal security scans within the company reqiure an action on this from our side, the security team simply complains too much about this.

— Reply to this email directly, view it on GitHub https://github.com/kubernetes/ingress-nginx/issues/9152#issuecomment-1423758401, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAK6ZDC2ZML7BVB4WTOOPNLWWSNDJANCNFSM6AAAAAAREBT76I . You are receiving this because you commented.Message ID: @.***>

[strongjz]

@ucinskij We are trying to find the best tool/practice to make sure things are getting addressed. Currently we are using the project board here to track our work and what needs to be worked on next or who is asking for feature/PR review.

https://github.com/orgs/kubernetes/projects/104

All new issues get added to the board but I have not added older ones. I will add this one to the board.

Another good way to keep this in our attention is to join the community meetings as well. We discuss issues, prs and open items like this to prioritize.

right now we have several CVE's we are trying to remediate and get updates out for ingress-nginx, then we can look to implementing features like this. If you are interested in taking the time and implementing it, we can discuss that 1x1.

Thank you, James

[0xgui]

Any update on this ?

[ricardoapl]

I would like to work on this issue if that's OK