virli/tutorial/docker-advanced/security.md

## Limiter les ressources

Lorsque l'on gère un environnement de production, on souhaite bien
évidemment éviter tout déni de service autant que possible. Ou
parfois, contenir un programme métier avec une fuite mémoire, dans
certaines limites : il vaut parfois mieux le tuer et le relancer
automatiquement, plutôt que d'attendre que potentiellement un autre
processus se fasse tuer à sa place.

Pour cela, Docker expose tout un arsenal, reposant sur les cgroups du
noyau Linux, que l'on verra plus en détail dans un prochain cours.

### Mémoire

Comme on peut s'y attendre, il est possible de limiter la mémoire que
peut occuper un conteneur avec l'option `-m`/`--memory`.


### CPU

En ce qui concerne la limitation d'utilisation du CPU, ce n'est pas
aussi simple. En effet, on ne peut pas définir le nombre
d'instructions par seconde qu'un conteneur est autorisé à consommer.

On ne peut définir qu'un taux d'utilisation relatif par rapport à
l'ensemble du système (ou du groupe de processus auquel il
appartient).  Ce taux est appliqué par l'ordonnanceur, lorsqu'il
détermine la prochaine tâche qui sera exécutée.

Ainsi, lorsque la machine n'est pas chargée, que le processeur n'a pas
constamment du travail à effectuer, l'ordonnanceur ne va pas empêcher
une tâche très consommatrice en puissance de calcul de s'exécuter.

Par contre, sous une forte charge, si l'on défini que notre conteneur
exécutant un cpuburn ne peut pas utiliser plus de 50% des ressources
de la machine, ce pourcentage ne pourra effectivement pas être
dépassé, l'ordonnanceur privilégiant alors les autres processus du
système.

Par défaut, le taux maximal (1024 = 100%) d'utilisation CPU est donné
aux nouveaux conteneurs, on peut le réduire en utilisant l'option
`-c`/`--cpu-shares` : 512 = 50%, par exemple.


## Sécuriser l'exécution

En plus des dénis de service, on peut également vouloir se protéger
contre des attaques provenant des conteneurs eux-mêmes. On n'est pas à
l'abri d'une vulnérabilité dans un des services exécuté dans un
conteneur. Plusieurs mécanismes sont mis en place pour accroître la
difficulté du rebond.

### Capabilities

Un certain nombre de capabilities Linux sont retirées par Docker au
moment de l'exécution du conteneur, on peut utiliser les options
`--cap-add` et `--cap-drop` pour respectivement ajouter et retirer une
capabilities.

Notez que l'option `--privileged` ne retire aucune capabilities à
l'exécution.

Nous verrons dans un prochain cours exactement ce que permettent ces
capabilities.


### seccomp

Si les capabilities sont un regroupement grossiers de fonctionnalités
du noyau, seccomp est un filtre que l'on peut définir pour chaque
appel système. Liste blanche, liste noire, tout est possible.

Docker filtre notamment tous les appels systèmes qui pourraient
débordés à l'extérieur du conteneur : il n'est par exemple pas
possible de changer l'heure dans un conteneur, car il n'y a
aujourd'hui aucun mécanisme pour isoler les visions des dates d'un
conteneur à l'autre.

Voici par exemple un fichier de profil seccomp, interdisant
l'utilisation de l'appel système `nanosleep(2)` (utilisé notamment par
`sleep(1)`) :

<div lang="en-US">
```js
{
	"defaultAction": "SCMP_ACT_ALLOW",
	"syscalls": [
        {
        	"names": [
    	    	"nanosleep"
        	],
    	    "action": "SCMP_ACT_ERRNO",
        	"args": [],
        	"comment": "",
        	"includes": {},
        	"excludes": {}
        }
	]
}
```
</div>

On peut ensuite l'appliquer à un conteneur Docker :

<div lang="en-US">
```
42sh$ docker container run -it --security-opt seccomp=nanosleep.json ubuntu /bin/bash
(cntnr)$ sleep 42
sleep: cannot read realtime clock: Operation not permitted
```
</div>