Jetstack Paranoia: A New Open-Source Tool for Container Image Security
1–10 of 11 posts
Re: Jetstack Paranoia: A New Open-Source Tool for Container Image Security
#2[dead]
Re: Jetstack Paranoia: A New Open-Source Tool for Container Image Security
#3I feel a bit conned by the headline, it would be better to say "verifying CA certs in images"
Re: Jetstack Paranoia: A New Open-Source Tool for Container Image Security
#4I feel a bit conned by the headline, it would be better to say "verifying CA certs in images"
I was also a bit confused and expected something like grype -https://github.com/anchore/grype
Re: Jetstack Paranoia: A New Open-Source Tool for Container Image Security
#5I feel a bit conned by the headline, it would be better to say "verifying CA certs in images"
I was also a bit confused and expected something like grype - https://github.com/anchore/grype
I was also expected something like this, but I didn't know for grype till now. Thanks!
Is there anything similar to this for npm packages?
Re: Jetstack Paranoia: A New Open-Source Tool for Container Image Security
#6Earlier quoted context omitted.
I was also a bit confused and expected something like grype - https://github.com/anchore/grype
I was also expected something like this, but I didn't know for grype till now. Thanks! Is there anything similar to this for npm packages?
I built Packj https://github.com/ossillate-inc/packj to scan NPM/PyPI/Ruby packages for CVEs and malicious/risky attributes.
Re: Jetstack Paranoia: A New Open-Source Tool for Container Image Security
#7Tools like this to me reinforce the broken state of TLS in the modern OS stack.
This looks great, but it's insane we need to do this: TLS really needs to be a kernel level, global feature. Take it out of the hands of applications, and let's add a pluggable system which extends the socket interface directly since that's theoretically what "transport layer security" is.
Re: Jetstack Paranoia: A New Open-Source Tool for Container Image Security
#8Tools like this to me reinforce the broken state of TLS in the modern OS stack. This looks great, but it's insane we need to do this: TLS really needs to be a kernel level, global feature. Take it out of the hands of applications, and let's add a pluggable system which extends the socket interface directly since that's theoretically what "transport layer security" is.
It's already hard enough to use web from Windows 2000 and other old operating systems. Making TLS kernel level feature will likely halt any TLS progress.
Google is moving TCP to user level (QUIC) for a reason.
Re: Jetstack Paranoia: A New Open-Source Tool for Container Image Security
#9In production it can be better to bind-mount the host's CA store, instead of relying on each container to have a correct and current CA database. This is especially needed if an enterprise CA is in use.
In general I think the unidirectional "layered" container image model is a stepping stone. It ought to be easy to replace the "runtime" layer for a container without rebuilding the higher layer holding the application code. I can replace the host's kernel without modifying the code; why can't I upgrade the container's glibc or Python?
Re: Jetstack Paranoia: A New Open-Source Tool for Container Image Security
#10In production it can be better to bind-mount the host's CA store, instead of relying on each container to have a correct and current CA database. This is especially needed if an enterprise CA is in use. In general I think the unidirectional "layered" container image model is a stepping stone. It ought to be easy to replace the "runtime" layer for a container without rebuilding the higher layer holding the application…
Take a look at buildpack layer model and caching options: https://buildpacks.io/docs/buildpack-author-guide/caching-st...