Alternative lightweight base image

[timconsidine]

@girish awesome !

[jadudm]

From a security standpoint, leaving dev packages out of the runtime container is a Very Good Thing.

So, a question (with a clear angle): do nodejs and ruby programs need dev tools to run, or do they need dev tools to build?

If the former, I'm surprised. If the latter, then a multistage build allows for a slimmer and more secure runtime container.

I could also be confused, which is a common state of being.

[timconsidine]

@jadudm my understanding is dev tools only for building, so multistage build is the way to go, generally and from attack surface perspective.
But I’m no expert.

[jadudm]

@timconsidine In my day job, we wouldn't be allowed to ship production containers containing dev tools without an exception from an ISSO. I'm also not an expert, but I know that I am not allowed to ship production containers that provide attackers with tools to build further attack tooling from within my app container. (Perhaps that's just a +1.)

[girish]

@jadudm I think @timconsidine is referring to the dev libraries, compilers, toolchains, shared objects etc as dev tools. I guess you are refering to the likes of programs that can say launch some network attack?

[jadudm]

In this instance, I am referring to (say) build-essential on Debian. If I have a C compiler in my runtime image, and someone compromises the host, they can build further tooling in the host because I gave them a hammer and nails.

We generally have to follow NIST guidelines, and therefore our containers:

1. Are not writeable (generally)
2. Contain only the packages necessary to execute the software in the container
3. Require allow listing for egress (meaning nothing in the container can talk to the outside world); this implies an egress proxy
4. Only allow specific connections in (ingress proxy)
5. ...

Cloudron does some of this already. (To be clear: the reason I only use the official packages, and stay up to date, is because I trust the core product. Kudos to y'all, always.)

Hence, the story I'm weaving (which I think Tim is as well) is that there might be a large, common build image for Cloudron (containing all of the build tools), but the runtime image (which a multistage build would copy into) is light/tight and shouldn't contain (say) a C/C++ compiler. You generally can't avoid having your language runtime(s) (e.g. ruby), but that doesn't mean that the runtime image needs the capability to install new libraries: everything should already be there for the app to execute.

Maybe that helps explain my thinking/comment.