Skip to main content

Utiliser les images UBI pour réduire les vulnérabilités des conteneurs

Écrit par
Headshot of Rags Srinivas

Rags Srinivas

Blog Design Red

27 mars 2020

0 minutes de lecture

Chez Snyk, nous mettons tout en œuvre pour améliorer continuellement nos solutions de sécurité des conteneurs et du cloud-native. Dans cette optique, Snyk Container permet aux développeurs de prendre pleinement en charge la sécurité de leurs images de conteneurs.

Les images de base utilisées comme fondation pour créer vos propres images personnalisées sont une source courante de vulnérabilités dans les conteneurs. Plutôt que de simplement réagir à l’apparition de nouvelles vulnérabilités, mieux vaut adopter une approche proactive en choisissant des images de base soigneusement sélectionnées et régulièrement mises à jour.

Dans cet article, nous nous intéressons aux Universal Base Images de Red Hat, qui contribuent à atteindre cet objectif.

Qu’est-ce qu’une Universal Base Image (UBI) ?

Annoncées au Red Hat Summit en 2019, les Universal Base Images de Red Hat reposent sur une plateforme de niveau entreprise : Red Hat Enterprise Linux (RHEL). Ces images de systèmes d’exploitation de base pour conteneurs, conformes aux normes OCI, incluent différents langages d’exécution et packages librement redistribuables. Les images UBI 8, par exemple, sont mises à jour à chaque mise à jour des images de base RHEL 8 et à l’application de correctifs aux CVE critiques.

D’un point de vue technique, elles sont presque identiques aux images Red Hat Enterprise Linux, ce qui leur confère une excellente sécurité, de bonnes performances et des cycles de vie bien établis. Elles sont distribuées sous un contrat de licence utilisateur final différent. Il est possible de créer une application conteneurisée avec UBI, de la pousser vers n’importe quel registre, de la partager facilement et, puisqu’elle est librement redistribuable, de la déployer même sur des plateformes autres que Red Hat.

Consultez la documentation de Red Hat sur la création, l’exécution et la gestion de conteneurs pour en savoir plus. Les images de conteneurs certifiées figurent également dans le catalogue de conteneurs de Red Hat. Les images UBI couvrent un large éventail de langages de développement populaires, dont dotnet, golang, nodejs, Python, PHP et Ruby.

Vous trouverez d’autres informations sur les images UBI dans la FAQ de Red Hat. Comme nous le montrons ci-dessous, il est assez simple d’intégrer ces images à votre workflow.

Créer des images de conteneurs avec UBI

Commençons par un exemple de Dockerfile pour Python. Une approche similaire permet d’utiliser des images UBI avec différents langages d’exécution.

Voici un Dockerfile généré automatiquement pour un exemple simple « Hello World! » en Python utilisant flask.

FROM python
ENV PORT 8080
EXPOSE 8080
WORKDIR /usr/src/app

COPY requirements.txt . 
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

ENTRYPOINT ["python"] 
CMD ["app.py"]

Au lieu d’utiliser python comme image de base, utilisons l’image UBI du registre Red Hat en modifiant le Dockerfile comme indiqué ci-dessous (vous aurez peut-être besoin des identifiants appropriés pour vous authentifier et utiliser les images). Notez que seule la première ligne change : nous y utilisons l’image UBI.

FROM registry.redhat.io/ubi8/python-36
ENV PORT 8080
EXPOSE 8080
WORKDIR /usr/src/app

COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

ENTRYPOINT ["python"] 
CMD ["app.py"]

La génération d’une application conteneurisée avec une image UBI comme image de base est identique à celle d’une application utilisant une image non UBI, comme indiqué ci-dessous :

docker build -t ragsns/example-python-ubi .

L’exécution de Snyk sur l’application conteneurisée utilisant une image UBI comme image de base génère la liste de vulnérabilités ci-dessous.

snyk test --container ragsns/example-python-ubi --file=Dockerfile          

Testing ragsns/example-python-ubi...

✗ Low severity vulnerability found in npm
  Description: RHEA-2020:0330
  Info: https://snyk.io/vuln/SNYK-RHEL8-NPM-555355
  Introduced through: npm@1:6.9.0-1.10.16.3.2.module+el8.0.0+4214+49953fda
  From: npm@1:6.9.0-1.10.16.3.2.module+el8.0.0+4214+49953fda
  Introduced by your base image (registry.redhat.io/ubi8/python-36)
  Fixed in: 1:6.13.4-1.12.14.1.1.module+el8.1.0+5466+30f75629

✗ Low severity vulnerability found in nodejs
  Description: RHEA-2020:0330
  Info: https://snyk.io/vuln/SNYK-RHEL8-NODEJS-555347
  Introduced through: nodejs@1:10.16.3-2.module+el8.0.0+4214+49953fda
  From: nodejs@1:10.16.3-2.module+el8.0.0+4214+49953fda
  Introduced by your base image (registry.redhat.io/ubi8/python-36)
  Fixed in: 1:12.14.1-1.module+el8.1.0+5466+30f75629

✗ High severity vulnerability found in systemd-pam
  Description: RHSA-2020:0575
  Info: https://snyk.io/vuln/SNYK-RHEL8-SYSTEMDPAM-552042
  Introduced through: systemd-pam@239-18.el8_1.2
  From: systemd-pam@239-18.el8_1.2
  Introduced by your base image (registry.redhat.io/ubi8/python-36)
  Fixed in: 0:239-18.el8_1.4

✗ High severity vulnerability found in systemd-libs
  Description: RHSA-2020:0575
  Info: https://snyk.io/vuln/SNYK-RHEL8-SYSTEMDLIBS-552044
  Introduced through: systemd-libs@239-18.el8_1.2
  From: systemd-libs@239-18.el8_1.2
  Introduced by your base image (registry.redhat.io/ubi8/python-36)
  Fixed in: 0:239-18.el8_1.4

✗ High severity vulnerability found in systemd
  Description: RHSA-2020:0575
  Info: https://snyk.io/vuln/SNYK-RHEL8-SYSTEMD-552048
  Introduced through: systemd@239-18.el8_1.2
  From: systemd@239-18.el8_1.2
  Introduced by your base image (registry.redhat.io/ubi8/python-36)
  Fixed in: 0:239-18.el8_1.4

✗ High severity vulnerability found in npm
  Description: RHSA-2020:0579
  Info: https://snyk.io/vuln/SNYK-RHEL8-NPM-555375
  Introduced through: npm@1:6.9.0-1.10.16.3.2.module+el8.0.0+4214+49953fda
  From: npm@1:6.9.0-1.10.16.3.2.module+el8.0.0+4214+49953fda
  Introduced by your base image (registry.redhat.io/ubi8/python-36)
  Fixed in: 1:6.13.4-1.10.19.0.1.module+el8.1.0+5726+6ed65f8c

✗ High severity vulnerability found in npm
  Description: RHSA-2020:0598
  Info: https://snyk.io/vuln/SNYK-RHEL8-NPM-557042
  Introduced through: npm@1:6.9.0-1.10.16.3.2.module+el8.0.0+4214+49953fda
  From: npm@1:6.9.0-1.10.16.3.2.module+el8.0.0+4214+49953fda
  Introduced by your base image (registry.redhat.io/ubi8/python-36)
  Fixed in: 1:6.13.4-1.12.16.1.1.module+el8.1.0+5811+44509afe

✗ High severity vulnerability found in nodejs
  Description: RHSA-2020:0579
  Info: https://snyk.io/vuln/SNYK-RHEL8-NODEJS-555367
  Introduced through: nodejs@1:10.16.3-2.module+el8.0.0+4214+49953fda
  From: nodejs@1:10.16.3-2.module+el8.0.0+4214+49953fda
  Introduced by your base image (registry.redhat.io/ubi8/python-36)
  Fixed in: 1:10.19.0-1.module+el8.1.0+5726+6ed65f8c

✗ High severity vulnerability found in nodejs
  Description: RHSA-2020:0598
  Info: https://snyk.io/vuln/SNYK-RHEL8-NODEJS-557034
  Introduced through: nodejs@1:10.16.3-2.module+el8.0.0+4214+49953fda
  From: nodejs@1:10.16.3-2.module+el8.0.0+4214+49953fda
  Introduced by your base image (registry.redhat.io/ubi8/python-36)
  Fixed in: 1:12.16.1-1.module+el8.1.0+5811+44509afe

Organization:      rags
Package manager:   rpm
Target file:       Dockerfile
Project name:      docker-image|ragsns/example-python-ubi
Docker image:      ragsns/example-python-ubi
Base image:        registry.redhat.io/ubi8/python-36
Licenses:          enabled

Tested 417 dependencies for known issues, found 9 issues.

L’exécution du conteneur basé sur une image UBI est également identique à celle de l’application reposant sur une image non UBI, comme indiqué ci-dessous.

docker run -it -p8080:8080 ragsns/example-python-ubi

Cela est possible grâce à ce qui est décrit dans la documentation : « Les nouvelles Universal Base Images de Red Hat vous permettent de créer votre conteneur UNE SEULE FOIS et de le redistribuer librement vers plusieurs plateformes de déploiement. »

Vous pouvez aussi utiliser la commande suivante si vous préférez employer l’ensemble d’outils de conteneurisation de Red Hat pour tester ou exécuter l’application.

podman run -p 8080:8080 ragsns/example-python-ubi

Maintenant que nous avons vu un exemple avec Python, plutôt que de détailler chaque exemple de langage d’exécution (certains peuvent nécessiter quelques modifications supplémentaires selon le langage utilisé), examinons-les tous ensemble.

Images UBI pour plusieurs langages

Comme indiqué précédemment, il existe des images UBI pour plusieurs langages d’exécution. L’analyse par Snyk de différentes images UBI produit les résultats récapitulés dans le tableau suivant.

Image UBI

Dépendances

Vulnérabilités

registry.redhat.io/ubi8/nodejs-10

373

9

registry.redhat.io/ubi8/python-36

417

9

registry.redhat.io/ubi8/ruby-26

481

9

registry.redhat.io/ubi8/php-73

403

9

registry.redhat.io/ubi8/go-toolset

371

13

registry.redhat.io/ubi8/dotnet-21

248

10

La diversité des langages disponibles et le faible nombre de vulnérabilités des images UBI s’expliquent par le travail de sélection et de mise à jour minutieux réalisé par Red Hat. Celui-ci porte notamment sur le système d’exploitation de base, les dépôts yum utilisés pour installer les packages et les outils, ainsi que sur les langages et les frameworks. Cet article de Red Hat explique le processus en détail : il s’appuie notamment sur une liste de bugs des images UBI, qui sont actualisées et maintenues périodiquement selon un processus similaire à celui du système d’exploitation de base.

Résumé et prochaines étapes

Nous avons montré à quel point il est facile de baser des applications conteneurisées sur des images UBI pour différents langages d’exécution. Les modifications, notamment l’extraction de l’image UBI de Red Hat, sont faciles à appliquer et à intégrer à votre pipeline CI/CD ou de développement, sans changer vos workflows habituels.

Du point de vue de la sécurité, les images UBI constituent une bonne option pour conteneuriser vos applications. Comme nous l’avons vu, elles font l’objet d’un processus de maintenance rigoureux, conforme à celui, bien établi, du système d’exploitation RHEL. Disponibles pour différents langages d’exécution, elles peuvent servir d’images de base à vos conteneurs et contribuer à réduire les vulnérabilités de vos applications.

Snyk contribue à sécuriser le développement de vos applications tout au long du cycle de vie du développement logiciel, notamment grâce à des intégrations avec votre registre d’images, votre dépôt Dockerfile, vos pipelines CI/CD et vos clusters Kubernetes, y compris les environnements OpenShift 4. Snyk Container prend en charge les images UBI et RHEL, ainsi que d’autres distributions Linux populaires.

La sécurité des conteneurs, pensée pour les développeurs

Snyk détecte et corrige automatiquement les vulnérabilités dans les images de conteneurs et les workloads Kubernetes.