Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Containers are tents

increment.com

Post reply on HN
Print view View original

71–80 of 109 posts

Re: Containers are tents

#71

Post by Saint_Genet »

foobar33333 wrote: post #66
Saint_Genet wrote: post #59

Earlier quoted context omitted.

Your first paragraph pretty much sums up what docker is, it’s a convenient way to design and build a system, but it is not a security mechanism. If you’re building a system that’s handling classified information, there is probably not an accreditation authority in the world that would let you use containers or even hypervisors as a way to separate different information classes.

Docker _should_ be secure, any part that isn't secure is a bug which can be reported. That disconnected to the reality of whether docker actually is secure, but in theory it is meant to be. Other implementation like podman get even better security by not running as root.

Absolutely it should be as secure as possible, but the fundamental concept of what a container is means it cannot be used for some high security concepts. One of the cornerstones of classified information security is physical separation, and containers just can’t provide that.

Re: Containers are tents

#72

Post by nyx__ »

jsiepkes wrote: post #54

Should be noted that a portion of this (valid) criticism applies specifically to the most prominent "container" implementation; Docker. Not containers as a whole. For example resources isolation with the Solaris / Illumos container implementation (zones) works just as well as full blown virtualization. You are just as well equipped to handle noisy neighbors with zones as you are with hardware VM's. > Much as you’d li…

Criticism applies to all Linux containers, not just Docker, which is one implementation of Linux containers.

One could argue that zones are distinct from containers (a Linux implementation), with both being OS specific versions of jails.

Re: Containers are tents

#74

Post by leephillips »

dijit wrote: post #68
leephillips wrote: post #65

I’ve found systemd-nspawn useful. Use debootstrap to install a minimal Debian system inside your system, then boot it with this command. It isolates the filesystem while sharing the network interface, and is convenient for most things that I guess people use Docker for. I wonder why it’s not mentioned more often.

I know it sounds like I want to be spoonfed, but do you have a walkthrough of this flow? I'd be interested in trying it out but I don't want to spend some hours reading documentation trying to get it working.

Well, that’s OK, because it did take me a while to track down the pieces of the documentation and find a procedure that worked for me. There is some less-than-optimal advice out there about this.

Become root.

Install debootstrap, which is in the Debian and Ubuntu repositories, at least.

Make a directory to contain your embedded system. It can be anywhere. Let's use /var/lib/machine/machinename.

This command will install a new, minimal Debian system in that directory:

debootstrap --include=systemd-container stable /var/lib/machines/machinename http://deb.debian.org/debian

It will download everything and, if I recall correctly, works unattended (doesn’t ask questions).

Enter the container with

systemd-nspawn -D /var/lib/machines/machinename/

and set the root container password with passwd.

Then do

echo 'pts/0' >> /etc/securetty

so the guest OS will let you log in after it's booted up. You may have to add other pts/x entries. I'm not sure about this part; it may be that if there is no /etc/securetty file that there is no problem.

Now log out of the container.

To boot up the guest OS, use

systemd-nspawn -b -D /var/lib/machines/machinename

You will see the familiar console messages.

You will find advice on the web to include the -U flag here, which causes files in the guest OS to only use UIDs known to the guest OS when determining ownership and permissions. This leads to headaches, because you have to set the ownership of any file you copy in from the host system. Leave it out, and you can have parallel users on the host and guest OSs, which is more convenient. But you may have to change the UIDs of the users on the guest OS so that they match.

Now, on the host OS, you can use the `machinectl` command to control all your guest OSs. `machinectl list` shows you what’s running, `machinectl login` lets you log in to them, and there are several commands for killing them with various levels of violence.

If you want your machine to be a long-running service, just `nohup` the spawn command, and direct output as desired.

If you want to be able to communicate with your machine from the internet, opening sockets from within the guest OS works, as they share the network interface. For a public-facing web service, you can install (for example) Apache and pick a port number to listen on, then set up a reverse proxy on the host OS, using a dedicated domain or a subdomain, so the users don’t have to use the custom port number. I’ve found that certificates for HTTPS need to be installed on both the host and guest OSs.

Good luck!

More information: https://wiki.debian.org/nspawn

Re: Containers are tents

#75

Post by aequitas »

rossmohax wrote: post #31

I believe, that success of containers is not because of lightweightness or other isolation properties of them. Containers won dev mindshare because of ease packaging and distribution of the artifacts. Somehow it is Docker, not VM vendors came up with a standard for packaging, distributing and indexing for glorified tarballs and it quickly picked up.

> Somehow it is Docker, not VM vendors came up with a standard for packaging, distributing and indexing for glorified tarballs and it quickly picked up.

Packaged VM's existed for a while already with thing like Vagrant on top, there was also already LXC which leaned more into the VM concept. Where Docker made the difference imho is with Dockerfiles and the layered/cached build steps.

Re: Containers are tents

#76

Post by otabdeveloper4 »

amarshall wrote: post #43
otabdeveloper4 wrote: post #41

Earlier quoted context omitted.

A Docker image is really just a .tar.gz under the hood, with a little bit of metadata. A Docker image is really just a chroot + some cgroups resource limits.

> A Docker image is really just a chroot + some cgroups resource limits. No, because an image specifies nothing about the runtime. Just add a Kernel and bootloader and one can boot most images. Further most container runtimes include a lot more than chroot and resource limits. Namespace isolation (process, user, network), seccomp rules, SELinux contexts, etc.

> Just add a Kernel and bootloader and one can boot most images.

Certainly not true of any of the images I work with.

Re: Containers are tents

#77

Post by flatline »

lanstin wrote: post #15
flatline wrote: post #11

Earlier quoted context omitted.

They are different means of composition. Dynamically (I assume that’s what you meant?) linked libraries allow you to compose binary artifacts. Containers allow you to compose services.

Not sure what you mean. The network lets you compose services. It has for decades been possible to do that. Containers as a form of static linking means that you ship one thing to prod and it has everything you need locally in it and it can’t be changed without you releasing a new one thing. If someone else upgrades MySQL client version on the host, your code keeps using the version you tested with, like a static bin…

Interesting. I think you are talking about intra-container composition, and I’m talking about inter-container composition. I see what you are saying (I think) about dependencies within a single container.

Re: Containers are tents

#78

Post by luord »

I've seen the problems of treating containers as houses, primarily during development: Multiple different processes inside a single container, with a wrapper around them (inside the container) that makes it even more difficult to debug.

So, assuming I understood correctly, treating them like tents is infinitely the better choice.

Re: Containers are tents

#80

Post by amarshall »

otabdeveloper4 wrote: post #76
amarshall wrote: post #43

Earlier quoted context omitted.

> A Docker image is really just a chroot + some cgroups resource limits. No, because an image specifies nothing about the runtime. Just add a Kernel and bootloader and one can boot most images. Further most container runtimes include a lot more than chroot and resource limits. Namespace isolation (process, user, network), seccomp rules, SELinux contexts, etc.

> Just add a Kernel and bootloader and one can boot most images. Certainly not true of any of the images I work with.

What sort of images are you working with? I can fairly straightforwardly boot debian:stable with no modifications to the image using direct kernel boot. Is everything perfect? No, but it does boot.
Post reply on HN