Comment automatiser les audits de sécurité Docker avec Docker Bench for Security –

Docker est pratique, mais cela peut aussi constituer un risque pour la sécurité. Il est important de protéger Docker Engine contre d’éventuelles menaces, en particulier si vous exécutez un hôte Docker en production.

Docker Bench for Security est un script automatisé qui peut vous aider à trouver des problèmes avec votre configuration. Le script Bench scanne votre hôte pour trouver des faiblesses dans la configuration de votre moteur Docker. Il est fourni par Docker lui-même en tant qu’outil d’audit de sécurité open source.

Exécution du script

Le moyen le plus simple d’utiliser Docker Bench est de télécharger le script et de l’exécuter directement. Vous pouvez l’inspecter sur GitHub si vous êtes préoccupé par son contenu.
Utilisez Git pour cloner le référentiel Bench. Exécutez le script à l’aide de votre shell. Docker Bench doit être exécuté avec sudo, car il inclut des vérifications qui nécessitent un accès root.

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

Vous verrez les résultats de l’audit affichés dans votre terminal. La numérisation prendra plusieurs secondes. Cela peut prendre une minute ou plus si vous avez beaucoup de conteneurs en cours d’exécution.

Comprendre le rapport

Code couleur du rapport pour vous permettre d’identifier rapidement les problèmes. Bleu INFO les lignes enregistrent l’entrée dans différentes sections de numérisation. Un vert PASS indique que votre système a satisfait au contrôle. rouge WARN les lignes indiquent une vulnérabilité potentielle.

Docker Bench exécute plus de 200 contrôles individuels au total. La liste exhaustive est disponible dans le référentiel GitHub du projet. Voici comment les tests sont classés.

Configuration de l’hôte

Ce groupe de tests se concentre sur les faiblesses de l’audit de sécurité de votre hôte. Des vérifications sont effectuées pour un audit approprié des répertoires Docker, l’utilisation d’une partition dédiée pour les conteneurs et l’installation d’une version mise à jour de Docker.

Configuration du démon

Les tests orientés démon vérifient que le socket du Docker n’est pas exposé sur une connexion non sécurisée. Trafic réseau entre les conteneurs par défaut bridge le réseau doit être restreint et les registres non sécurisés supprimés.

Cette section recherche également les octrois de privilèges inappropriés aux conteneurs. Les conteneurs ne devraient pas pouvoir acquérir de nouveaux privilèges. Cela pourrait permettre à un attaquant de devenir trop grand pour le conteneur.

La section suivante, les fichiers de configuration du démon Docker, a un objectif similaire. Il garantit que le répertoire d’installation de Docker et le socket Unix ont les autorisations et la propriété appropriées. Le système de fichiers de Docker doit appartenir à root:root avec des autorisations restrictives de 644.

Images de conteneurs

Docker Bench effectue une vérification de base des fichiers Docker pour vos images connues. Il recherchera des utilisateurs de conteneurs dédiés, la présence de HEALTHCHECK instructions et l’utilisation de Content Trust pour vérifier l’intégrité des données.

Cette section de test émettra également des avertissements qui vous rappelleront les étapes de base du renforcement de l’image. Utilisez des images de base fiables, appliquez de nouveaux correctifs de sécurité et évitez l’installation de packages inutiles. Ces mesures aident à éliminer les vulnérabilités dans conteneurs.

Runtime du conteneur

Les tests Container Runtime inspectent vos conteneurs en cours d’exécution. Cette section contient plus de 30 tests, allant de la disponibilité de SELinux et AppArmor à l’utilisation de montages de système de fichiers et d’options de mise en réseau appropriés.

Vous déposerez des points si vous utilisez des conteneurs privilégiés ou si vous montez le socket Docker dans un conteneur. Les conteneurs ne doivent pas pouvoir obtenir de privilèges supplémentaires ou interférer avec le système hôte.

Bench recherche également les serveurs SSH en cours d’exécution à l’intérieur conteneurs. Ceci est déconseillé, car l’accès direct aux conteneurs doit être évité. Il est préférable d’utiliser docker exec de l’hôte pour interagir avec les conteneurs.

Des tests supplémentaires examinent l’utilisation des limites du processeur et de la mémoire. Un conteneur illimité peut consommer des ressources excessives et éventuellement provoquer une insuffisance de mémoire sur l’hôte. Les vérifications de mise en réseau signalent les ports inutilisés ainsi que les demandes de mappage de ports privilégiés dans des conteneurs.

Essaim de dockers

Docker Bench comprend une section supplémentaire pour les utilisateurs de Docker Swarm. Il se concentre sur le signalement des secrets et des certificats non sécurisés qui ne sont pas pivotés correctement. Il nécessite également une configuration réseau correcte, y compris l’utilisation de réseaux de superposition cryptés.

La section Swarm émettra un avertissement si le mode Swarm est activé mais pas réellement utilisé. Si vous ne prévoyez pas d’utiliser Swarm, désactivez-le en exécutant docker swarm leave --force.

Résoudre les problèmes courants

La plupart des hôtes Docker présenteront plusieurs avertissements si vous n’avez pas pris de mesures actives pour les renforcer. Voici quelques mesures que vous pouvez prendre pour traiter certains des rapports Docker Bench les plus courants.

Activation de l’audit pour les fichiers Docker

Docker conseille l’utilisation de l’audit au niveau du système sur les principaux répertoires Docker. L’audit enregistre toutes les opérations qui affectent les fichiers et répertoires surveillés. Cela vous permet de suivre les changements potentiellement destructeurs.

Assurez-vous que vous avez auditd installée. Éditer /etc/audit/audit.rules et ajoutez les lignes suivantes au bas du fichier:

-w /etc/default/docker -p wa
-w /etc/docker -p wa
-w /etc/docker/daemon.json -p wa
-w /lib/systemd/system/docker.service -p wa
-w /lib/systemd/system/docker.socket -p wa
-w /usr/bin/docker -p wa
-w /usr/bin/docker-containerd -p wa
-w /usr/bin/docker-runc -p wa
-w /var/lib/docker -p wa

le -p wa instruction signifie que auditd enregistrera les écritures et les changements d’attributs qui affectent les fichiers. Si votre sortie Docker Bench suggère que vous utilisiez l’audit pour des répertoires supplémentaires, ajoutez-les également à la liste. Les répertoires de Docker peuvent changer avec le temps.

Vous devrez redémarrer auditd pour appliquer vos modifications:

sudo systemctl restart auditd

Renforcer le démon

Docker Bench trouvera généralement des problèmes avec la configuration de votre démon. Ajout de ce qui suit à /etc/docker/daemon.json mettra fin à plusieurs avertissements de démon.

{
    "icc": false,
    "live-restore": true,
    "no-new-privileges": true,
    "userland-proxy": false,
    "userns-remap": "default"
}

• icc: Cela empêche les conteneurs de communiquer entre eux via la valeur par défaut bridge réseau. Les conteneurs n’atteindront les uns les autres que s’ils sont explicitement liés entre eux à l’aide d’un --link.
• restauration en direct: Cette définition permet aux conteneurs de continuer à fonctionner même si le démon s’arrête. Ceci est conseillé dans les environnements de production où vous souhaitez minimiser les temps d’arrêt.
• aucun-nouveau-privilèges: Cela empêche les conteneurs d’élever leurs privilèges à l’aide de commandes telles que setuid et setgid.
• userland-proxy: Désactiver cela signifie que iptables est utilisé pour acheminer le trafic du port hôte vers des conteneurs. Sans cela, le processus de proxy userland de Docker est utilisé, ce qui augmente la surface d’attaque de votre démon.
• userns-remap: Cela permet l’utilisation d’espaces de noms utilisateur, donc root dans un conteneur correspond à un utilisateur hôte moins privilégié. Cela réduit le risque qu’un conteneur compromis puisse s’exécuter root commandes sur votre hôte. Utilisant default demandera à Docker de créer un compte utilisateur dédié à cet effet.

Personnalisation de la sortie du rapport

Docker Bench prend en charge plusieurs indicateurs que vous pouvez utiliser pour ajuster sa sortie:

• -b: Désactivez les couleurs. Utile si vous exécutez le script dans un environnement CI qui ne prend pas en charge la sortie ANSI complète.
• -p: N’incluez pas les mesures correctives suggérées. Utile lorsque vous souhaitez vous concentrer sur les avertissements et réduire le bruit dans la sortie.
• -l report.txt: Ecrire la sortie dans report.txt au lieu du terminal.
• -c check_5.1, check_5.2: Exécutez les vérifications 5.1 et 5.2 uniquement. La liste des tests est disponible sur GitHub.
• -e check_5.1, check_5.2: Exclure les contrôles 5.1 et 5.2.

Vous pouvez combiner des indicateurs pour produire le rapport dont vous avez besoin. Si toute une section de vérifications ne s’applique pas à vous, envisagez de créer un alias de shell afin de pouvoir exécuter rapidement Docker Bench avec une séquence d’indicateurs appliqués.

Conclusion

L’utilisation du script Docker Bench for Security vous aide à trouver et à résoudre les faiblesses de la sécurité de votre hôte Docker. Répondre aux avertissements qu’il émet aidera à renforcer votre hôte et à améliorer votre posture de sécurité.

N’oubliez pas que Docker Bench n’est pas un test exhaustif. Il y a d’autres aspects du maintien de la sécurité de Docker qui ne doivent pas non plus être négligés.

Un conteneur compromis peut permettre aux attaquants de s’implanter dans vos systèmes, même si vous disposez d’une forte sécurité au niveau de l’hôte. Vous pouvez réduire ce risque en utilisant Docker Bench, ainsi que des scanners de vulnérabilité de conteneurs actifs tels que Trivy et Clair. Ceux-ci vous aideront à identifier les problèmes dans vos conteneurs, tels que les dépendances obsolètes qui pourraient être exploitées.

Bien qu’une bonne sécurité soit toujours la cible, vous devez également noter que Docker Bench est destiné aux charges de travail de production. Toutes les vérifications ne concernent pas l’installation Docker locale d’un développeur. Exécutez le script, lisez les avertissements et évaluez ceux qui s’appliquent à votre environnement.