I think everyone here remembers that time they wrote a simple HTTP server, that just works, and would continue to work today.
If anything, I hope that we can recognize that there has been advancements in computing. Back in the day you would be open to attacks left and right. It was the wild west back in the day. Today, you can take that tiny webserver and put it in a VM, and voila, now it doesn't matter if anyone breaks in. As long as you didn't add the SSH key to github or anything like that.
We can have complex programs, as long as every-man doesn't have to know the details behind it, or implement it or risk losing access he previously had.
I think new protocols that are extremely hard to
implement falls under that, and I don't think Qemu or Linux does, as nobody loses anything when Linux adds new complex features.
We have to make sure, at least, that we continue to support HTTP/1. I think we already lost a lot when we moved away from IRC.
FCGI controlling Go programs, maybe front-ended by a load balancer and back-ended by MySQL/MariaDB/Postgres, can get an awful lot of work done cheaply.
FCGI is an automatic "orchestration system" - it starts up more instances as needed, restarts them if they crash, shuts them down when they go idle, and restarts them once in a while in case they leak some resource. It's like the parts of Kubernetes you really need.
Go is an OK language. Not a great language, but an OK language. It comes with almost everything you need for server-side applications. Also, the "goroutine" model means you don't have to fool with threads vs async. If a goroutine blocks on a lock, no problem; the CPU gets redispatched. If you need a million goroutines, that works, too. None of that "oh, no, the async thread made a call that blocked and screwed up the whole system".
MySQL/MariaDB/Postgres have been around for decades, and they work pretty well. You can have replication if you need it. (NoSQL seems to have come and gone.)
Get the stuff at the bottom right, instead of piling more cruft on top. It's cheaper.
What if 'advancements' were anything but? How would we know whether we're advancing a nascent engineering discipline in the best way possible? Is public cloud, an optimization for a certain calculus of engineering resources, the optimal form of computing delivery?
There's an underlying presumption about computing progress that has weaseled its way into your thinking, and the devil of it is that there are vanishingly few people willing to question it (can hardly blame them, given this thread).
You seem unfamiliar with the mystical energy force that always ensures the direction of "progress" is always positive for everyone. It's very un-techy to not believe in this, you need to immediately forget enough social science subjects so you can get back to the purity of ignorance.
James Mickens' 'Technological Manifest Destiny', cited at UseNIX 2018, is a real thing. At the time, listening to it, it was easy to chuckle, but I've since had a lot of sobering conversations with people in which I realized partway through that they really believed these things, and that's frightening.
Technological Manifest Destiny:
1. Technology is value neutral and will therefore automatically lead to great outcomes for everyone.
2. If we delay the rollout of new technology than we would delay the distribution of the inevitably great impacts for everyone.
3. History is generally uninteresting because the past has nothing to teach us right now.
You jest, but there is an actual argument somewhere in this dumpster fire arguing that philosophy cannot explain the overall direction of technology, as evidenced by a particular software's choice of license and the underlying assumption that technology is "different" from any other human endeavor.
Nebulous philosophical arguments do explain things. Quite readily, actually.
> Today, you can take that tiny webserver and put it in a VM, and voila, now it doesn't matter if anyone breaks in
This is a dangerous viewpoint to hold. Containers do offer some slightly better security, but they are not a silver bullet or anything close. There are still lots of ways to cause problems whether the software is in a container or not.
Short of CVEs, which are fixed after identification, can you point out other ways to "cause problems" with a tiny webserver serving static content in a container?
> What security do you gain by being in a container instead of on a server without a container?
I'm not a container guru, but... this is obvious, right? You have to break out the container, which is an extra layer. In order to get root on the server, you need:
• Without container: application vulnerability (to gain access to the OS) + kernel vulnerability (to gain access to root)
• With container: application vulnerability (to gain access to the container) + container breakout vulnerability (to gain access to the OS) + kernel vulnerability (to gain access to root)
You make it sound like I'm missing something — what am I missing here?
Why do you need to access the OS? If you break out of the web server, you have control of the container. You can then launch any sort of internal attack at the access level of the container. You could also launch a DDOS from the container.
Most of the bad stuff you can do when you take over a web server doesn't require root access, just user level access, and you get that whether or not it's in a container.
Containers share a platform. They increase attack surface by supplying a vector to any neighbour, by being something that can be attacked at all, and by requiring another control plane that requires credentials, making it a social engineering opportunity as well as being another component that itself can be vulnerable.
They are not an additional shell of defence, they do not reduce your blast radius.
> They increase attack surface by supplying a vector to any neighbour
Could you explain what you mean by this? I'm still not getting it.
Here's the example I have in mind: I have one application listening on a TCP port, and another one listening on a different port. I don't want the first application to talk to the second application. If they're just two processes on the same machine, they can both see each other, and an attacker who manages to exploit an RCE vulnerability gets access to the port "for free"; if they're both in containers, then they can only see the ports I specify, and it's really easy for me to specify them.
This literally does seem like an additional shell of defence to me! What sort of attack would it make worse?
Trusting the isolation like this is absolutely misguided, to the extent that it’s in conflict with understanding how computers work. Those who do not remember rowhammer or spectre and their kin are doomed to repeat them.
As for your example, there’s no difference between that and OS mediated mandatory access controls, separation of uids, chroot etc. Those capabilities are present irregardless of whether you’re using containers.
Anyone selling you on containers as a security measure is pitching snake oil. They are a resource allocation & workload scheduling tool. They may help applications avoid inadvertently treading on one another’s toes e.g. avoiding library conflicts or easing the deployment of, say, QA and showcase environments on the same metal, but it’s intrinsically a shoji wall.
There’s even a cultural downside, since developers may make exactly these flawed assumptions about runtime safety, or hard-code paths for config files rather than making them relative to deployment location, make assumptions (implicit or otherwise) about uids and so on, i.e. containers can breed sloppy dev practices.
I feel like you are several metaphors removed from me right now. Rowhammer? Spectre? I am just trying to serve a couple of websites here! I'm not going to buy another rack of servers just to isolate the two. Have you seen how expensive those things are?
> Anyone selling you on containers as a security measure is pitching snake oil. They are a resource allocation & workload scheduling tool.
I agree with both of these statements — and I suspect this is where it all falls down. When you put all your applications in containers, you are not done with security, no. Nevertheless, I've found great value in having one file per version per application, being able to upgrade my dependencies one-by-one, automatically rolling back in case of failure, and taking advantage of the tools in the container ecosystem. With all that, the security features such as isolating filesystems and network ports are just the cherry on top. Before containers, I was thinking about how to give my applications limited filesystems to work with, but along came Docker, and I didn't have to think about it anymore, because I'd already done it.
This is why I feel so out-of-touch with many of the commenters here. I'm surrounded by people decrying containers for security reasons, I want to defend them because of the many benefits they have given me, and I think the people preaching some kind of True Security (where everything is 100% perfectly isolated) aren't taking this into account. I feel like I could take your comment — "Trusting the isolation like this is absolutely misguided" — and apply it to any part of the stack. You have to stop somewhere.
I've seen the salespeople. They definitely exist, but I don't think they're here on HN, and they're more likely to be learning than lying.
And developers making flawed assumptions? You know this didn't start happening with containers!
> I am just trying to serve a couple of websites here!
Don't underestimate your responsibilities as an active participant online and operator of a globally reachable computing resource. Like driving a car, if you're not fully qualified and alert then you can endanger yourself and others. This is how PHP got such a bad rap.
The fact that the container deployment tool has helped you configure security elements (such as limited filesystem access) is nice, but those elements already existed, along with the tools to manage them. Containerized software deployment did not invent them, and if you're getting procedural benefits from containers, that's great for you, but that's all it is.
Having an additional layer of restriction (be it an alloation and workload scheduler or whatever) is additional security. The fact that there are vulnerabilities that bypass layers of security is irrelevant. The power button on the machine is a vulnerability to your software. The fact the restrictions are possible with other tools is irrelevant. Grouping functionality into a singular paradigm has utility.
To be fair, more security by additional tooling adds a vulnerability in human error, but that's true of all the tools.
If anything, I hope that we can recognize that there has been advancements in computing. Back in the day you would be open to attacks left and right. It was the wild west back in the day. Today, you can take that tiny webserver and put it in a VM, and voila, now it doesn't matter if anyone breaks in. As long as you didn't add the SSH key to github or anything like that.
We can have complex programs, as long as every-man doesn't have to know the details behind it, or implement it or risk losing access he previously had.
I think new protocols that are extremely hard to implement falls under that, and I don't think Qemu or Linux does, as nobody loses anything when Linux adds new complex features.
We have to make sure, at least, that we continue to support HTTP/1. I think we already lost a lot when we moved away from IRC.