Secure Your Containers with this One Weird Trick (RHEL Blog) [LWN.net]

Over on the Red Hat Enterprise Linux Blog, Dan Walsh writes about using Linux capabilities to help secure Docker containers. "Let’s look at the default list of capabilities available to privileged processes in a docker container: chown, dac_override, fowner, fsetid, kill, setgid, setuid, setpcap, net_bind_service, net_raw, sys_chroot, mknod, audit_write, setfcap. In the OCI/runc spec they are even more drastic only retaining, audit_write, kill, and net_bind_service and users can use ocitools to add additional capabilities. As you can imagine, I like the approach of adding capabilities you need rather than having to remember to remove capabilities you don’t." He then goes through the capabilities listed describing what they govern and when they might need to be turned on for a container application.

to post comments

Secure Your Containers with this One Weird Trick (RHEL Blog)

Posted Oct 17, 2016 19:11 UTC (Mon) by BlueLightning (subscriber, #38978) [Link] (5 responses)

I don't know about anyone else, but the phrase "weird trick" has been totally ruined for me by spammers.

Secure Your Containers with this One Weird Trick (RHEL Blog)

Posted Oct 17, 2016 20:48 UTC (Mon) by mgalgs (guest, #85461) [Link] (4 responses)

I believe it was supposed to be a joke.

Secure Your Containers with this One Weird Trick (RHEL Blog)

Posted Oct 18, 2016 2:28 UTC (Tue) by BlueLightning (subscriber, #38978) [Link] (3 responses)

Perhaps I'm humour-impaired, but I don't exactly feel inspired to click on the article by the title - quite the opposite.

Secure Your Containers with this One Weird Trick (RHEL Blog)

Posted Oct 18, 2016 11:54 UTC (Tue) by jzb (editor, #7867) [Link]

Can confirm, you are humor-impaired. ;-)

Secure Your Containers with this One Weird Trick (RHEL Blog)

Posted Oct 18, 2016 12:17 UTC (Tue) by lkundrak (subscriber, #43452) [Link]

I needed to have Mr. Poe explain that to me too.

Secure Your Containers with this One Weird Trick (RHEL Blog)

Posted Oct 19, 2016 2:54 UTC (Wed) by k8to (guest, #15413) [Link]

Personally, I could see the intended joke, but it didn't strike me as funny.
Maybe it it went a bit further down the rabbit hole ... "Auditors hate this!!"

Secure Your Containers with this One Weird Trick (RHEL Blog)

Posted Oct 17, 2016 19:40 UTC (Mon) by xorbe (guest, #3165) [Link]

[Click-bait intensifies]

Secure Your Containers with this One Weird Trick (RHEL Blog)

Posted Oct 17, 2016 21:30 UTC (Mon) by flussence (guest, #85566) [Link] (8 responses)

I prefer the Don't Install Gigabytes Of Shovelware That Needs Containerization To Be Secure In The First Place method, but I realise that makes me sound senile and not at all buzzword-compliant.

Secure Your Containers with this One Weird Trick (RHEL Blog)

Posted Oct 17, 2016 22:14 UTC (Mon) by josh (subscriber, #17465) [Link] (1 responses)

You clearly just need to buzzwordify it: DIG-O-STANC (Don't Install Gigabytes of Shovelware That Always Needs Containerization).

Secure Your Containers with this One Weird Trick (RHEL Blog)

Posted Oct 18, 2016 0:50 UTC (Tue) by HybridAU (guest, #85157) [Link]

Oh wow, that works surprisingly well, it actually rolls of the tongue.

I can almost hear the executives at their golf club meet up already... "Now that we finished our scalable agile cloud migration, our organization will be going completely dig-o-stanc next month."

Secure Your Containers with this One Weird Trick (RHEL Blog)

Posted Oct 18, 2016 4:07 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (5 responses)

I currently use jails on FreeBSD on my machines, but I am looking at moving to containers via the OCI spec built by buildroot, Debian, Fedora, and Docker (in decreasing preferential order). You can use the tech without the crap just fine, but you do have to realize you're swimming against the current.

Secure Your Containers with this One Weird Trick (RHEL Blog)

Posted Oct 18, 2016 16:18 UTC (Tue) by drag (guest, #31333) [Link] (4 responses)

If your goal is to reduce the fat then basing your containers off of operating system installs is a massive step in the wrong direction. Taking a distro and using it as the basis of your container is very common because it is the easiest and lowest friction way to get your application easily installed, but that does not mean it's the best results.

In the most ideal setup you would be running your application as part of some sort of SDK that tracks your application dependencies and only includes in your container images what dependencies the applications needs to run.

The easiest way to do this is to use something like goland that builds static binaries. This way your container can be as little as a single file.

Personally I think that perfect is the enemy of good, so using slimmed down versions of distro is perfectly acceptable.

Secure Your Containers with this One Weird Trick (RHEL Blog)

Posted Oct 18, 2016 17:03 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (3 responses)

My actual goal is to make it easier to maintain. Keeping ports up-to-date is a time consuming process while with containers, I can spin them up on a faster machine test them out, push them over and then restart using the new base image once I'm happy with it.

As for the usage of distributions, it's only because not everything is available in buildroot. The vast majority of the services I use are there, but some are not (e.g., the Haskell stack for my git-annex server), so until either cabal/stack is in buildroot and I can just install directly using it, I'll be using a bare-bones distribution base image.

Also, I plan on using systemd in containers (not all containers are single-process in my setup), so the "one static blob" isn't what I want anyways :) .

Secure Your Containers with this One Weird Trick (RHEL Blog)

Posted Oct 20, 2016 16:22 UTC (Thu) by drag (guest, #31333) [Link] (2 responses)

> Also, I plan on using systemd in containers (not all containers are single-process in my setup), so the "one static blob" isn't what I want anyways :) .

Instead of having multiple process per container try to do multiple containers.

Trying to add things like init systems or supervisor daemons to containers just complicates things needlessly a lot of the time. You already have a init system on your server. You don't need a dozen of them. :P

I understand that when porting a lot of applications may require managing multiple processes in a single container or at least you may need a intermediate step to speed things along in the porting process from 'traditional unix' to 'containers', but it is the sort of thing that is less then ideal.

Take a look at how kubernetes does things with it's 'pod' objects. With a 'pod' you can have one or more containers, but within a pod they all share the same network namespace. The pod is then managed as a single object. This way they can communicate with one another over localhost sockets.

It's not just eliminating the need for extra management process in the container, but it makes things a lot simpler in many ways... for example: Logging. With single process containers you don't need to bother double forking or daemonizing, creating log files, or syslog or anything like that. You just run in foreground and log to stdout and stderr. Whatever container management system you use should be able to just grab that output and deal with it appropriately.

I have spent most of my time with containers dealing with docker-based stuff (because the developers I work with prefer it and the ecosystem around docker is substantial), but I really like the CoreOS approach of leveraging containers directly on systemd rather then through a intermediate daemon like docker. They have their 'fleet' cluster service, for example. Fleet isn't meant to support thousands of containers or anything like that, but it's just a way to manage systemd (essentially systemctl remote control) across a cluster of nodes for the purpose of bootstrapping stuff like kubernetes.

Secure Your Containers with this One Weird Trick (RHEL Blog)

Posted Oct 20, 2016 19:49 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

FWIW, the only one which is currently conflated on my jails is dovecot and postfix (and that jail is disabled since I don't really have it working anyways); there's a dependency between them in ports. Doing it in containers will probably let be break them up. Off-hand, I can't think of any other jails with multiple services running at least; not sure about multiple top-level processes as much though.

Secure Your Containers with this One Weird Trick (RHEL Blog)

Posted Oct 24, 2016 20:36 UTC (Mon) by kleptog (subscriber, #1183) [Link]

> Instead of having multiple process per container try to do multiple containers.

I'd love to, except I got told by people on the #docker IRC channel that that's not really the end goal.

My use case wasn't too complicated, I wanted an nginx container and I wanted to be able to reconfigure it on the fly. The way I was doing that was by doing 'docker exec' in the existing container to rewrite the config file and reload the daemon. However, 'docker exec' won't be supported in the new swarm mode. Asking what I should be doing instead I was told that I should make a little daemon to connect to to reconfigure it. When I pointed out that that meant running multiple services in one container using something like supervisor they said that 'one service per container' was only an ideal anyway and not really the goal.

There are other (much less nice) ways of reconfiguring running containers, but 'docker exec' is really nice. Especially the unforgeable security credentials (if there are no root processes in the container and no setuid binaries, then any root process must have been spawned from outside).

Secure Your Containers with this One Weird Trick (RHEL Blog)

Posted Oct 18, 2016 0:49 UTC (Tue) by jcm (subscriber, #18262) [Link]

You'll never believe what happens at the end of this video!

Secure Your Containers with this One Weird Trick (RHEL Blog)

Posted Oct 18, 2016 14:04 UTC (Tue) by jhoblitt (subscriber, #77733) [Link]

But... how much will this save me on car insurance?

Secure Your Containers with this One Weird Trick (RHEL Blog)

Posted Oct 19, 2016 11:18 UTC (Wed) by biergaizi (guest, #92498) [Link]

Hackers hate it!