[HN Gopher] Sandboxing and workload isolation
___________________________________________________________________
Sandboxing and workload isolation
Author : sudhirj
Score : 102 points
Date : 2020-07-30 18:08 UTC (4 hours ago)
(HTM) web link (fly.io)
(TXT) w3m dump (fly.io)
| eyberg wrote:
| There's also unikernels which several work under firecracker.
|
| "The first, and really the big problem for the whole
| virtualization approach, is that you need bare metal servers to
| efficiently do lightweight virtualization;" <- this isn't really
| true anymore as unikernels can be deployed to {aws, gcloud,
| azure} as machine images and so can be as light-weight as your
| program needs.
| mrkurt wrote:
| We've been playing a lot with OSv. But unikernels aren't
| strictly sandboxing or isolation.
|
| If you're deploying a unikernel to ec2, you're just using their
| underlying isolation. You can't safely deploy multiple
| unikernels on the same ec2 instances without figuring out your
| own, nested isolation.
| eyberg wrote:
| Sure - the hypervisor is the isolation vehicle - the same as
| firecracker.
|
| The only? reason I can see for wanting to deploy N unikernels
| to one AWS instance is if you want full control on the
| orchestration of things like multi-tenancy, however, it is
| very much possible and it is possible on GCloud as well. It
| should be noted that you are in the same boat as firecracker
| here. They both use virtualization.
| hinkley wrote:
| I just cannot shake the feeling that everything Containers have
| promised us, I was promised back in 1991 with pre-emptive
| multitasking and protected memory.
|
| I also can't help but think we're going to end up with a
| microkernel with some sort of nested cgroups for user processes.
| Which is itself going to look a little bit like Erlang...
| watermelon0 wrote:
| Docker promised containers like we knew them from the past, and
| improved building and packaging procedures.
|
| In the past, we never had an easy way to package various
| applications (including all needed resources and executables).
| Each language ecosystem invented their own ways of packaging,
| distributing and installing the application, and this always
| relied on pre-existing environment.
|
| With Docker you don't care what versions of language runtime,
| or dependencies, each application runs, you can run them on the
| same machine. There are no incompatible dependencies between
| multiple Docker containers, everything almost always works.
|
| Same goes with building, image layers made building of images a
| lot easier, and doing incremental changes is fast. Of course
| there are downsides, image size can really grow if you are not
| careful, and you need to regularly rebuild images from the
| ground up, to ensure everything is patched.
| jnwatson wrote:
| Containers are the API hack we put in because we couldn't
| change POSIX. The isolation and packaging were available in
| 90's era capability-based OSes (and 70's mainframe OSes), but
| backwards compatibility is more important than anything else,
| so we build matryoshkas of OSes inside OSes.
| jayd16 wrote:
| Is that a surprise? Containers can mostly be summed up by file
| system isolation on top of process isolation. I think this is
| why we're seeing some work done on capability based OSes like
| Google's Fuchsia.
| kjeetgill wrote:
| Sorta, but I think you're missing the value proposition
| forest for the feature trees.
|
| I'm going to speak to the docker-style containers because
| that's what I'm most familiar with.
|
| Filesystem, process, and even network isolation facilitate
| the illusion of an application having a fresh install of an
| OS to a degree. This includes details like /dev/, a package
| manager, things sitting in /etc/.
|
| Added to that there's decent tooling for sharing,
| composing/layering, shipping, baking images. They're
| declarative (enough-ish) too.
|
| This is nice because that's a pretty decent compatibility
| layer across a ton of software like databases and webservers
| that have always run expecting a full host, services written
| with bare metal in mind, and new things too.
|
| The kernel isolation features are powerful enablers, but
| don't undervalue how important it was to have things sorted
| out for you, like ldloader quirks with different glibc
| versions against the same kernel. Real issue I had.
|
| Source: Too much futzing around with chroots.
| pjmlp wrote:
| For me we are kind of there already with hypervisors and
| managed language runtimes.
|
| The irony of having monoliths like Linux running type 1
| hypervisors, on Intel CPUs running ME.
| hashamali wrote:
| Love what the folks at fly.io are doing with edge deployed
| containers.
|
| Interesting comparison with Cloudflare's isolate approach which
| they expanded on earlier this week:
| https://blog.cloudflare.com/mitigating-spectre-and-other-sec...
|
| Seems like there is an edge compute option for any requirement
| these days!
| jamestenglish wrote:
| Anyone else having a hard time even reading this article because
| of the lack of contrast from text to background?
| denysvitali wrote:
| uhm, nope
| iancarroll wrote:
| We've deployed nsjail for our file conversion pipeline (i.e.
| ImageMagick) and it's been great -- very nice configuration
| language and strong isolation properties, with a manageable
| performance hit. Definitely easy to write a configuration that
| would not securely sandbox you, though, which seems like a strong
| point towards Docker or other more high-level solutions.
| louwrentius wrote:
| So light-weight virtual machines on a security-hardened code
| base.
|
| Have we come full circle?
| rhizome wrote:
| It's not a circle!
|
| https://media0.giphy.com/media/F5rQlfTXqCJ8c/giphy.gif
___________________________________________________________________
(page generated 2020-07-30 23:00 UTC)