new Blog( perso );

Docker daemon is extensible by plugins, allowing network, volumes, authorization and (in last version) logs and metrics management to be plugged in and controlled from external services.

As I'm investigating Docker infrastructure security in the contexte of a CI/CD service, I've been looking for ways to lock down docker daemon so it only allows a subset of the Docker API. Typically, I want to disable bind mounts to ensure one can't just make crazy things like :

docker run -v /:/target alpine rm -rf /target/*

(don't try this at home)


There's various solutions to prevent bad things to happen, including enabling the user namespace, but a second protection barrier still makes sense #DefenseInDepth.


So I've been investigating authorization plugin for docker daemon.

Step 1 : Architecture

Authorization plugin are invoked by deamon for any API call, either from docker socket or http clients. User identity is based on TLS key, so one could create such a plugin with user profiles, so some super-admin with adequate TLS key could do anything, and all others would have restricted access to the API. You can chain authorization plugins, so depending your needs you can keep them simple, or just plug existing ones.

Authorization plugin only implements 2 http endpoints, one to authorize the incoming API request, and the second to authorize the resulting output. This design allows to filter some API calls or to block some data to be exposed by the daemon. It's sometime simpler to let the daemon run some read-only API calls (like inspect)  then check the result to ensure no sensible data is exposed.

To write such a plugin, you'll need to understand which API are actually used by a docker CLI command. Typically, docker run -it  actually uses a bunch of them to pull image, create and start container, attach stdin/out. A simple way is to just look a docker daemon logs when debug is enabled.

Also note authorization plugin can't make changes to the incoming request, so you can't for sample remove some parameters or add some additional ones, like forcing a label to a container to track which user created it. I'd like to do this so I can prevent a later docker exec command to enter a container someone else created. To do this from this plugin I'll need to become stateful and store some container :: owner map.

Step 2 : Code

I've implemented my plugin in Go, using go-plugin-helper skeleton. There's not much done by this lib, but I'm lazy :P

I spent some time fighting with GOPATH and (lack of) dependency management in Go language. Typically, go-plugin-helped do depend on go-connections, and I've been hurt by this change as go-connection has some tags but go-plugin-helper doesn't, so dep I'm using to manage dependencies just pulled incompatible code. I like go development but dependency hells is really a terrible issue for this ecosystem.

Plugin's code is available on github. There's nothing magic here, just a whitelist for API calls I authorize and a specific parameter check for 'docker run'  to ensure no bind mount is user, nor Privileged containers creation.

I could also have used twistlock authz plugin with a custom profile, but

1. I'm not sure this plugin is more than just a proof of concept (twistlock offers a proprietary more advanced security service, so don't expect this project to do more than just basic filtering)
2. One learn more by getting hands dirty. Or maybe this is some sort of NIH syndrom :P 

Step 3 : Test

You can ask my colleagues : I'm not used to write unit tests (and that's probably bad) but here I did at least for a simple one :P. But unit tests only cover local code execution, let's try to deploy this plugin on a real docker daemon and validate it actually does the job.

To avoid breaking my local docker installation (sic) I created a virtualbox test environment using docker-machine (yes, despite docker4desktop supersede it for developer experience, this project still is useful). So we now have a sandbox, let's play

Step 4 : Deploy

Authorization plugin deployment is not a smooth process. I would expect I can run something like:

  docker build -t myplugin . && docker plugin install myplugin

but ... that's not the case (yet - maybe this will be improved in a future release).

You first have to build your plugin and provide a root filesystem for it to run containerized. So the simpler solution is to build a docker image and export it's filesystem

docker build -t authobot .

(...)

mkdir rootfs
ID=$(docker run -d authobot)
docker export $ID | tar -x -C rootfs
docker kill $ID
docker rm $ID

{
  "Description": "Authorization plugin for Docker",
  "Documentation": "https://github.com/ndeloof/authobot/blob/master/README.md",
  "Entrypoint": [
    "/bin/authobot"
  ],

  "Interface": {
    "Socket": "authobot.sock",
    "Types": [
      "docker.authz/1.0"
    ]
  }
}

docker plugin create authobot .
docker plugin enable authobot

sudo vi /var/lib/boot2docker/profile

sudo /etc/init.d/docker restart

$ docker run -it ubuntu echo 'hello world!'
hello world!

$ docker ps
Error response from daemon: plugin authobot:latest failed with error: AuthZPlugin.AuthZReq: /v1.30/containers/json is not authorized

Step 6 : What's next?

Code is currently very minimalist, there's many thing I could improve.
Generally speaking, it only partially cover my need : I will need to track the owner of each container to prevent one try to access other's containers.

Also, as an authorization plugin doesn't allow to change the API call payload, there's few things that will be harder to implement, like per user resource quota, and few other protections I'd like to implement. This plugin anyway will at least prevent the most obvious security issues.

Vous le voyez, dans cette recette, filmer le speaker c'est le dernier point, la cerise sur le gateau. Essayez donc de déjà faire un gateau sympa avant de vous embarquer dans des trucs compliqués et intrusifs.

Notez bien que je parle de captation de meetup ici, pas d'interview, vidéo d'ambiance, etc. Ca c'est un tout autre sujet :D

Je dois l'avouer, c'est souvent très chiant. Le support dans les outils de présentation de templates est d'ailleurs assez mauvais, et lorsqu'on en change toute la mise en page est à refaire. Cependant, en tant que speaker, lorsqu'on ne m'impose pas un template - je précise qu'on ne me l'a jamais "imposé", juste très fortement recommandé, ce qui n'est pas la même chose, j'aurais pu faire ma conférence sans, et ne pas pour autant être blâmé - j'ai pour habitude d'essayer a minima d'intégrer le logo de la conférence dans les slides. Ca s'appelle respecter son hôte.

Ca ne m'est jamais arrivé, j'ai parfois vu cette option dans un Call for Papers, mais généralement on me demande plutôt une vidéo d'une de mes intervention pour estimer mes qualités de speaker. J'admet que si ça m'arrivait je serais emmerdé. Il est assez courant que j'ajuste mes slides au denier moment, souvent en fonction des sessions qui ont précédées ou qui sont au programme et recouvrent mon sujet "pour en savoir plus, allez voir XX salle YY à 16h".

Sérieux, peut-on reprocher à une conférence de vouloir regrouper les slides sur leur site web ? Bien sur, l'essentiel de la conférence n'est pas dans les slides, mais il y a TOUJOURS des gens pour vous les demander. Franchement ce n'est pas pour ce que ça coute, sans parler des très nombreux speakers qui les mettent en ligne d'eux-même

Alors là mon gars, je sais pas dans quel monde tu vies, mais quand on est organisateur, on est bien obligé de faire avec ce qu'on trouve dans les rares lieux qui correspondent à l'événement qu'on prévoit. Et oui, parfois on a de vieux projecteur 4:3 qui poussent à peine en 1024x768. Mais pour quelqu'un qui nous explique que son talk ne se résume pas à ses slides, je trouve que la critique tombe bien mal.

J'admet qu'un micro qui part en vrille au bout de 10 minutes, ou pire : un micro pupitre qui t'interdit tout mouvement, c'est pénible. Seul point sur lequel je suis d'accord. Ceci dit, un bon micro serre tête sans fil ça coute un bras, aussi voir le point précédent.

Je n'ai jamais fait cette expérience, et je n'aurais pas l'idée de l'imposer à un speaker. Mais de toute évidence ça arrive. Si c'est le cas j'admet que c'est un soucis au niveau de l'organisation, à savoir que permettre au speaker de vérifier sa connectique avant son intervention est un minimum. Maintenant, encore faut-il que le speaker en question soit présent à l'avance et joignable :P

Ben tiens. Viens vendre ta camelote, je te payerais le billet d'avion avec plaisir ! Y'en a qui n'ont peur de rien. Evidemment il existe des speakers qui se font rémunérer, mais là on parle d'autre chose, non?

Dire ça, c'est clairement ne pas comprendre le modèle économique d'une conférence, qui doit jongler entre ce qu'elle arrive à soutirer des sponsors, et le prix du billet qu'elle veut afficher. Alors oui, on peut faire des conférences de riche avec des billets à 1500€ et payer l'avion à tous les speakers, ou bien ne proposer une assistance financière qu'au cas par cas et conserver un billet abordable.

Désolé, la suite présidentielle n'était pas libre. Et nous ne payons pas non plus le service de callgirls. 

Bon là, clairement on est dans la catégorie Lady Gaga, je ne sais même plus quoi dire. Le mec on lui paye l'hotel, l'avion, et il est pas content parce que c'est compliqué d'indiquer ses contraintes.

Vu le discours, il est clair que le "beneficial" dans un des deux sens il est évident. En tant qu'organisateur, je laisserais le plaisir à d'autres de gouter à l'autre direction de la relationship.

Voilà, bref, ce discours de speaker-star m'exaspère. Ce mec mériterait un bon entartrage (tarte évidemment financée par l'organisateur)