list of security tools around containers

src: Panorama des outils de sécurité autour des conteneurs - OCTO Talks ! - 2022-03-12

Abstract

There are 2 ways to minimize the Docker image security:

• review the content of the Dockerfile using a static analysis: SAST (Static Application Security Testing)
• analyze the Docker image after it’s built: DAST (Dynamic Application Security Testing)

Some tools that cover the above checks:

• hadolint: Dockerfile linter
  • pros
    • can be used in an IDE
    • best practices besides the Docker image security (e.g. image size)
    • fast
  • cons
    • can only be used on images that are built with a Dockerfile
    • cannot detect security issue from images used in the “FROM” instruction
• Dockle: container image linter
  • pros
    • can detect security issue from images used in the “FROM” instruction
    • best practices Docker + Linux
    • can add custom rules in a .dockleignore at root project
  • cons
    • need to access to the Docker socket ⇒ hard to use in a CI
    • false positive on secrets detection
• Trivy: find vulnerabilities, misconfigurations, secrets, SBOM in containers, Kubernetes, code repositories, clouds and more
  • pros
    • easy CI integration
    • can add a .trivyignore to avoid failed pipeline where there are still no fix
    • clear and complete documentation
  • cons
    • only analyze vulnerabilities ⇒ need to use other tools for other things to check
• Grype: vulnerability scanner for container images and filesystems

The author recommends the following:

• Hadolint for local development and for the CI
• Dockle for checking best practices for post-builds
• trivy to analyze dependencies after building the images

Les conteneurs sont devenus la nouvelle norme quant au packaging d’application logicielle. Il existe deux façons complémentaires de minimiser les risques de sécurité d’une image :

• par la revue du Dockerfile qui définit cette image, afin de vérifier que l’on n’introduit pas de faille de sécurité lors de la conception de l’image. Cela se traduit généralement par une analyse syntaxique qui va permettre de vérifier que la définition de l’image respecte certains principes (l’image ne tourne pas en user root par exemple). Dans la littérature, une telle approche est appelée SAST (Static Application Security Testing).
• par l’analyse de l’image Docker une fois qu’elle est buildée. Cette approche s’apparente au DAST (Dynamic Application Security Testing). Cela va permettre une analyse complète de l’image produite, y compris toutes les dépendances qui sont tirées lors du build de l’image. Si l’on suit le principe Build Once, Run Everywhere cher à Docker, on analyse donc l’artefact qui va être déployé sur tous nos environnements.

Cet article propose un panorama des outils que nous utilisons pour respecter les bonnes pratiques lorsque nous construisons des images Docker.

Hadolint est un linter dédié aux images Docker. Il se présente sous la forme d’un binaire, qui va analyser le Dockerfile en le traitant sous forme d’arbre de syntaxe abstraite. Cela permet à Hadolint de vérifier programmatiquement que votre Dockerfile respecte bien les dizaines de règles qui sont nativement implémentées dans l’outil. Cette vérification a lieu avant le build de l’image, sur le code.

Comme les linters pour les langages de programmation, on peut automatiser l’utilisation d’Hadolint en l’incluant directement dans notre IDE. Cela permet de détecter d’éventuelles failles et d’identifier des optimisations dès la rédaction ! Comme pour un linter de code classique, celui-ci s’intègre également très bien dans un pipeline CI pour valider que le Dockerfile est bien conforme à vos exigences…

Hadolint n’est pas seulement axé sur la sécurité, il permet aussi de s’assurer que l’on a bien produit une image Docker minimale (pas de “cache apk” qui traîne par exemple).

Image issue de la documentation officielle illustrant l’intégration d’Hadolint à VS Code

On aime :

• La possibilité d’intégrer Hadolint à notre IDE pour un feedback très rapide
• Les bonnes pratiques au-delà de la sécurité (taille des images, etc)
• La rapidité d’exécution

Limites de l’outil :

• Limites intrinsèques à l’analyse statique (pas d’analyses de l’image “FROM”)
• Ne s’applique pas aux images créées sans Dockerfile (ce genre d’image par exemple)

Dockle est un outil permettant à la fois de vérifier l’application des bonnes pratiques définies par Docker Inc. ainsi que de faire un audit sécurité d’une image. Se basant sur l’image buildée et non sur le simple Dockerfile, l’outil présente l’avantage de détecter des transgressions de manière plus poussée qu’au travers d’un simple lint du Dockerfile (comme Hadolint).

Exemple des informations remontées par Dockle

On aime :

• Permet de détecter des problèmes issus des images utilisées dans les instructions FROM
• Outil très complet (bonnes pratiques Docker + bonnes pratiques Linux + benchmarks Docker du CIS)
• Utilisable via une image Docker
• La possibilité d’ignorer les règles qui ne sont pas en accord avec nos standards d’équipe ou qui n’ont pas de sens dans un contexte spécifique (ex: HEALTHCHECK dans un job) via un fichier “.dockleignore”

Limites de l’outil :

• Nécessite d’accéder à la socket Docker donc plus difficile à intégrer à une CI
• Les faux positifs sur la détection de secrets

Trivy est un outil permettant de faire une analyse des vulnérabilités sur les images une fois qu’elles sont buildées. Il se présente sous la forme d’un binaire qui va scanner notre image pour identifier les vulnérabilités liées aux packages installés sur les images (OS, bibliothèques, etc…). Lors de la première exécution, il va charger sa base de vulnérabilités (ce qui peut prendre quelques secondes, rallongeant ainsi le premier scan effectué). Cette base sera ensuite mise à jour de manière différentielle, raccourcissant d’autant les scans suivants.

Les informations remontées par Trivy sont claires

On aime :

• Intégration facile dans une CI
• Le fichier “.trivyignore” et l’option –ignore-unfixed qui permettent d’éviter une CI rouge pour des vulnérabilités qui n’ont pas encore de correction disponible et/ou que l’on est prêt à accepter (temporairement)
• La documentation claire et complète

Limites de l’outil :

• Ne fait “que” de l’analyse de vulnérabilités et nécessite donc d’être couplé à un autre outil pour vérifier le respect des bonnes pratiques

Plus de détails sur cet outil sont disponibles sur notre article de blog dédié.

Anchore est un outil permettant de faire une analyse des vulnérabilités sur les images Docker.  A la manière de SonarQube, il est composé d’un serveur qui va scanner sur commande d’une CLI des images présentes dans une registry. Contrairement à Dockle par exemple, celui-ci permet de détecter exclusivement les problèmes liés aux packages installés sur les images (OS, bibliothèques, etc…) et non pas les problèmes liés au fonctionnement de l’image (tourne en root etc…).

Format de sortie de la CLI de Anchore une fois l’image analysée

On aime :

• Base de données d’erreurs qui se met à jour toute seule
• Déclenchement à distance via la CLI (à la manière d’un Sonar)
• L’architecture de la solution qui permet un traitement parallélisé
• Ne nécessite pas de tirer l’image depuis une registry sur l’hôte qui demande l’analyse

Limites de l’outil :

• La lecture des erreurs (le format de sortie n’est pas explicite)
• Ne fait “que” de l’analyse de vulnérabilités, nécessite donc d’être couplé à un autre outil pour une sécurisation maximale de vos images Docker
• Architecture logicielle complexe et mal documentée
• Difficilement exécutable en local mais peut être compensée en utilisant Grype

Conclusion

Comme vous pouvez le constater, l’écosystème autour des images Docker est plutôt fourni… Et notre article n’est pas exhaustif. N’hésitez donc pas à abuser de ces contrôles de sécurité  pour vos images Docker !

Même s’il n’existe aucune solution qui corresponde à tous les contextes, nous recommandons la solution suivante, adaptée selon nous à une majorité de projets :

• Hadolint utilisé en local directement dans l’IDE et intégré au pipeline de CI/CD avec les linters de code applicatif (pour un feedback avant la phase de build)
• Dockle pour la vérification des bonnes pratiques en post-build
• Trivy pour l’analyse des dépendances régulière après le build des images

Avec ces 3 outils, vos images seront à l’état de l’art !

Enfin, même si l’outil ne concerne pas directement la sécurité des images Docker, on ne pouvait pas faire d’article concernant l’outillage autour des images Docker sans mentionner l’excellent Dive. Il s’agit d’un outil en ligne de commande pour explorer les images Docker, le contenu des “layers” et découvrir les moyens de réduire la taille des images. Il est idéal pour l’analyse fine et l’investigation en cas de problème !