Normalize asking "but why do i need docker" for an app that is literally just an executable + database.

Security, resources' limits/quotas, price, not caring about platform differences/changes

because for "just an executable + database", setting up docker takes less brain power and time than writing this rant. if it's not already part of the project template.

"just a database"
When running a server/program during development I don't wanna mess around with some database fuckery and ports and setting up an own user and fixing file system perms and fixing the schema because apparently the system updated postgres and it's now incompatible

@netikras

Docker is per se more insecure, which is kinda funny.

... you built your own docker images, which updates all packages regularly.

Most images are built once per version and then never updated.... Which is a pretty nasty problem.

What I really hate about docker is that to do it right and proper you have to really go all out.

E.g. for proper permissions, you'll most likely will have to built your own images plus fixed user. 999:999 is a gentleman agreement.... If the upstream even realize root is a bad idea.

Then removing things like gosu / tinyinit etc.

Assuring image is rebuildable without breakage… so setting up apt pinning plus necessary pipelines to pass the version to the image by an ARG.

Finding and fucking around with many docker specific shenanigans, e.g. iptables might not be working as intended (docker uses iptables for routing, breaks for example firewalling scripts like UFW).

Multiple networks means that the default hostname must not be used (cannot be deactivated... Autogenerated hostname based on container id is present in all networks :/ which can end up badly with things like DNS discovery...)

Tons of other stuff.

I like Docker never the less. But it always amazes me what a toxic jar of poison it is....

... And how shitty some images Dockerfiles are written.

@IntrusionCM by secure I meant the higher scale. When someone obtains an rce, they can't touch other apps running on the same server. Hell, they can't even break out of the virtual network into the company's true lan

@netikras

In theory.

Don't get me wrong, I totally agree with you.

But it only applies if done right.

If you e.g. have an reverse proxy running as an TLS terminator with public ports and you never update the image, you have a gaping security hole.

HTTP smuggling and other security holes make it possible to bypass everything.

Not trying to be nitpicky - but in my current company I'm still whacking heads cause even after 4 years some people claim that docker / kubernetes or whatever OCI or similar thing is *magically* more secure.

Whacking as that magic means caring for security issues and other things... Not dumping some image in a registry and letting it rot for years *rolls eyes*

Which is in my experience a common "practice"... I'm still explaining to people after 4 years that if an image isn't regularly updated its a security leak and thus the plug will be pulled.

Sorry when I went a bit on a rampage here, but yeah. 4 years plus and still I hear the same comments.

I'm pretty sure you're more wise then that, it just triggered me immensely.

@IntrusionCM idk if I'm more wise. I agree that stale inages get their sec vulns discovered and w/o dependency refresh/upgrade they will be more vulnerable.

I'm not aiming this layer. Apps will eventually get hacked, exploited, etc. That's on devs [mostly]. My main concern is what happens when the app is hacked: at which layer access can be gained and what is the possible worse impact. E.G. Will the hack be isolated to the hacked component or will the ransomware spread uncontrolled in company's intranet/lan.

I believe containerization [container networks] contains the attack inside the container for the most of it. Containerized networks can be easily restricted, at least in k8s. That's why I assume docker [OCI] networks are safer for the company's infrastructure [NOT the application running in it]

@netikras that makes you already wiser than most people.

Security is always a game of matryoshka dolls - you have to stack it, otherwise its useless.

If you rebuild the images regularly (1), have a non root user with no su(do) running the image (2), have a single entry point like a TLS terminator so only one application is reachable from the outside (3), isolate and seperate networks (4), ensure the containers access to non containers is restricted - meaning container access to the internal network outside the docker host - by for example firewall / VLAN (5).

Thats 5 different things docker can do.

... If used properly / wisely / ... Whatever adjective fits best.

As I began working in this company, none. Like zero / nada / null / niente. Best practices were followed. That seems to be a pattern with Docker. ;)

@IntrusionCM yeeeah... I guess the right conclusion would be that Docker makes it easy to enhance your infrastructure's security, assuming you are using those knobs and levers that come with it :)