Why use docker (and not rkt)?

I (with not much insight in technical details) read that rkt has a security advantage over docker. As far as I understand the mater this is related to running processes inside a container as root or not). If that was to be said TRUE why is everybody still using docker?

not trying to initiate a flamewar here, just interested in some opinions from this audience

can it be no one has really answered that question for him/herself? I think itā€™s an interesting one still though ā€¦ anyone with some insights?

Honestly, I feel like Docker has a huge amount of momentum, but people are much less interested in the CoreOS stack than they used to be. I took a quick peek through rktā€™s claimed advantages and the security claims are generally around things most people donā€™t care much about, like having a strong chain of trust in signed images.

From what I can tell most Docker users donā€™t pay attention to even basic security things: they consider it acceptable that a development tool requires a TCP port listener that makes unrestricted, uncontrolled root access to their system available to anyone who can reach it, for instance. If ā€œrun containers as non-rootā€ is a security best practice (which Iā€™d believe) many many containers donā€™t do it (in part because it makes reusing host content tricky). And so on.

1 Like

@dmaze

Sounds like ppl should care abt those more (but maybe the hype [or ā€˜momentumā€™ as you put it] tends to wash all doubts away) in your eyes?

Iā€™d say more that people donā€™t know or donā€™t care. If you ever install software by curl http://... | sudo sh (and I see that recommended not infrequently) then thereā€™s a whole host of trust issues at all levels of the stack that can just go wrong (DNS spoofing on the host name, an attacker replacing the contents of the installer at the network level, ā€¦); but, itā€™s super convenient. If youā€™ve ever fought with Debian or Ubuntuā€™s signed package system, on the other hand, thereā€™s some deep magic incantations to get a signing key correctly imported, and if you get it wrong thereā€™s a bunch of scare warnings that, 99% of the time, donā€™t actually make a difference.

With Docker, even if itā€™s ā€œless secureā€, there are a ton of tutorials out there on how to use it and do standard things, including some ā€œinsecureā€ things like letting the application code be injected from a host directory outside the container systemā€™s control. I think most people donā€™t think of that as a tradeoff, unless youā€™re really a security expert. The choice between ā€œpopular, and securable, but with some not-quite-optimal defaultsā€ and ā€œtotally obscure but more secure in tiny-detail waysā€ is usually pretty clear for most people.

1 Like

A lot of folk bring up security without any context. Docker is used to conveniently install GitLab OSS on oneā€™s workstation. Docker is used to support CI/CD pipelines in engineering environments. Docker is used as the container format for multi-tenant, high-availability hybrid cloud environments. The security concerns of these things couldnā€™t be more different. Docker is popular in part because thereā€™s a culture and knowledge base around all of those use cases. IMHO, CoreOS has been focused solely on the data center side of things.

All of that said, Docker is not infrastructure nor is it InfoSec/AppSec policy enforcement. One could easily argue that the majority of security issues that occur today can be blamed on poor policy and poor infrastructure. Gaining root access on virtual host 3 of 200 should not give a malicious application keys to your castle. If it does, Docker is not your problem. Root access on a application host should mean very little, mitigated through limited permissions schemes and proper network segmentation. But again, this is not Docker specific.

2 Likes