Containers Host Hardening – Durcir la configuration de son hôte docker

Bonjour à tous, j’espère que vous avez passé un bel été 2022. Aujourd’hui nous allons voir comment améliorer la sécurité d’un hôte docker pour un environnement de production.

I. Présentation de docker-bench-security

Docker Bench for Security est un script qui vérifie des dizaines de bonnes pratiques courantes concernant le déploiement de conteneurs Docker en production. Les tests sont tous automatisés et basés sur le CIS Docker Benchmark v1.4.0 .

Docker bench nécessite Docker 1.13.0 ou une version ultérieure pour fonctionner.

Je ne vais pas détailler toutes les options et les tests que docker-bench-security effectue, cela serait contre-productif. Cependant, je vous propose d’analyser une situation très courante, (exécution d’un container via l’user root) afin que docker-bench-security détecte que cela est une mauvaise pratique pour un environnement de production.

La configuration de mon lab sera la suivante :

• Hôte Docker Kali linux : 192.168.125.128/24
  • Deux containers vont me servir d’exemple
    • alpine:latest
    • ubuntu:latest

Instanciez les deux conteneurs à l’aide de la commande suivante :

docker run --rm -d -it ubuntu sh
docker run --rm -d -it alpine sh

Je vous invite dès à présent à git clone le projet suivant. Puis, exécutez ensuite le script préfixé de la commande sudo.

git clone https://github.com/docker/docker-bench-security
cd docker-bench-security
sudo sh docker-bench-security.sh

Si, je m’intéresse plus particulièrement à la section 4, je constate une alerte qui m’indique que j’ai instancié mes containers par l’intermédiaire de l’utilisateur root, ce qui n’est pas une pratique recommandée (tout dépend de ce que fait votre container et si vous êtes dans un environnement de production ou non).

Alors, vous allez me dire : Ok, mais cela n’est pas de l’hardening d’hôte, mais plutôt de container. Ce qu’il faut bien se dire ici, c’est que ce script analyse quel utilisateur a été choisit lors de l’instanciation du container avec la commande docker run (par défaut root). docker-bench-security n’inspecte pas ce qui se passe à l’intérieur du container en question 😉 mais regarde « de loin » « par la fenêtre », qui se trouve à l’intérieur du container.

Afin de corriger cela, je vais stopper le container en cours :

sudo docker stop 7e

Puis, je vais le démarrer de nouveau mais cette fois avec un autre utilisateur afin de vérifier si oui ou non docker-bench-security détecte un changement.

sudo docker start 7e
sudo docker exec -it --user nobody 7e sh 

L’image par défaut d’alpine ne contient pas d’autres utilisateurs que root et nobody. Mais, ce n’est pas le cas si vous personnalisez une image. Vous pouvez ajouter un utilisateur ou plus « standard » dans votre Dockerfile ou dans un Docker compose.

J’ouvre une autre fenêtre de terminal, puis je relance l’analyse (sudo sh docker-bench-security.sh), et bam, j’ai toujours mon container qui est détecté comme s’exécutant avec l’user root.. vous allez me dire… Bizarre. Oui c’est vrai, mais c’est logique ^^ car voilà ce qui s’est passé :

• Je redémarre un container que j’avais précédemment instancié avec l’utilisateur root, puis
• Je me connecte avec l’utilisateur nobody au shell du container via docker exec

Voilà pourquoi docker-bench-security ne détecte pas le changement. Vous devez provisionner un nouveau container avec la commande docker run en précisant cette fois-ci l’utilisateur en argument de la commande.

docker run --user nobody:nobody -it alpine 

Actuellement, j’ai donc trois containers qui sont démarrer.

Afin de vérifier si docker-bench-security détecte les changements, je relance le script.

sudo sh docker-bench-security.sh

Cette fois-ci vous pouvez constater que le dernier container que j’ai provisionné plus haut n’est pas « flagué » par le script. (pensive_swanson).

II. docker-bench-security – Options avancés

A. Sélectionner uniquement des tests / groupes de tests en particulier

Par défaut, docker-bench-security est composé de 7 sections qui comportent chacune une multitude de tests en lien avec le nom de la section. Si vous désirez uniquement exécuter les tests d’une section, vous pouvez utiliser la commande suivante (à adapter en fonction du nom des sections).

sudo sh docker-bench-security -c docker_daemon_configuration

Ci-dessous, juste les tests de la section 2 ont été lancés

De plus, si vous souhaitez exécuter juste un seul test, vous pouvez le faire de cette manière (donnez bien le bon numéro de l’identifiant du test)

Ici le test choisit est 4.1

sudo sh docker-bench-security.sh -c check_4_1

Ici le test choisit est 1.2.2

sudo sh docker-bench-security.sh -c check_1_2_2

III. Gestion des logs

Enfin par défaut docker-bench-security sauvegarde tous les tests effectués dans plusieurs formats de fichier à savoir :

• .json
• .log

Pratique pour garder une trace des tests qui ont été effectués.

J’espère une fois de plus que cet article vous aura plus !

++

Geoffrey

IV. Références

• https://www.calcomsoftware.com/docker-host-hardening-guide/
• https://github.com/docker/docker-bench-security