Salut, Habr !

Dans la réalité moderne, en raison du rôle croissant de la conteneurisation dans les processus de développement, la question de la sécurité à différents stades et pour les entités liées aux conteneurs n’est pas à négliger. Effectuer des vérifications manuelles est une tâche laborieuse, il serait donc judicieux de faire au moins les premiers pas vers l'automatisation de ce processus.

Dans cet article, je vais partager des scripts prêts à l'emploi pour implémenter plusieurs utilitaires de sécurité Docker et une instruction sur la façon de déployer un petit environnement de démonstration pour tester ce processus. Ces matériaux peuvent être utilisés pour expérimenter avec l'organisation du processus de test de la sécurité des images et des instructions Dockerfile. Évidemment, l'infrastructure de développement et de déploiement varie pour chacun, donc ci-dessous, je vais proposer quelques options possibles.

Utilitaires de vérification de sécurité

Il existe un grand nombre d'applications auxiliaires et de scripts qui effectuent des vérifications de différents aspects de l'infrastructure Docker. Une partie d'entre eux a déjà été décrite dans l'article précédent (https://habr.com/ru/company/swordfish_security/blog/518758/#docker-security), et dans ce document, je voudrais me concentrer sur trois d'entre eux qui couvrent la plupart des exigences en matière de sécurité des images Docker créées durant le développement. En plus, je vais également montrer un exemple de la façon dont ces trois utilitaires peuvent être réunis dans un seul pipeline pour réaliser des vérifications de sécurité.

Hadolint
https://github.com/hadolint/hadolint

Un utilitaire en ligne de commande assez simple qui aide, dans une première approche, à évaluer la correction et la sécurité des instructions des Dockerfiles (par exemple, utiliser uniquement des registres d'images autorisés ou utiliser sudo).

Dockle
https://github.com/goodwithtech/dockle

Un utilitaire en ligne de commande qui travaille avec une image (ou un archive tar d'une image enregistrée), qui vérifie la correction et la sécurité de l'image spécifique en elle-même, en analysant ses couches et sa configuration : quels utilisateurs ont été créés, quelles instructions sont utilisées, quels volumes sont attachés, la présence d'un mot de passe vide, etc. Actuellement, le nombre de vérifications n'est pas très élevé et repose sur quelques vérifications propres et recommandations. CIS (Center for Internet Security) Benchmark pour Docker.


Trivy
https://github.com/aquasecurity/trivy

Cet outil est conçu pour détecter des vulnérabilités de deux types : les problèmes de construction du système d'exploitation (prise en charge d'Alpine, RedHat (EL), CentOS, Debian GNU, Ubuntu) et les problèmes de dépendances (Gemfile.lock, Pipfile.lock, composer.lock, package-lock.json, yarn.lock, Cargo.lock). Trivy peut scanner à la fois une image dans le dépôt et une image locale, ainsi que procéder à un scan à partir d'un fichier .tar contenant une image Docker.

Options d'intégration des outils

Pour tester les applications décrites dans des conditions isolées, je vais fournir des instructions pour installer tous les outils dans le cadre d'un processus simplifié.

L'idée principale est de démontrer comment intégrer une vérification automatique du contenu du Dockerfile et des images Docker créées lors du développement.

La vérification elle-même se compose des étapes suivantes :

1. Vérification de la validité et de la sécurité des instructions Dockerfile à l'aide d'un linter Hadolint
2. Vérification de la validité et de la sécurité des images finales et intermédiaires à l'aide de l'outil Dockle
3. Vérification de la présence de vulnérabilités connues (CVE) dans l'image de base et dans plusieurs dépendances à l'aide de l'outil Trivy

Ensuite, dans cet article, je présenterai trois façons d'intégrer ces étapes :
La première consiste à configurer un pipeline CI/CD, en prenant GitLab comme exemple (avec une description du processus de déploiement d'une instance de test).
La seconde utilise un script shell.
La troisième consiste à construire une image Docker pour scanner d'autres images Docker.
Vous pouvez choisir l'option qui vous convient le mieux, l'adapter à votre infrastructure et l'ajuster à vos besoins.

Tous les fichiers nécessaires et des instructions supplémentaires se trouvent également dans le dépôt : https://github.com/Swordfish-Security/docker_cicd

Intégration dans GitLab CI/CD

Dans la première option, nous examinerons comment intégrer des vérifications de sécurité en prenant comme exemple le système de dépôts GitLab. Nous allons suivre les étapes et examiner comment installer un environnement de test avec GitLab à partir de zéro, définir le processus de scan et exécuter les outils pour vérifier un Dockerfile de test et une image aléatoire — l'application JuiceShop.

Installation de GitLab
1. Installer Docker :

sudo apt-get update && sudo apt-get install docker.io

2. Ajouter l'utilisateur actuel au groupe docker pour pouvoir travailler avec Docker sans sudo :

sudo addgroup  docker

3. Trouver votre adresse IP :

ip addr

4. Installer et démarrer GitLab dans un conteneur, en remplaçant l'adresse IP dans hostname par la vôtre :

docker run --detach 
--hostname 192.168.1.112 
--publish 443:443 --publish 80:80 
--name gitlab 
--restart always 
--volume /srv/gitlab/config:/etc/gitlab 
--volume /srv/gitlab/logs:/var/log/gitlab 
--volume /srv/gitlab/data:/var/opt/gitlab 
gitlab/gitlab-ce:latest

Nous attendons que GitLab exécute toutes les procédures nécessaires à l'installation (vous pouvez suivre le processus via la sortie du fichier journal : docker logs -f gitlab).

5. Ouvrez votre adresse IP locale dans un navigateur et vous verrez une page vous proposant de changer le mot de passe pour l'utilisateur root :

Définissez un nouveau mot de passe et connectez-vous à GitLab.

6. Créez un nouveau projet, par exemple cicd-test et initialisez-le avec un fichier de démarrage. README.md:

7. Nous devons maintenant installer GitLab Runner : l'agent qui exécutera toutes les opérations nécessaires à la demande.
Téléchargez la dernière version (dans ce cas - pour Linux 64 bits) :

sudo curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64

8. Rendez-le exécutable :

sudo chmod +x /usr/local/bin/gitlab-runner

9. Ajoutez un utilisateur système pour le Runner et démarrez le service :

sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash
sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
sudo gitlab-runner start

Cela devrait ressembler à quelque chose comme ceci :

local@osboxes:~$ sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
Runtime platform arch=amd64 os=linux pid=8438 revision=0e5417a3 version=12.0.1
local@osboxes:~$ sudo gitlab-runner start
Runtime platform arch=amd64 os=linux pid=8518 revision=0e5417a3 version=12.0.1

10. Maintenant, enregistrez le Runner pour qu'il puisse interagir avec notre instance GitLab.
Pour cela, ouvrez la page Settings-CI/CD (http://NOTRE_ADRESSE_IP/root/cicd-test/-/settings/ci_cd) et dans l'onglet Runners, trouvez l'URL et le jeton d'enregistrement :

11. Enregistrez le Runner en insérant l'URL et le jeton d'enregistrement :

sudo gitlab-runner register 
--non-interactive 
--url "http:///" 
--registration-token "" 
--executor "docker" 
--docker-privileged 
--docker-image alpine:latest 
--description "docker-runner" 
--tag-list "docker,privileged" 
--run-untagged="true" 
--locked="false" 
--access-level="not_protected"

En résultat, nous avons un GitLab opérationnel, dans lequel il est nécessaire d'ajouter des instructions pour le démarrage de nos utilitaires. Dans ce cas de démonstration, nous n'avons pas d'étapes pour construire l'application et sa conteneurisation, mais dans un environnement réel, elles précéderont les étapes de scan et formeront des images et des Dockerfile pour l'analyse.

Configuration du pipeline

1. Ajoutez des fichiers au dépôt mydockerfile.df (c'est un Dockerfile test que nous allons vérifier) et le fichier de configuration du processus GitLab CI/CD .gitlab-cicd.yml, qui énumère les instructions pour les scanners (remarquez le point dans le nom du fichier).

Le fichier de configuration YAML contient les instructions pour exécuter trois outils (Hadolint, Dockle et Trivy), qui analyseront le Dockerfile choisi et l'image définie dans la variable DOCKERFILE. Tous les fichiers nécessaires peuvent être récupérés depuis le dépôt : https://github.com/Swordfish-Security/docker_cicd/

Extrait de mydockerfile.df (il s'agit d'un fichier abstrait avec un ensemble d'instructions arbitraires uniquement pour démontrer le fonctionnement de l'outil). Lien direct vers le fichier : mydockerfile.df

Contenu de mydockerfile.df

FROM amd64/node:10.16.0-alpine@sha256:f59303fb3248e5d992586c76cc83e1d3700f641cbcd7c0067bc7ad5bb2e5b489 AS tsbuild
COPY package.json .
COPY yarn.lock .
RUN yarn install
COPY lib lib
COPY tsconfig.json tsconfig.json
COPY tsconfig.app.json tsconfig.app.json
RUN yarn build
FROM amd64/ubuntu:18.04@sha256:eb70667a801686f914408558660da753cde27192cd036148e58258819b927395
LABEL mainteneur="Rhys Arkins <rhys@arkins.net>"
LABEL name="renovate"
...
COPY php.ini /usr/local/etc/php/php.ini
RUN cp -a /tmp/piik/* /var/www/html/
RUN rm -rf /tmp/piwik
RUN chown -R www-data /var/www/html
ADD piwik-cli-setup /piwik-cli-setup
ADD reset.php /var/www/html/
## ENTRYPOINT ##
ADD entrypoint.sh /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]
USER root

Le fichier de configuration YAML ressemble à ceci (le fichier lui-même peut être récupéré par le lien direct ici : .gitlab-ci.yml):

Contenu de .gitlab-ci.yml

variables:
    DOCKER_HOST: "tcp://docker:2375/"
    DOCKERFILE: "mydockerfile.df" # nom du Dockerfile à analyser   
    DOCKERIMAGE: "bkimminich/juice-shop" # nom de l'image Docker à analyser
    # DOCKERIMAGE: "knqyf263/cve-2018-11235" # image Docker de test avec plusieurs CVE CRITIQUES
    SHOWSTOPPER_PRIORITY: "CRITIQUE" # quel niveau de criticité fera échouer le travail Trivy
    TRIVYCACHE: "$CI_PROJECT_DIR/.cache" # où mettre en cache la base de données des vulnérabilités Trivy pour une réutilisation plus rapide
    ARTIFACT_FOLDER: "$CI_PROJECT_DIR"
 
services:
    - docker:dind # pour pouvoir construire des images Docker à l'intérieur du Runner
 
stages:
    - scan
    - rapport
    - publication
 
HadoLint:
    # Analyse de lint de base des instructions du Dockerfile
    stage: scan
    image: docker:git
 
    after_script:
    - cat $ARTIFACT_FOLDER/hadolint_results.json
 
    script:
    - export VERSION=$(wget -q -O - https://api.github.com/repos/hadolint/hadolint/releases/latest | grep '"tag_name":' | sed -E 's/.*"v([^"]+)".*//1/')
    - wget https://github.com/hadolint/hadolint/releases/download/v${VERSION}/hadolint-Linux-x86_64 && chmod +x hadolint-Linux-x86_64
     
    # NB : hadolint sortira toujours avec un code de sortie 0
    - ./hadolint-Linux-x86_64 -f json $DOCKERFILE > $ARTIFACT_FOLDER/hadolint_results.json || exit 0
 
    artifacts:
        when: always # renvoyer les artefacts même après un échec de travail       
        paths:
        - $ARTIFACT_FOLDER/hadolint_results.json
 
Dockle:
    # Analyse des meilleures pratiques concernant l'image Docker (permissions des utilisateurs, instructions suivies lors de la construction de l'image, etc.)
    stage: scan   
    image: docker:git
 
    after_script:
    - cat $ARTIFACT_FOLDER/dockle_results.json
 
    script:
    - export VERSION=$(wget -q -O - https://api.github.com/repos/goodwithtech/dockle/releases/latest | grep '"tag_name":' | sed -E 's/.*"v([^"]+)".*//1/')
    - wget https://github.com/goodwithtech/dockle/releases/download/v${VERSION}/dockle_${VERSION}_Linux-64bit.tar.gz && tar zxf dockle_${VERSION}_Linux-64bit.tar.gz
    - ./dockle --exit-code 1 -f json --output $ARTIFACT_FOLDER/dockle_results.json $DOCKERIMAGE   
     
    artifacts:
        when: always # renvoyer les artefacts même après un échec de travail       
        paths:
        - $ARTIFACT_FOLDER/dockle_results.json
 
Trivy:
    # Analyse de l'image Docker et des dépendances de packages par rapport à plusieurs bases de données CVE
    stage: scan   
    image: docker:git
 
    script:
    # obtenir le dernier Trivy
    - apk add rpm
    - export VERSION=$(wget -q -O - https://api.github.com/repos/knqyf263/trivy/releases/latest | grep '"tag_name":' | sed -E 's/.*"v([^"]+)".*//1')
    - wget https://github.com/knqyf263/trivy/releases/download/v${VERSION}/trivy_${VERSION}_Linux-64bit.tar.gz && tar zxf trivy_${VERSION}_Linux-64bit.tar.gz
     
    # afficher toutes les vulnérabilités sans échouer la construction
    - ./trivy -d --cache-dir $TRIVYCACHE -f json -o $ARTIFACT_FOLDER/trivy_results.json --exit-code 0 $DOCKERIMAGE    
    
    # écrire les informations sur les vulnérabilités dans stdout dans un format lisible par l'homme (lire du pure json n'est pas amusant, n'est-ce pas ?). Vous pouvez supprimer cela si vous n'en avez pas besoin.
    - ./trivy -d --cache-dir $TRIVYCACHE --exit-code 0 $DOCKERIMAGE    
 
    # échouer la construction si la priorité SHOWSTOPPER est trouvée
    - ./trivy -d --cache-dir $TRIVYCACHE --exit-code 1 --severity $SHOWSTOPPER_PRIORITY --quiet $DOCKERIMAGE
         
    artifacts:
        when: always # renvoyer les artefacts même après un échec de construction
        paths:
        - $ARTIFACT_FOLDER/trivy_results.json
 
    cache:
        paths:
        - .cache
 
Report:
    # combinant les sorties des outils en un seul HTML
    stage: report
    when: always
    image: python:3.5
     
    script:
    - mkdir json
    - cp $ARTIFACT_FOLDER/*.json ./json/
    - pip install json2html
    - wget https://raw.githubusercontent.com/shad0wrunner/docker_cicd/master/convert_json_results.py
    - python ./convert_json_results.py
     
    artifacts:
        paths:
        - results.html

Si nécessaire, il est également possible de scanner et de sauvegarder des images sous forme d'archive .tar (mais il faudra modifier les paramètres d'entrée dans le fichier YAML pour les utilitaires)

NB : Trivy nécessite des rpm et git. Sinon, il renverra des erreurs lors du scan d'images basées sur RedHat et de la mise à jour de la base de données des vulnérabilités.

2. Après l'ajout des fichiers au dépôt, selon les instructions de notre fichier de configuration, GitLab commencera automatiquement le processus de build et de scan. Dans l'onglet CI/CD → Pipelines, vous pourrez voir l'avancement de l'exécution des instructions.

En conséquence, nous avons quatre tâches. Trois d'entre elles se chargent du scan lui-même et la dernière (Report) compile un rapport simple à partir de fichiers hétérogènes contenant les résultats du scan.

Par défaut, Trivy arrête son exécution si des vulnérabilités CRITIQUES sont détectées dans l'image ou les dépendances. En revanche, Hadolint renvoie toujours un code de réussite, car son exécution génère toujours des remarques, ce qui entraîne l'arrêt de la construction.

Selon les exigences spécifiques, il est possible de configurer le code de sortie pour que ces utilitaires arrêtent également le processus de build en cas de détection de problèmes d'une certaine criticité. Dans notre cas, la construction s'arrêtera uniquement si Trivy détecte une vulnérabilité d'une criticité que nous avons définie dans la variable SHOWSTOPPER dans .gitlab-ci.yml.


Le résultat de chaque utilitaire peut être consulté dans le journal de chaque tâche de scan, directement dans les fichiers json dans la section des artifacts ou dans un rapport HTML simple (nous en parlerons un peu plus bas) :


3. Pour présenter les rapports des utilitaires d'une manière légèrement plus lisible, un petit script en Python est utilisé pour convertir trois fichiers json en un seul fichier HTML avec un tableau des défauts.
Ce script est exécuté comme une tâche distincte Report, et son produit final est un fichier HTML avec le rapport. Le code source du script se trouve également dans le dépôt et peut être adapté à vos besoins, couleurs, etc.

Script Shell

La deuxième option convient aux cas où il est nécessaire de vérifier des images Docker en dehors d'un système CI/CD, ou lorsqu'il est nécessaire d'avoir toutes les instructions dans un format pouvant être exécuté directement sur l'hôte. Cette option est couverte par un script shell prêt à l'emploi, qui peut être exécuté sur une machine virtuelle (ou même physique) vierge. Le script exécute les mêmes instructions que le gitlab-runner décrit ci-dessus.

Pour que le script fonctionne correctement, Docker doit être installé sur le système et l'utilisateur actuel doit être dans le groupe docker.

Le script lui-même peut être récupéré ici : docker_sec_check.sh

Au début du fichier, les variables définissent quelle image doit être scannée et quelles défaillances de quelle criticité provoqueront la sortie de l'utilitaire Trivy avec le code d'erreur spécifié.

Au cours de l'exécution du script, tous les utilitaires seront téléchargés dans le répertoire docker_tools, les résultats de leur travail seront dans le répertoire docker_tools/json, et le HTML avec le rapport sera dans le fichier results.html.

Exemple de sortie du script

~/docker_cicd$ ./docker_sec_check.sh

[+] Réglage des variables d'environnement
[+] Installation des paquets requis
[+] Préparation des répertoires nécessaires
[+] Récupération de l'exemple Dockerfile
2020-10-20 10:40:00 (45.3 Mo/s) - ‘Dockerfile’ enregistré [8071/8071]
[+] Récupération de l'image à scanner
latest: Pulling from bkimminich/juice-shop
[+] Exécution de Hadolint
...
Dockerfile:205 DL3015 Évitez les paquets supplémentaires en spécifiant `--no-install-recommends`
Dockerfile:248 DL3002 Le dernier USER ne doit pas être root
...
[+] Exécution de Dockle
...
WARN    - DKL-DI-0006: Évitez l'étiquette latest
        * Évitez l'étiquette 'latest'
INFO    - CIS-DI-0005: Activez la confiance du contenu pour Docker
        * export DOCKER_CONTENT_TRUST=1 avant docker pull/build
...
[+] Exécution de Trivy
juice-shop/frontend/package-lock.json
=====================================
Total : 3 (UNKNOWN : 0, LOW : 1, MEDIUM : 0, HIGH : 2, CRITICAL : 0)

+---------------------+------------------+----------+---------+-------------------------+
|       LIBRARY       | VULNERABILITY ID | SEVERITY | VERSION |             TITLE       |
+---------------------+------------------+----------+---------+-------------------------+
| object-path         | CVE-2020-15256   | HAUT     | 0.11.4  | Pollution de prototype  |
|                     |                  |          |         | dans object-path        |
+---------------------+------------------+          +---------+-------------------------+
| tree-kill           | CVE-2019-15599   |          | 1.2.2   | Injection de code       |
+---------------------+------------------+----------+---------+-------------------------+
| webpack-subresource | CVE-2020-15262   | FAIBLE   | 1.4.1   | Morceaux chargés de manière non protégée |
|                     |                  |          |         |                       |
+---------------------+------------------+----------+---------+-------------------------+

juice-shop/package-lock.json
============================
Total : 20 (UNKNOWN : 0, LOW : 1, MEDIUM : 6, HIGH : 8, CRITICAL : 5)

...

juice-shop/package-lock.json
============================
Total : 5 (CRITICAL : 5)

...
[+] Suppression des restes
[+] Mise en forme de la sortie
[+] Conversion des résultats JSON
[+] Écriture des résultats HTML
[+] Sortie propre ============================================================
[+] Tout est terminé. Trouvez le rapport HTML dans results.html

Image Docker avec tous les utilitaires

En guise de troisième alternative, j'ai élaboré deux Dockerfiles simples pour créer une image avec des outils de sécurité. Un Dockerfile aidera à assembler un ensemble pour scanner l'image depuis le dépôt, le second (Dockerfile_tar) permettra de rassembler un ensemble pour scanner un fichier tar contenant l'image.

1. Prenez le Dockerfile approprié et les scripts depuis le dépôt https://github.com/Swordfish-Security/docker_cicd/tree/master/Dockerfile.
2. Lancez-le pour la construction :

docker build -t dscan:image -f docker_security.df .

3. Une fois la construction terminée, créez un conteneur à partir de l'image. Dans ce processus, transmettez la variable d'environnement DOCKERIMAGE avec le nom de l'image qui nous intéresse et montez le Dockerfile que nous voulons analyser depuis notre machine sur le fichier /Dockerfile (notez qu'un chemin absolu vers ce fichier est requis) :

docker run --rm -v $(pwd)/results:/results -v $(pwd)/docker_security.df:/Dockerfile -e DOCKERIMAGE="bkimminich/juice-shop" dscan:image

[+] Configuration des variables d'environnement
[+] Exécution de Hadolint
/Dockerfile:3 DL3006 Toujours taguer la version d'une image explicitement
[+] Exécution de Dockle
WARN    - DKL-DI-0006 : Éviter le tag latest
        * Évitez le tag 'latest'
INFO    - CIS-DI-0005 : Activer la confiance dans le contenu pour Docker
        * export DOCKER_CONTENT_TRUST=1 avant docker pull/build
INFO    - CIS-DI-0006 : Ajouter l'instruction HEALTHCHECK à l'image du conteneur
        * instruction HEALTHCHECK non trouvée
INFO    - DKL-LI-0003 : Ne mettre que les fichiers nécessaires
        * fichier inutile : juice-shop/node_modules/sqlite3/Dockerfile
        * fichier inutile : juice-shop/node_modules/sqlite3/tools/docker/architecture/linux-arm64/Dockerfile
        * fichier inutile : juice-shop/node_modules/sqlite3/tools/docker/architecture/linux-arm/Dockerfile
[+] Exécution de Trivy
...
juice-shop/package-lock.json
============================
Total : 20 (UNKNOWN : 0, LOW : 1, MEDIUM : 6, HIGH : 8, CRITICAL : 5)
...
[+] Mise en forme de la sortie
[+] Démarrage du module principal ============================================================
[+] Conversion des résultats JSON
[+] Écriture des résultats HTML
[+] Sortie propre ============================================================
[+] Tout est terminé. Trouvez le rapport HTML résultant dans results.html

Résultats

Nous n'avons examiné qu'un ensemble de base d'outils pour scanner les artefacts Docker, qui, à mon avis, couvre de manière assez efficace une bonne partie des exigences de sécurité des images. Il existe encore beaucoup d'outils payants et gratuits qui peuvent effectuer les mêmes vérifications, générer de beaux rapports ou fonctionner uniquement en mode console, couvrir des systèmes de gestion des conteneurs, etc. Un aperçu de ces outils et de leurs méthodes d'intégration pourrait apparaître plus tard.

L'un des avantages de l'ensemble d'outils décrit dans cet article est qu'ils sont tous basés sur du code source ouvert, vous permettant d'expérimenter avec eux et d'autres outils similaires pour déterminer ce qui convient le mieux à vos exigences et spécificités d'infrastructure. Bien sûr, toutes les vulnérabilités découvertes doivent être étudiées pour leur applicabilité dans des conditions particulières, mais c'est un sujet pour un futur grand article.

J'espère que ce guide, ces scripts et utilitaires vous seront utiles et constitueront un point de départ pour créer une infrastructure plus sûre dans le domaine de la conteneurisation.

Source : habr.com