Comment by cookiengineer
3 days ago
Containers allow separation of access rights, because you don't have to pwn only one program/service that is running on the host system to get physical access to it.
Containers have essentially 3 advantages:
- Restart the containers after they got pwned, takes less than a second to get your business up and running again.
- Separation of concerns: database, reverse proxy, and web service run in separate containers to spread the risk, meaning that an attacker now has to successfully exploit X of the containers to have the same kind of capabilities.
- Updates in containers are much easier to deploy than on host systems (or VPSes).
> Separation of concerns
Sorta: yes the container is immutable and can be restarted, but when it does, it has the same privs and creds to phone up the same DB again or mount the same filesystem again. I'd argue touching the data is always the problem you're concerned about. If you can get an exec in that container you can own its data.
Why do you think ISOs never really took off? I feel like they solve so many issues but only ever see folks reach for containers.
Do mean VMs? ISO is a file format, commonly used for VMs and other computers.
For VMs, they did take off and essentially the entire cloud ecosystem runs on mostly VMs behind the scenes for VPS and similar hosting.
It's true though at it seems more popular for developers to reach for containers when they need to think about deployments, particularly docker containers. But VMs are still widely in use and deployed today.
1 reply →
Just thinking about this from a proxmox pov -- applying this advice, do you see an issue with then saying: take a copy of all "final" VMs, delete the VM and clone the copy?
And, either way, do you have a thought on whether you'd still prefer a docker approach?
I have some on-prem "private cloud"-style severs with proxmox, and just curious about thinking through this advice.
There's already unix permissions and regular namespaces. Docker is very hard to secure.