Jetstack Paranoia: A New Open-Source Tool for Container Image Security

https://www.jetstack.io/blog/announcing-paranoia/

by nejlika • 4 years ago

35 9 4 years ago

jetstack.io

beny23• 4 years ago

I feel a bit conned by the headline, it would be better to say "verifying CA certs in images"

pulsar256• 4 years ago

I was also a bit confused and expected something like grype -https://github.com/anchore/grype

mirzap• 4 years ago

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?

XorNot2• 4 years ago

Tools 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.

vbezhenar• 4 years ago

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.

XorNot2• 4 years ago

Making TLS a kernel subsystem which dispatches to a common userspace provider though would not. The issue is that every application has to link and use TLS libraries on their own - they don't just ask the kernel for "a secure socket".

So we wind up in this space where a transport level protocol is for some reason being handled by the application stack, in a million different places and only somewhat common by convention (which we've gone and broken with containerizing userspace).

tedchs• 4 years ago

In 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?

jacobr1• 4 years ago

Take a look at buildpack layer model and caching options: https://buildpacks.io/docs/buildpack-author-guide/caching-st...

Jetstack Paranoia: A New Open-Source Tool for Container Image Security

Related Stories