Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kubernetes ingress-nginx controller vulnerability

armosec.io

Post reply on HN
Print view View original

41–50 of 52 posts

Re: Kubernetes ingress-nginx controller vulnerability

#41

Post by zzyzxd »

Although this particular vulnerability is all about ingress-nginx and has nothing to do with Kubernetes itself, the current design of the ingress API sort of encouraged it.

The reason that an ingress controller need permission to read all secrets across all namespaces in the first place, is because ingress objects can specify their own certs (stored in namespaced secret objects) within their namespaces, hence the ingress controller needs permission to read those secrets and load the certs into the reverse proxy (in case of ingress-nginx, it is nginx). This is such a scary permission to grant that cluster admins have to hand over all the secrets in the cluster to the ingress controller and hope it does the right thing.

Now, ingress-nginx actually allows you to specify a default secret to be used by all ingresses it manages, and that would be the only secret it needs access to. I am not sure how many users out there are willing to dig into thousands lines of its manifest yaml files to tweak its rbac settings.

Re: Kubernetes ingress-nginx controller vulnerability

#43

Post by spockz »

hn_throwaway_99 wrote: post #22
asguy wrote: post #10

> Hey Everyone, here's a high severity vulnerability report, to check for it, run the folliowing: curl -s https://raw.githubusercontent.com/noideawhatyourerunning/ins... |/bin/bash .... oh man

Honestly, this kind of made my blood boil, and just points out how difficult security can be. Here is presumably a security company , in their own blog post outlining a high-severity vulnerability alert , advocating that you run untrusted code from some rando GitHub repo. It also outlines my fear about dealing with some "security consultants", because on the one hand they outline all of the things you need to "box ch…

I thought that was entirely their point?

Re: Kubernetes ingress-nginx controller vulnerability

#44

Post by hn_throwaway_99 »

spockz wrote: post #43
hn_throwaway_99 wrote: post #22

Earlier quoted context omitted.

Honestly, this kind of made my blood boil, and just points out how difficult security can be. Here is presumably a security company , in their own blog post outlining a high-severity vulnerability alert , advocating that you run untrusted code from some rando GitHub repo. It also outlines my fear about dealing with some "security consultants", because on the one hand they outline all of the things you need to "box ch…

I thought that was entirely their point?

Entirely whose point?

Re: Kubernetes ingress-nginx controller vulnerability

#45

Post by notabee »

tbrownaw wrote: post #5
jeffbee wrote: post #2

Are they for real with that curl? Normalize better security practices!

I think it's contrary to currently-recommended ops practice (clearly imperative rather than nominally declarative), but how is it bad security practice? If you don't trust the origin, it's not like saving to a temporary file first is going to help you. Unless you're suggesting that everyone should always do their own code review and then compile from source...

Here's some discussion about that. But to put it simply, security is done in layers. Checking something simple like a script before running it is relatively easy and can catch low-effort malicious attempts. Sure, it won't protect against an advanced persistent threat doing a supply chain attack, but you're probably much more likely to be hit with low effort attacks that could be avoided by just not being careless.

https://news.ycombinator.com/item?id=17636032

Re: Kubernetes ingress-nginx controller vulnerability

#49

Post by lsandler »

capableweb wrote: post #38
corobo wrote: post #29

Earlier quoted context omitted.

It does that in the script for you :)

Not only that, they don't do any checksum checks either, and seem to not even publish checksums.

While I understand the concern with curl | bash, this method is used in many different open source product installations. The sh file is coming from github - pretty trustful source. You can always watch it in the browser (github will not trick you into different version) but you can also curl it or just download the source from the repository (just half a page above). You can also always review and rebuild the entire tool - another beauty of the open source. But most people just want to use the tool as fast and as simple as it can be. I guess there are options for any possible taste.

Re: Kubernetes ingress-nginx controller vulnerability

#50

Post by cassianoleal »

xnxn wrote: post #34
cassianoleal wrote: post #14

Earlier quoted context omitted.

It is unclear whether this is a problem if you're running namespaced ingress-controllers though. This comment [0] in the bug report says: there's definitely an attack path that gets the ingress-nginx service account token, which has list rights on secrets at a cluster level (so allowing for all secret values to be retrieved). I can't see how list permissions would allow retrieval of the secret value though. You'd nee…

> You'd need get permissions for that. I'm afraid not. HTTP GET on a collection endpoint (which is the operation represented by the list verb) returns the full object content. https://kubernetes.io/docs/reference/access-authn-authz/auth...

Interesting, thanks for the reference. This is at best surprising, at worst sloppy security design IMO.
Post reply on HN