Codefresh + Snyk = livrer rapidement et en toute sécurité

Le développement logiciel moderne, c’est écrire du code. Pas construire, pas livrer, mais développer : on code, on fusionne, on compile, on livre. Il est important de tester des deux côtés de la frontière du dépôt, entre le code et la partie automatisée. L’objectif est de tester avant la fusion, afin que les modifications passent sans encombre dans le pipeline.

Les pipelines ne sont pas là pour permettre aux développeurs de tester leurs modifications pour la première fois. Ils servent à bloquer la livraison d’une nouvelle version si notre code ne répond pas aux critères requis. C’est comme une dernière liste de vérification pendant que la fusée est encore sur la rampe de lancement. Dans l’idéal, il est même déjà un peu trop tard si nous devons corriger des problèmes pendant l’exécution d’un pipeline. Mieux vaut le faire pendant le développement et/ou la fusion. Cependant, le monde n’étant pas toujours idéal, nous devrions tout de même nous efforcer, en règle générale, de corriger les problèmes pendant la phase de développement.

Pour y parvenir, testez plus tôt afin d’obtenir des retours le plus en amont possible, par exemple sur votre machine ou dans votre dépôt de code. Bien sûr, vous devrez tout de même commencer par créer ce pipeline et y intégrer les tests nécessaires. C’est là que Codefresh intervient. La plateforme vous permet de créer des pipelines automatisés pour livrer vos applications sous forme de conteneurs et de déploiements Kubernetes.

Ces tests DOIVENT inclure la sécurité. C’est indispensable. Si vous n’en êtes pas convaincu, arrêtez la lecture et allez en parler à votre équipe, à un collègue, à vos pairs ou à un groupe de discussion, voire à nous. Nous vous expliquerons pourquoi c’est important… C’est là que Snyk intervient.

Nous allons consacrer 5 à 10 minutes à créer ce pipeline dans Codefresh et à y intégrer des tests de sécurité avec Snyk. Les tests seront rapides et efficaces : nous pourrons ainsi reprendre le codage et, à terme, livrer des fonctionnalités. Codefresh et Snyk proposent tous deux des offres gratuites, vous pouvez donc suivre les étapes sans frais. J’ai également animé un webinaire avec l’équipe de Codefresh. Si vous préférez regarder la vidéo, vous pouvez la retrouver ici.

Nous allons créer une application Node d’exemple et la livrer dans un conteneur Docker que nous publierons sur Docker Hub. Un autre pipeline se déclenchera ensuite pour déployer le résultat sous forme d’application Kubernetes. Codefresh détectera les modifications fusionnées dans notre dépôt, créera les images Docker, puis lancera les tests Snyk pour déterminer si le résultat peut être livré en toute sécurité.

Commençons par un bref rappel sur les applications et les conteneurs. Le schéma ci-dessous illustre l’architecture type d’une application exécutée sur une infrastructure de conteneurs.

Le pipeline récupère le code source de mon application dans mon dépôt GitHub, le transforme en conteneur Docker, puis vérifie la sécurité des dépendances de l’application et du système d’exploitation avant de publier le conteneur sur Docker Hub. Si aucune vulnérabilité n’est détectée, le pipeline se poursuit sans problème.

Créons maintenant ce pipeline pour de vrai !

1. Créez un compte Codefresh et un compte Snyk.io.

2. Ajoutez un dépôt dans Codefresh.

Pour cette démonstration, nous allons utiliser le dépôt https://github.com/snyk-playground/codefresh-pipeline-snyk-app-docker-scan.

3. Sélectionnez ensuite Start from template comme méthode de compilation.

Nous utilisons ici une application NodeJS. Sélectionnons-la, puis cliquons sur Suivant.

Pour l’instant, nous allons utiliser le modèle standard. N’hésitez pas à l’adapter à vos besoins.

Très bien, notre nouveau dépôt est ajouté. Passons maintenant à la définition du pipeline.

4. Créez le pipeline du dépôt en cliquant sur Create pipeline.

Commençons par définir quelques variables d’environnement requises. Veillons à chiffrer tous les secrets. Ajoutez une variable nommée « SNYK_TOKEN ».

Vous trouverez sa valeur sur https://app.snyk.io/account.

Pendant que vous y êtes, ajoutez une autre variable nommée SNYK_ORG, dont la valeur correspond à la dernière partie de votre URL https://app.snyk.io/org/. Dans mon cas, il s’agit de aarlaud-snyk-demo

Voilà pour Snyk.

Nous avons maintenant besoin de quelques variables d’environnement supplémentaires pour récupérer l’image depuis le registre Codefresh et publier l’image finale sur Docker Hub.

Pour que Codefresh puisse accéder à notre registre d’images privé, ajoutez les variables suivantes (consultez https://codefresh.io/docs/docs/docker-registries/codefresh-registry/#generate-cfcr-login-token pour plus de détails) :

• CF_USER_NAME - mon nom d’utilisateur Codefresh (par exemple, aarlaud dans mon cas)

• CFCR_ACCOUNT - dans mon cas, il s’agit du même nom que mon nom d’utilisateur : aarlaud

• CFCR_LOGIN_TOKEN - générez un jeton sur https://g.codefresh.io/user/settings et chiffrez-le !

Pour l’intégration Docker Hub, nous allons enregistrer le nom de l’image que nous voulons publier sur Docker Hub dans la variable suivante :

IMAGE_NAME - par exemple, dans mon cas : aarlaudsnyk/trainingapp

Votre ensemble de variables devrait ressembler à ceci :

Enfin, nous devons configurer Docker dans la section Integrations de Codefresh :

Vous devez disposer d’un compte Docker Hub (https://hub.docker.com/). Créez-en un si ce n’est pas déjà fait, puis configurez l’intégration du registre Docker :

Très bien, nous sommes prêts à continuer ! Si vous consultez vos déclencheurs, vous verrez que chaque commit lancera une compilation. Comme nous avons créé ce pipeline à partir de la branche master, seuls les commits sur master déclencheront la compilation. C’est suffisant pour le moment, et il est facile de modifier ou de dupliquer le pipeline pour d’autres branches et environnements.

En examinant le workflow, nous reconnaissons le modèle Docker vu précédemment. À terme, il serait peut-être préférable de le déplacer dans un Dockerfile.

Essayons maintenant de lancer une compilation pour vérifier que tout fonctionne comme prévu avant d’aller plus loin.

Vous verrez la compilation démarrer :

Et voilà, mon application est compilée.

Codefresh place automatiquement cette image dans votre registre Docker privé associé à votre compte Codefresh. Dans la section Images, je vois l’image Docker que je viens de créer :

Avant de publier simplement cette image sur Docker Hub, je veux également m’assurer qu’elle ne contient aucune vulnérabilité de sécurité.

5. Revenons au pipeline et ajoutons une commande snyk test pour vérifier si les dépendances présentent des vulnérabilités de sécurité.

Nous allons d’abord installer Snyk, puis l’exécuter avec des commandes très simples, configurées pour faire échouer le pipeline en cas de problème de gravité élevée. Pour l’instant, je ne veux pas bloquer la compilation pour des problèmes de gravité faible ou moyenne, le temps de mieux maîtriser mon workflow.

> npm install -g snyk
> snyk test --severity-threshold=high

Cliquez sur Enregistrer, puis relancez la compilation. Vous verrez une étape d’extraction dans le pipeline, intitulée Running Unit Tests. Elle échouera probablement en raison de certains problèmes. Nous les corrigerons plus tard. Analysons maintenant l’image Docker elle-même pour détecter les problèmes liés au système d’exploitation de mon application.

Lorsque Codefresh compile l’application, il publie l’image dans notre registre privé, puis la récupère pour exécuter les tests unitaires. Nous allons répéter cette opération pour lancer un deuxième test Snyk, cette fois sur l’image Docker.

Pour ce faire, nous utiliserons une composition Codefresh. Consultez la documentation pour plus de détails. Nous allons toutefois passer en mode YAML pour disposer de davantage de possibilités.

En mode YAML, commençons par ajouter ces trois lignes juste après « version: ‘1.0’ » : stages:

-scan
-promote

Cette modification est purement cosmétique : elle crée une section en forme de compartiment dans l’interface. Modifions légèrement la section RunningUnitTests existante pour utiliser la section SnykAppScan. Outre le changement de titre, nous avons ajouté une section stage pour placer cette étape dans le bon compartiment de l’interface. Nous transmettons également les variables d’environnement plus directement et simplifions quelques éléments.

SnykAppScan:
title: Snyk Test Application Dependencies
stage: scan
image: '${{BuildingDockerImage}}'
working_directory: IMAGE_WORK_DIR
environment:
- SNYK_TOKEN=${{SNYK_TOKEN}}
- SNYK_ORG=${{SNYK_ORG}}
commands:
- npm install -g snyk
- snyk test --severity-threshold=high
on_success:
metadata:
set:
- '${{BuildingDockerImage.imageId}}':
- CF_QUALITY: true
on_fail:
metadata:
set:
- '${{BuildingDockerImage.imageId}}':
- CF_QUALITY: false

Ajoutons maintenant une section SnykScanImage, cette fois pour analyser notre image Docker. Le stage est également scan : il se trouve donc dans le même compartiment que l’étape d’analyse des dépendances de l’application. Comme l’indique la documentation sur les compositions, vous pouvez exécuter plusieurs services pour lancer vos tests.

Dans notre cas, BuildingDockerImage correspond à l’image produite lors de l’étape de compilation. Nous voulons tester cette image de l’extérieur. Nous composons donc notre test avec un service d’analyse qui exécute une autre image que j’ai créée précédemment : aarlaudsnyk/snyk-container-scan-docker. Cette image rassemble simplement les éléments nécessaires à Snyk pour tester une image Docker. Vous trouverez le code source ici :

SnykScanImage:
title: Snyk Test Docker OS Dependencies
stage: scan
type: composition
composition:
version: '2'
services:
targetimage:
image: ${{BuildingDockerImage}} # Must be the Docker build step name
command: sh -c "exit 0"
labels:
build.image.id: ${{CF_BUILD_ID}} # Provides a lookup for the composition
composition_candidates:
scan_service:
image: aarlaudsnyk/snyk-container-scan-docker
command: python snyk-cli.py "${{IMAGE_NAME}}:${{CF_BRANCH_TAG_NORMALIZED}}"
environment:
- SNYK_TOKEN=${{SNYK_TOKEN}}
- SNYK_ORG=${{SNYK_ORG}}
- CFCR_ACCOUNT=${{CFCR_ACCOUNT}}
- CF_USER_NAME=${{CF_USER_NAME}}
- CFCR_LOGIN_TOKEN=${{CFCR_LOGIN_TOKEN}}
depends_on:
- targetimage
volumes: # Volumes required to run DIND
- /var/run/docker.sock:/var/run/docker.sock
- /var/lib/docker:/var/lib/docker
add_flow_volume_to_composition: true
on_success: # Execute only once the step succeeded
metadata: # Declare the metadata attribute
set: # Specify the set operation
- ${{BuildingDockerImage.imageId}}: # Select any number of target images
- SECURITY_SCAN: true

on_fail: # Execute only once the step failed
metadata: # Declare the metadata attribute
set: # Specify the set operation
- ${{BuildingDockerImage.imageId}}: # Select any number of target images
- SECURITY_SCAN: false

La partie intéressante du fichier YAML ci-dessus est la suivante :

image: aarlaudsnyk/snyk-container-scan-docker
command: python snyk-cli.py "${{IMAGE_NAME}}:${{CF_BRANCH_TAG_NORMALIZED}}"

Nous utilisons cette image pour exécuter une commande Python qui fait principalement deux choses :

• Récupérer l’image et la tester localement

• Exécuter « snyk test --docker »

Cette image est conçue pour récupérer l’image depuis le registre Codefresh si les variables d’environnement suivantes sont définies :

• CFCR_ACCOUNT

• CF_USER_NAME

• CFCR_LOGIN_TOKEN

Cela nous permet de tester l’image qui vient d’être créée. Sinon, l’image sera récupérée par défaut depuis Docker Hub.

Enfin, ajoutons à la fin la publication sur le registre Docker Hub, afin de publier effectivement cette image si les tests réussissent :

PushingToDockerRegistry:
title: Pushing to Docker Registry
stage: promote
type: push
candidate: '${{BuildingDockerImage}}'
tag: '${{CF_BRANCH_TAG_NORMALIZED}}'
registry: aarlaudsnyk

Rien de compliqué : Codefresh facilite la publication sur Docker Hub, à condition que l’intégration ait été configurée (voir plus haut). Notez que le stage promote permet de distinguer cette étape des tests d’analyse.

Le tout devrait ressembler à ceci :

version: '1.0'
stages:
- scan
- promote
steps:
BuildingDockerImage:
title: Building Docker Image
type: build
image_name: ${{IMAGE_NAME}}
working_directory: ./
tag: '${{CF_BRANCH_TAG_NORMALIZED}}'
dockerfile:
content: |-
FROM node:8.0-alpine AS builder
WORKDIR /app
COPY package.json /app
# Creating tar of productions dependencies
RUN npm install --production && cp -rp ./node_modules /tmp/node_modules
# Installing all dependencies
RUN npm install
# Copying application code
COPY . /app
SnykAppScan:
title: Snyk Test Application Dependencies
stage: scan
image: '${{BuildingDockerImage}}'
working_directory: IMAGE_WORK_DIR
environment:
- SNYK_TOKEN=${{SNYK_TOKEN}}
- SNYK_ORG=${{SNYK_ORG}}
commands:
- npm install -g snyk
- snyk test --severity-threshold=high
on_success:
metadata:
set:
- '${{BuildingDockerImage.imageId}}':
- CF_QUALITY: true
on_fail:
metadata:
set:
- '${{BuildingDockerImage.imageId}}':
- CF_QUALITY: false

SnykScanImage:
title: Snyk Test Docker OS Dependencies
stage: scan
type: composition
composition:
version: '2'
services:
targetimage:
image: ${{BuildingDockerImage}} # Must be the Docker build step name
command: sh -c "exit 0"
labels:
build.image.id: ${{CF_BUILD_ID}} # Provides a lookup for the composition
composition_candidates:
scan_service:
image: aarlaudsnyk/snyk-container-scan-docker
command: python snyk-cli.py "${{IMAGE_NAME}}:${{CF_BRANCH_TAG_NORMALIZED}}"
environment:
- SNYK_TOKEN=${{SNYK_TOKEN}}
- SNYK_ORG=${{SNYK_ORG}}
- CFCR_ACCOUNT=${{CFCR_ACCOUNT}}
- CF_USER_NAME=${{CF_USER_NAME}}
- CFCR_LOGIN_TOKEN=${{CFCR_LOGIN_TOKEN}}
depends_on:
- targetimage
volumes: # Volumes required to run DIND
- /var/run/docker.sock:/var/run/docker.sock
- /var/lib/docker:/var/lib/docker
add_flow_volume_to_composition: true
on_success: # Execute only once the step succeeded
metadata: # Declare the metadata attribute
set: # Specify the set operation
- ${{BuildingDockerImage.imageId}}: # Select any number of target images
- SECURITY_SCAN: true

on_fail: # Execute only once the step failed
metadata: # Declare the metadata attribute
set: # Specify the set operation
- ${{BuildingDockerImage.imageId}}: # Select any number of target images
- SECURITY_SCAN: false

PushingToDockerRegistry:
title: Pushing to Docker Registry
stage: promote
type: push
candidate: '${{BuildingDockerImage}}'
tag: '${{CF_BRANCH_TAG_NORMALIZED}}'
registry: aarlaudsnyk

6. Essayons de lancer une compilation pour obtenir une première référence. Notre organisation semble en très bon état :

Après un instant, nous obtenons ceci :

Oh là là, notre application présente quelques problèmes. Le pipeline s’est arrêté en toute sécurité pour éviter de livrer un produit comportant des problèmes de sécurité. Corrigeons-les en suivant les étapes de correction indiquées dans le résultat. Il suffit de mettre à niveau le package qs vers la version 6.0.4 dans package.json.

Relançons la compilation.

La vulnérabilité de qs est corrigée, super ! Mais il y a maintenant un problème avec les dépendances du système d’exploitation dans notre image Docker.

Les recommandations de correction indiquent qu’une mise à niveau de l’image serait une bonne solution (consultez la section Docker sur snyk.io/docs). Passons donc à node:10-alpine et réessayons.

Enregistrer => Compiler => Faire des pompes pendant la compilation !

Super ! Nous avons maintenant une référence propre et un pipeline entièrement fonctionnel qui livre notre application et notre conteneur sur Docker Hub.

Nous pouvons maintenant reprendre le codage. Veillons à exécuter snyk test sur nos modifications avant de les fusionner et/ou à les tester avec l’intégration GitHub PR de Snyk. Les modifications seront ensuite livrées automatiquement. Et en bonus, voici la dernière nouveauté !

Utilisez snyk monitor pour surveiller vos dépendances au fil du temps. Personne n’a envie de surveiller ses projets en permanence. En exécutant snyk monitor, Snyk nous avertira automatiquement si une nouvelle vulnérabilité est divulguée pour l’une des dépendances du projet ou de l’image Docker. Il suffit d’ajouter snyk monitor après la section snyk test.

L’URL de l’instantané de surveillance apparaîtra ensuite dans le résultat :

L’étape Docker s’exécutera automatiquement si snyk test réussit (c’est-à-dire si aucun problème connu n’est détecté). Des liens vers les instantanés de surveillance sont également fournis.

Vous pouvez également consulter les projets surveillés dans l’interface Snyk de votre organisation Snyk :

Consultez le pipeline Codefresh en cliquant sur le badge dans le dépôt (https://github.com/snyk-playground/codefresh-pipeline-snyk-app-docker-scan).

Et voilà, c’est tout ! Restez en sécurité !