2021-09-19 22:19:49 +00:00
|
|
|
|
\newpage
|
|
|
|
|
|
2021-09-21 09:44:12 +00:00
|
|
|
|
Contenir les applications pour éviter les fuites
|
|
|
|
|
================================================
|
2018-10-17 18:42:13 +00:00
|
|
|
|
|
2018-10-19 23:51:25 +00:00
|
|
|
|
Lorsque l'on gère un environnement de production, on souhaite bien
|
2021-09-21 09:44:12 +00:00
|
|
|
|
évidemment éviter tout déni de service. Ou parfois, contenir un
|
2022-02-24 19:43:43 +00:00
|
|
|
|
programme métier avec une fuite mémoire, dans certaines limites : il
|
2021-09-21 09:44:12 +00:00
|
|
|
|
vaut parfois mieux le tuer et le relancer automatiquement, plutôt que
|
|
|
|
|
d'attendre que potentiellement un autre processus se fasse tuer à sa
|
|
|
|
|
place.
|
2018-10-17 18:42:13 +00:00
|
|
|
|
|
2018-10-19 23:51:25 +00:00
|
|
|
|
Pour cela, Docker expose tout un arsenal, reposant sur les cgroups du
|
2022-06-26 19:08:01 +00:00
|
|
|
|
noyau Linux, que l'on verra plus en détail par la suite.
|
2018-10-17 18:42:13 +00:00
|
|
|
|
|
2021-09-21 09:44:12 +00:00
|
|
|
|
|
2022-02-26 10:03:32 +00:00
|
|
|
|
## Limiter l'utilisation des ressources
|
2021-09-21 09:44:12 +00:00
|
|
|
|
|
2018-10-17 18:42:13 +00:00
|
|
|
|
### Mémoire
|
|
|
|
|
|
2018-10-19 23:51:25 +00:00
|
|
|
|
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.
|
|
|
|
|
|
2021-09-19 22:19:49 +00:00
|
|
|
|
Par contre, sous une forte charge, si l'on définit 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.
|
2018-10-19 23:51:25 +00:00
|
|
|
|
|
|
|
|
|
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
|
2022-02-24 19:43:43 +00:00
|
|
|
|
`-c`/`--cpu-shares` : 512 = 50%, par exemple.
|
2018-10-17 18:42:13 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Sécuriser l'exécution
|
|
|
|
|
|
2018-10-19 23:51:25 +00:00
|
|
|
|
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 à
|
2021-09-19 22:19:49 +00:00
|
|
|
|
l'abri d'une vulnérabilité dans un des services exécutés dans un
|
2018-10-19 23:51:25 +00:00
|
|
|
|
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.
|
|
|
|
|
|
2022-06-26 19:08:01 +00:00
|
|
|
|
Nous verrons plus tard de quoi sont capables ces *capabilities*
|
|
|
|
|
exactement.
|
2018-10-19 23:51:25 +00:00
|
|
|
|
|
2018-10-17 18:42:13 +00:00
|
|
|
|
|
|
|
|
|
### seccomp
|
|
|
|
|
|
2021-09-19 22:19:49 +00:00
|
|
|
|
Si les capabilities sont un regroupement grossier de fonctionnalités
|
2018-10-19 23:51:25 +00:00
|
|
|
|
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
|
2022-02-24 19:43:43 +00:00
|
|
|
|
déborder à l'extérieur du conteneur : il n'est par exemple pas
|
2018-10-19 23:51:25 +00:00
|
|
|
|
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
|
2022-02-24 19:43:43 +00:00
|
|
|
|
`sleep(1)`) :
|
2018-10-19 23:51:25 +00:00
|
|
|
|
|
|
|
|
|
<div lang="en-US">
|
|
|
|
|
```js
|
|
|
|
|
{
|
|
|
|
|
"defaultAction": "SCMP_ACT_ALLOW",
|
|
|
|
|
"syscalls": [
|
|
|
|
|
{
|
|
|
|
|
"names": [
|
|
|
|
|
"nanosleep"
|
|
|
|
|
],
|
|
|
|
|
"action": "SCMP_ACT_ERRNO",
|
|
|
|
|
"args": [],
|
|
|
|
|
"comment": "",
|
|
|
|
|
"includes": {},
|
|
|
|
|
"excludes": {}
|
|
|
|
|
}
|
|
|
|
|
]
|
|
|
|
|
}
|
|
|
|
|
```
|
|
|
|
|
</div>
|
|
|
|
|
|
2022-02-24 19:43:43 +00:00
|
|
|
|
On peut ensuite l'appliquer à un conteneur Docker :
|
2018-10-19 23:51:25 +00:00
|
|
|
|
|
|
|
|
|
<div lang="en-US">
|
|
|
|
|
```
|
2022-02-24 19:43:43 +00:00
|
|
|
|
42sh$ docker run -it --security-opt seccomp=nanosleep.json ubuntu /bin/bash
|
2018-11-16 01:38:41 +00:00
|
|
|
|
(cntnr)$ sleep 42
|
|
|
|
|
sleep: cannot read realtime clock: Operation not permitted
|
2018-10-19 23:51:25 +00:00
|
|
|
|
```
|
|
|
|
|
</div>
|