Replying to 98fa4384...

nostr:npub1l3gpk6vrudg8r67swqlex5alv9ch59s4lw46kk6hekuxe2n3aczsyqvu48

Like, okay, you *can* (and usually do) build a Docker image from some base OS, but that's really only just to give your program the support it needs to exist. A Docker container is not, fundamentally, supposed to be a VM. It's an application running in a sandbox. There is no real OS around it, besides the libraries and support files it would need to run. There are no processes besides whatever is in the CMD line when building the image + whatever else that starts up.

This removes like 90% of the OS from the OS, and not many OS updates are going to really have any effect besides major version changes or urgent fixes.

(And even for urgent fixes, you *can* modify and rebuild the image yourself just by changing the FROM line)

nostr:npub1trdnqrfstufc45awha43p6xy2n0v6czuhapzh4r09hap08dg0c6s9gussx

nostr:npub17j5xgxhtskpcp0kjd9ldjhm3w6ggns7kkvfp44lk4qsrdwawmjeqvd0ny5 nostr:npub1trdnqrfstufc45awha43p6xy2n0v6czuhapzh4r09hap08dg0c6s9gussx

That's better, but if the application running on the image requires a raft of other programs running (e.g. LAMP/LNMP stack), that's still a huge leap of trust that those will stay sufficiently up-to-date.

Even without dependent processes, the libraries themselves can often be attack surfaces.

I get that it's a very convenient solution to a pretty hairy problem, but it introduces some pretty hairy problems of its own, no?

Reply to this note

Please Login to reply.

Discussion

No replies yet.