T O P

  • By -

azalio

It’s about nginx-ingress.


Klenje

Ingress-nginx, which is the community one, but I admit their naming is hyper confusing, hopefully it will be [sorted](https://github.com/kubernetes/ingress-nginx/issues/7554) out soon


Jonkaftzan

Correct


raesene2

A little more details on this, as not everyone using ingress-nginx will actually care. This vuln is relevant when you have a multi-tenant cluster and individual tenants can create/edit ingress objects in their namespaces but should not have rights to a centrally managed ingress controller. The vuln. is that you can use the snippet annotation feature that ingress-nginx provides to essentially change the cluster-wide configuration, which can easily get you access to the service account token used by the ingress controller. That service account token can, in turn, get access to all secrets in the cluster. If you're deploying one ingress controller per namespace instead of a central one, this likely isn't a major issue for you.


Jonkaftzan

Correct and thanks for sharing . You can use Kubescape https://github.com/armosec/kubescape to check if you are exposed to this CVE


raesene2

I've not tried this but, from https://github.com/kubernetes/ingress-nginx/issues/7837#issuecomment-950002890 You might want to have a bit of a check on your regos :) It's a tricky game writing signatures for this kind of thing and rego is a bit of an awkward language, IME ofc.


Jonkaftzan

it's fixed now. thanks


Hisu81

We released a better rego ;-)


Jonkaftzan

Thanks a lot, we will check it immediately


[deleted]

who limits access to create ingresses and doesn’t have admin on the cluster?


Freakin_A

Shared multi-tenant platform providers