Sécuriser les conteneurs PHP

Selon Wappalyzer, PHP alimente plus de douze millions de sites web. Pas mal pour un langage vieux de 28 ans ! Malgré son âge, PHP a su s’adapter aux pratiques de développement modernes. Grâce à la prise en charge des déclarations de type et à d’excellents frameworks comme Laravel et Symfony, PHP reste un excellent choix pour développer des applications web. 

PHP fonctionne très bien dans les environnements conteneurisés. Avec une image officielle disponible sur Docker Hub, les développeurs savent qu’ils peuvent s’appuyer sur des images de conteneurs PHP éprouvées.

Les développeurs doivent toutefois faire preuve de prudence lorsqu’ils créent des images de conteneurs pour des applications PHP. PHP étant omniprésent et largement utilisé, les applications PHP constituent une cible de choix pour les attaquants. De plus, comme nous travaillons avec des conteneurs et des microservices, nous sommes susceptibles d’utiliser des conteneurs PHP aux côtés d’applications tierces, ce qui crée une autre voie d’exploitation des vulnérabilités.

Trop souvent, les développeurs supposent que l’isolation des conteneurs suffit à les rendre intrinsèquement sécurisés. Cette idée reçue mène à un manque de vigilance. Rester attentif à la sécurité est essentiel, mais avec un peu de rigueur et de prudence, il n’est pas difficile de développer et d’exécuter des applications PHP conteneurisées sécurisées.

Dans cette optique, explorons concrètement quelques bonnes pratiques pour sécuriser les conteneurs PHP.

Prérequis

Pour mettre vous-même ces bonnes pratiques en œuvre et suivre cette démonstration, assurez-vous de disposer des outils suivants :

• Docker installé sur votre machine. Nous utiliserons Docker pour exécuter nos conteneurs PHP et tirer parti de ses fonctionnalités intégrées afin de les sécuriser.

• Un compte Snyk gratuit. Nous utiliserons les outils d’analyse de sécurité de Snyk pour détecter et corriger les vulnérabilités dans nos conteneurs.

• Node.js pour installer et exécuter la CLI Snyk, ou consultez la documentation sur l’installation de la CLI Snyk pour découvrir d’autres méthodes.

Bonnes pratiques à garder en tête pour les conteneurs

Les conteneurs offrent un moyen pratique d’exécuter des applications PHP. Et même si les environnements d’exécution de conteneurs comme Docker isolent les conteneurs les uns des autres et du système d’exploitation hôte, cette isolation n’est pas parfaite et a déjà été contournée par le passé.

Vous pouvez toutefois prendre plusieurs mesures pour renforcer la sécurité de vos conteneurs PHP, notamment les suivantes.

Définissez des limites de ressources et utilisez des quotas

La configuration de quotas de ressources par conteneur limite la quantité de ressources système qu’il peut utiliser. Ces ressources comprennent la mémoire et le processeur consommés par le conteneur, ainsi que la bande passante des entrées-sorties du disque. Les développeurs PHP peuvent utiliser plusieurs options de l’environnement d’exécution des conteneurs pour limiter l’accès du conteneur aux ressources.

Processeurs

L’option –-cpus <value> indique le nombre de processeurs que le conteneur peut utiliser. Par exemple, en définissant --cpus 3.5, le conteneur peut utiliser précisément trois processeurs et demi, ou cœurs de processeur, parmi ceux disponibles.

Pour un contrôle plus précis, consultez la documentation sur les options cpu-quota et cpu-period dans la documentation Docker. Notez cependant que vous devrez comprendre les périodes de l’ordonnanceur Linux pour utiliser efficacement ces options.

Voici un exemple d’exécution d’un conteneur PHP avec des limites d’utilisation du processeur :

1$ docker run -it --cpus 3.5 php:7.4-cli /bin/bash

Mémoire

L’option -m ou –memory= définit la quantité maximale de mémoire disponible pour le conteneur. Vous pouvez utiliser un entier positif suivi de b, k, m ou g pour indiquer respectivement des octets, des kilo-octets, des mégaoctets ou des gigaoctets.

Par exemple, avec la commande ci-dessous, limitons la réservation de mémoire de notre conteneur à 800 Mo et fixons sa mémoire vive à une capacité maximale de 1,5 gigaoctet.

1$ docker run -it --memory 1.5g --memory-reservation 800m php:7.4-cli /bin/bash

Limiter les ressources disponibles pour un conteneur réduit l’impact potentiel d’une attaque, car cela diminue le risque qu’un conteneur consomme tellement de ressources qu’il perturbe le fonctionnement du système d’exploitation hôte ou d’autres conteneurs. Cette approche renforce la sécurité de chaque conteneur et améliore la sécurité globale de l’environnement hôte.

En l’absence de quotas, les conteneurs exposent un système aux attaques par déni de service (DoS). Une attaque DoS peut interrompre les services en cours d’exécution et dégrader la qualité de service pour les utilisateurs. Les conteneurs sans quotas peuvent ainsi représenter un risque pour l’entreprise s’ils ne sont pas gérés correctement.

Si vous exécutez des conteneurs PHP avec Kubernetes plutôt qu’avec Docker, comprendre les paramètres de contexte de Kubernetes est essentiel pour assurer la sécurité des conteneurs.

Évitez d’exécuter des conteneurs en tant que root

Il est préférable d’éviter d’exécuter nos conteneurs en tant qu’utilisateur root ou avec un compte utilisateur disposant de privilèges supérieurs à ceux nécessaires. Nous devrions plutôt toujours appliquer le principe du moindre privilège lors de la création de comptes utilisateur pour nos conteneurs.

La plupart des environnements d’exécution de conteneurs permettent d’exécuter les conteneurs avec un compte utilisateur non-root. Docker propose un mode rootless qui permet d’exécuter l’environnement d’exécution des conteneurs et tous ses conteneurs avec un compte utilisateur standard.

Kubernetes propose également plusieurs options pour exécuter des nœuds et des conteneurs sans privilèges root. Plus généralement, tout environnement d’exécution de conteneurs conforme à OCI permet de spécifier exactement l’utilisateur et le groupe à utiliser, grâce aux propriétés UID et GID de notre fichier de configuration de l’environnement d’exécution.

En fait, si vous utilisez Snyk pour analyser vos fichiers de configuration Kubernetes ou vos fichiers IaC Terraform, vous pourrez détecter les mauvaises configurations mentionnées ci-dessus, comme Limites de mémoire non définies ou Le conteneur s’exécute en tant que root. Snyk les signale visuellement et indique les lignes de code concernées dans le fichier YAML qui ne respectent pas ces bonnes pratiques de sécurité :

Prenons Docker comme exemple : exécuter nos conteneurs PHP en mode rootless ne diffère pas beaucoup de l’exécution de Docker en tant que root. Toutes les commandes Docker habituelles devraient fonctionner, mais n’oubliez pas que les privilèges que nous pouvons accorder à un conteneur sont limités à ceux du compte utilisateur qui exécute le démon Docker. Il y a toutefois un piège : si vous avez installé le démon Docker avec sa configuration par défaut, vous devrez le désinstaller, puis le réinstaller en mode rootless en suivant les instructions de la documentation Docker.

Évitez d’utiliser un utilisateur root dans les conteneurs

En plus d’exécuter les conteneurs en mode rootless, nous devrions éviter d’utiliser un utilisateur root à l’intérieur du conteneur. Cela peut sembler redondant si nous exécutons déjà le conteneur en mode rootless, mais cette mesure ajoute une couche de défense contre les utilisateurs malveillants.

Nous pouvons exécuter notre conteneur PHP avec un utilisateur non-root en utilisant la directive USER dans le Dockerfile, afin que le conteneur s’exécute dans le contexte d’un utilisateur ou d’un groupe disposant du moins de privilèges possible.

Si une image de base Docker ne comprend pas d’utilisateur disposant de peu de privilèges, nous pouvons en ajouter un non-root lors de la création de l’image. Il sera alors disponible lors de la création d’une nouvelle image de conteneur, comme le montre le Dockerfile suivant :

1FROM php:7.4-cli
2# the command below adds a new user or a group with a userid 1002
3RUN groupadd -g 1002 appuser && \
4    useradd -r -u 1002 -g appuser appuser
5# command below changes a default root user to one with non-root privileges
6USER appuser
7CMD ["touch", "/root/example.txt"]

Les images officielles de conteneurs PHP comprennent un compte utilisateur non privilégié nommé nobody. Si vous créez une image de conteneur à partir d’une image de base Docker officielle, vous pouvez donc utiliser cet utilisateur plutôt que d’en créer un vous-même (comme montré ci-dessus) :

1FROM php:7.4-cli
2USER nobody
3CMD ["touch", "/root/example.txt"]

Maintenant, si nous exécutons l’image Docker en mode interactif et essayons de consulter le fichier texte créé pour l’utilisateur root dans le Dockerfile, nous verrons que nous n’y sommes pas autorisés :

1$ cat /root/example.txt
2cat: /root/example.txt: Permission denied

À retenir : éviter d’utiliser root à la fois au niveau de l’environnement d’exécution et à l’intérieur des conteneurs signifie qu’une image d’application Docker malveillante, ou une application conteneurisée compromise, devrait réussir deux attaques d’escalade de privilèges pour pénétrer dans le système d’exploitation hôte sur lequel le conteneur s’exécute, puis poursuivre avec un mouvement latéral.

Il n’est toutefois pas toujours possible d’utiliser des conteneurs rootless. Certaines applications conteneurisées ont parfois besoin d’accéder à du matériel comme un GPU. Heureusement, nous pouvons ajouter d’autres couches de défense.

Corrigez les vulnérabilités des conteneurs grâce à des outils automatisés

Les conteneurs peuvent abriter de nombreuses vulnérabilités. Les bibliothèques et applications incluses dans votre image de base, ainsi que les paquets supplémentaires que vous installez, peuvent contenir des CVE ou d’autres vulnérabilités. Comment le savoir ? La plupart des équipes de développement et DevOps n’ont pas le temps de suivre manuellement l’historique de sécurité de chaque paquet installé dans leurs conteneurs. 

Heureusement, l’analyse automatisée des conteneurs peut vous aider. Snyk Container est gratuit et peut analyser automatiquement vos images pour vous signaler immédiatement les vulnérabilités dans les paquets et les bibliothèques open source de vos conteneurs. Vous pouvez ainsi déployer des correctifs dès l’apparition d’une vulnérabilité, avant que les attaquants ne puissent l’exploiter. Snyk propose aussi automatiquement des correctifs en ouvrant des demandes de tirage avec une image de base mise à jour et les balises d’image recommandées.

Snyk permet d’analyser rapidement et facilement vos conteneurs à la recherche de vulnérabilités. Si Node.js et npm sont installés, il vous suffit d’exécuter npm install snyk@latest -g pour installer la CLI Snyk.

Exécutez ensuite :

1snyk auth

Cette commande ouvrira une page d’authentification dans votre navigateur :

"blog-php-container-authenticateUn message confirmant la réussite de l’authentification s’affichera dans votre terminal lorsque vous cliquerez sur le bouton Authenticate.

Nous pouvons maintenant analyser nos conteneurs avec la CLI Snyk en exécutant :

1snyk container test <your-image>

Voici le résultat obtenu avec une image de base PHP 7.4 :

L’analyse du conteneur Snyk a détecté 87 problèmes dans l’image de base.

Idéalement, nous devrions analyser les conteneurs dans notre pipeline CI/CD pour nous assurer de ne jamais déployer en production un conteneur vulnérable. Nous pouvons également utiliser la commande de surveillance des conteneurs pour envoyer à Snyk les résultats de test de notre image de conteneur. Snyk pourra ainsi afficher ces informations dans notre tableau de bord et nous avertir de l’apparition de nouvelles vulnérabilités dans notre image.

1snyk container monitor <your-image>

Voici le résultat de l’analyse de la même image PHP que nous venons de tester :

Facile, non ? Et ce n’est pas tout. Nous pouvons aussi utiliser Snyk Code pour vérifier la sécurité de notre code PHP avant de le conteneuriser.

Accédez au dossier contenant le fichier manifeste de votre application PHP, puis exécutez la commande ci-dessous pour afficher le résultat :

1snyk code test

Nous pouvons lancer un test Snyk Code sur un ancien projet Laravel pour examiner un cas fréquent : repérer les vulnérabilités dans un projet PHP obsolète, mais toujours fonctionnel. Voici le résultat :

Comme pour la surveillance des conteneurs, nous pouvons également demander à Snyk de surveiller notre base de code en exécutant snyk monitor dans le répertoire principal de notre application PHP. L’application apparaîtra alors dans notre tableau de bord Snyk.

L’analyse de sécurité des conteneurs et du code nous offre un excellent moyen de veiller à livrer des conteneurs et du code sécurisés.

Utilisez des images de conteneurs fiables

Pour sécuriser nos conteneurs PHP, nous pouvons récupérer des images dans des registres en ligne sécurisés et fiables. Ces registres sont moins susceptibles d’héberger des images contenant du code obsolète ou malveillant qui pourrait exposer notre environnement de conteneurs à une violation de données. Docker Hub, par exemple, propose diverses images fiables que Docker vérifie minutieusement pour détecter les vulnérabilités et dont les fournisseurs sont également vérifiés par Docker.

Cependant, les images disponibles sur Docker Hub ne sont pas toutes fiables. Lorsque nous utilisons des registres en ligne, nous devrions vérifier le contenu des images pour détecter d’éventuelles vulnérabilités. Nous pouvons analyser l’image à la recherche de code malveillant susceptible de menacer le conteneur avant de la télécharger sur le système hôte. Pour ne jamais oublier cette étape, nous pouvons intégrer directement un outil de sécurité comme Snyk à nos outils ou workflows de développement afin de surveiller et de corriger les vulnérabilités potentielles de nos conteneurs.

Au-delà de l’analyse, nous pouvons nous assurer d’utiliser des images de conteneurs fiables grâce à Docker Hub, au programme Docker Verified Publisher et aux Docker Official Images. Le programme Docker Verified Publisher valide que les images récupérées proviennent de sources fiables, afin d’éviter que les utilisateurs téléchargent des images non sécurisées depuis de faux dépôts.

Nous pouvons aussi utiliser des images vérifiées par Docker Content Trust. Docker 1.8 a introduit Docker Content Trust pour renforcer la signature numérique des images et leur authentification. La signature d’image valide l’origine d’une image de conteneur et vérifie qu’elle n’a pas été modifiée. Elle définit également les règles qui déterminent quelles images validées les utilisateurs peuvent télécharger sur leurs systèmes.

Même si vous récupérez les images officielles de Docker auprès de Docker Verified Publishers ou via Docker Content Trust pour sécuriser votre environnement de conteneurs, il reste essentiel d’utiliser Snyk pour sécuriser vos conteneurs.

La sécurité des conteneurs PHP relève des développeurs PHP

Pour protéger les conteneurs PHP contre les menaces potentielles, il faut mettre en œuvre plusieurs techniques de sécurité tout au long du cycle de vie de l’application, de la compilation au déploiement et à l’exécution. En plus de suivre les bonnes pratiques de sécurisation des applications PHP dans des conteneurs, vous pouvez compter sur Snyk pour préserver la sécurité de vos conteneurs grâce à des outils automatisés, tels que :

• Des tests de sécurité automatisés dans les pipelines CI/CD, comme les intégrations GitHub Actions ou AWS Code Pipeline

• Des renseignements de sécurité unifiés pour les conteneurs et le code source

• Une intégration à Kubernetes pour surveiller et observer les conteneurs dans vos clusters Kubernetes afin de détecter toute vulnérabilité nouvelle ou existante

• Une approche axée sur les développeurs qui signale les problèmes de sécurité dans votre propre code PHP et facilite leur résolution, même sans connaissances approfondies en sécurité

Snyk Container est un outil de gestion des vulnérabilités des conteneurs qui vous aide à identifier et à résoudre les problèmes de sécurité des conteneurs de manière complète et efficace. Grâce à ses contrôles intégrés dans l’IDE, à son intégration CI/CD automatisée, à l’analyse native de Git et à ses tests en environnement de production, Snyk Container sécurise vos conteneurs et vos charges de travail Kubernetes tout au long du cycle de développement logiciel.

Snyk peut également vous aider à détecter les vulnérabilités en intégrant l’analyse de sécurité à des outils de développement comme VS Code et JetBrains. Les applications sont ainsi analysées pendant leur développement, et vous obtenez davantage d’informations sur les types de vulnérabilités ainsi que sur les correctifs suggérés.

Snyk peut aussi aider les développeurs à détecter les vulnérabilités qui compromettent la sécurité des conteneurs. Il corrige automatiquement ces problèmes, améliore la productivité et permet aux équipes de développement de consacrer moins de temps à corriger le code et plus de temps à créer des applications. Créez votre compte gratuit dès aujourd’hui. Vous pouvez également essayer notre outil en ligne gratuit de vérification du code PHP pour découvrir comment le moteur Snyk Code analyse votre code afin d’y détecter les problèmes de sécurité et de qualité.