Live data from Hacker News

Kubescape – tool for testing if Kubernetes is deployed securely

github.com

31–40 of 104 posts

Re: Kubescape – tool for testing if Kubernetes is deployed securely

#31
post #22
post #16

Earlier quoted context omitted.

There is debate on whether this is really a security concern. [0] https://www.arp242.net/curl-to-sh.html [1] https://sandstorm.io/news/2015-09-24-is-curl-bash-insecure-p...

There is a vast community who thinks it's bad, and unsafe (with examples on how to detect direct piping to bash in order to serve malware) and a few ones condoning it. That seems like saying there is currently a debate on the roundness of the planet Earth.

Yes, it's exactly like that, but not in the way you think.

One side is a small-but-vocal minority making silly arguments. "how to detect direct piping to bash in order to serve malware"? An attacker who tries to serve different things to different people will easily be caught, and a simple diff will highlight their exploit. A much more robust attack strategy is to serve the same malware to everyone but obfuscate it. Make the vulnerability look like an innocent bug, and you have plausible deniability. This same attack works for every approach to software distribution, it's not unique to curl|bash.

The vast majority of pragmatic people just don't think there's an issue here, don't find these arguments convincing, and don't care to argue about it. I run the Sandstorm project, which uses curl|bash, and this issue really hasn't impacted adoption. Our users aren't naive, they understand what curl|bash is, but they also recognize that obviously by installing our software they are giving us arbitrary code execution. Users who don't trust us install Sandstorm in a separate VM -- the only reasonable way to run software you are suspicious of.

Re: Kubescape – tool for testing if Kubernetes is deployed securely

#32
post #15

Earlier quoted context omitted.

What alternative pattern would you suggest?

binary packages, maybe through github releases. debian packages, potentially upstreamed into the package repos (though that's some effort). It's quite presumptive to presume to know how a target system is to be configured. no matter which alternative, curl|bash is security risk enough to never use: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b... gpg can help (below from zerotier): curl -s ' https://ra…

In all of these cases you also outsource the security to someone that you trust. How is that different from curl https... | sh ? Who says that no one took over the github, or the debian package?

Re: Kubescape – tool for testing if Kubernetes is deployed securely

#33
post #17

Kubernetes? God forbid! Very few companies have mastered this technology, and frankly, no one needs it. That such a testing tool is necessary confirms my assumption. Security is now outsourced.

Security has been outsourced ever since hardware.

Re: Kubescape – tool for testing if Kubernetes is deployed securely

#34
post #25

Earlier quoted context omitted.

What's the advantage of binary packages through GitHub releases? How do you audit them? I'm aware of the fact that you can detect curl | bash server-side, and it's a neat trick, but I don't understand the security risk of it. The server is supplying you with arbitrary content that you're not auditing - what does it matter if it supplies you different arbitrary content? What's the advantage of the GPG approach? Last I…

I think you may be conflating the application owner and the delivery system. If we're installing the application I think we're implicitly trusting the author. If you copy/paste http instead of https then you've given execution control to every single middlebox along the way. If the code is hosted on an evil sourceforge, then you've given them execution control. deb packages will do signature checks, any many authors…

All these arguments apply no matter the packaging format. Install scripts can be signed and checksummed too. Only by having your package put into a repository already trusted by the user in advance do you solve these problems, it's not an issue with the packaging format being a shell script versus a deb package.

Re: Kubescape – tool for testing if Kubernetes is deployed securely

#35
post #4

Earlier quoted context omitted.

cool! happy to hear that. if you have any ideas or comments about Kubescape, we would love to hear them

If you could check for container signing and providence on all materials and make sure that only a single registry is being used (ex only `internal.company.com:443`) and make sure it's not possible to schedule pods with unsigned/untrusted containers that would be awesome.

s/providence/provenance

Re: Kubescape – tool for testing if Kubernetes is deployed securely

#36
post #17

Kubernetes? God forbid! Very few companies have mastered this technology, and frankly, no one needs it. That such a testing tool is necessary confirms my assumption. Security is now outsourced.

So if I were to make a daft assumption that frankly, no one needs DNS, and then the NSA were to bring out a DNS infra hardening guide then I would also be correct?

Your comment is nonsense.

Re: Kubescape – tool for testing if Kubernetes is deployed securely

#37
post #34

Earlier quoted context omitted.

I think you may be conflating the application owner and the delivery system. If we're installing the application I think we're implicitly trusting the author. If you copy/paste http instead of https then you've given execution control to every single middlebox along the way. If the code is hosted on an evil sourceforge, then you've given them execution control. deb packages will do signature checks, any many authors…

All these arguments apply no matter the packaging format. Install scripts can be signed and checksummed too. Only by having your package put into a repository already trusted by the user in advance do you solve these problems, it's not an issue with the packaging format being a shell script versus a deb package.

I don’t think you understand how signed packages work. They give you the ability to be sure you are installing software packaged by an entity you trust, regardless of where you get the package.

Re: Kubescape – tool for testing if Kubernetes is deployed securely

#38
post #34

Earlier quoted context omitted.

All these arguments apply no matter the packaging format. Install scripts can be signed and checksummed too. Only by having your package put into a repository already trusted by the user in advance do you solve these problems, it's not an issue with the packaging format being a shell script versus a deb package.

I don’t think you understand how signed packages work. They give you the ability to be sure you are installing software packaged by an entity you trust, regardless of where you get the package.

I understand. That only moves the problem to where you get the signature from, it doesn't solve it (unless you are using a central repo you already trust for example). Therefore binary packages shipped on a GitHub releases page alongside a signature file still face the same issue. An attacker simply has to replace both the package and the signature with one they control. It is nothing to do with the packaging format being a deb file instead of an install script, the issue applies in either case.

Re: Kubescape – tool for testing if Kubernetes is deployed securely

#39
post #15

Earlier quoted context omitted.

What alternative pattern would you suggest?

binary packages, maybe through github releases. debian packages, potentially upstreamed into the package repos (though that's some effort). It's quite presumptive to presume to know how a target system is to be configured. no matter which alternative, curl|bash is security risk enough to never use: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b... gpg can help (below from zerotier): curl -s ' https://ra…

They actually have binary releases created through github: https://github.com/armosec/kubescape/releases/tag/v1.0.64

The only thing the installer script is doing is autodetecting your OS, picking the correct binary release, downloading it, making it executable, and copying it to /usr/local/bin. The installation instructions could just as easily tell you to do that. As with most go programs, the entire thing is just one file. No libraries, no config files, no dependencies.

Heck, wrapping it in a deb, rpm, and tarball for pacman would be easy as heck, just a one-line installer script: install -m755 /bin. I guess single-application developers just really don't like package managers.

Post reply on HN