Principes de base de la sécurité des conteneurs : sécurisation du pipeline

Si vous découvrez cette série, nous vous conseillons de commencer par le début :
Principes de base de la sécurité des conteneurs : introduction

À l’ère du capital applicatif, le pipeline CI/CD est un composant essentiel dont dépendent la rapidité et la sécurité des applications qu’il crée et déploie.

Il s’agit d’un système complexe d’outils, intégrés via des API et appelés par des scripts ou des plugins qui représentent numériquement le processus que vous suivez pour créer et, à terme, livrer des applications conteneurisées. Cela signifie qu’il existe de nombreux points auxquels un acteur malveillant pourrait compromettre le système. Même si cela peut sembler peu plausible, n’oubliez pas qu’un grand nombre d’organisations tirent aujourd’hui parti du cloud, ce qui implique nécessairement un accès à distance.

Cela signifie que la sécurité du pipeline comporte deux volets : premièrement, la sécurité du pipeline lui-même. Deuxièmement, la sécurité au sein du pipeline.

Sécurité du pipeline

1. L’authentification n’est pas facultative
Si vous utilisez des outils et des services dans le cadre de votre pipeline dans le cloud ou sous forme de services hébergés, ils sont exposés aux attaques. Si vous permettez à des développeurs ou à des équipes d’exploitation à distance d’accéder à des outils et services hébergés en interne, ceux-ci sont également exposés aux attaques. Avant d’écarter ce risque, n’oublions pas le nombre de violations de sécurité survenues ces dernières années à la suite de l’ouverture de systèmes à des accès externes. En matière de sécurité du pipeline, la meilleure approche consiste à partir du principe qu’il est bel et bien accessible à des acteurs malveillants.

La priorité absolue est donc de sécuriser les accès. Une authentification forte n’est pas facultative. Il est vivement recommandé d’utiliser un contrôle des accès afin de gérer précisément l’accès aux systèmes critiques, même si vous pensez que ces systèmes ne sont accessibles qu’en interne. D’autres systèmes présents sur votre réseau peuvent permettre à des acteurs malveillants d’y accéder.

Une fois l’authentification mise en place, il faut s’occuper de l’autorisation. Celle-ci détermine ce qu’un utilisateur authentifié peut faire au sein du système. Il est important de différencier les privilèges en fonction des rôles, car moins il existe d’identifiants donnant accès aux composants critiques, plus votre environnement est sécurisé.

Chaque composant du pipeline doit exiger une authentification et une autorisation. Cela concerne aussi bien les dépôts que les outils utilisés pour créer les applications et les conteneurs.

2. Sécurisation des composants du pipeline
Il n’est malheureusement pas rare d’apprendre que des attaquants ont découvert de véritables trésors (identifiants et autres secrets) en analysant des dépôts publics. Reportez-vous au premier point pour vous rappeler qu’il est indispensable d’exiger une authentification pour accéder aux dépôts.

La réalité des pipelines actuels est qu’ils constituent une chaîne intégrée d’outils, dont chacun devrait nécessiter une authentification. Par conséquent, les identifiants et les secrets (clés) finissent souvent par être stockés dans des scripts qui font appel aux outils et services composant le pipeline. C’est une très mauvaise chose™, en particulier lorsque cela s’accompagne de mauvaises pratiques d’authentification sur les dépôts où ces scripts peuvent être stockés.

Les identifiants sont des ressources critiques qui doivent être protégées. Il est essentiel de savoir où ils se trouvent, où ils sont stockés et comment ils sont sécurisés. Un outil utile pour gérer la « prolifération des secrets » est HashiCorp Vault. Vault stocke les secrets de manière sécurisée dans un emplacement centralisé.

Sécurité dans le pipeline

3. Tenez à jour une nomenclature
Avant de pouvoir sécuriser un système – ou un composant du système –, vous devez savoir qu’il existe. Il est important de tenir à jour une nomenclature exhaustive afin de savoir ce qui se trouve dans votre environnement. Plus précisément, vous devez savoir ce qui devrait se trouver dans votre environnement – et, inversement, ce qui ne devrait pas s’y trouver.

Un inventaire bien tenu peut contribuer à vous protéger contre les tentatives d’introduction de composants altérés ou compromis dans le pipeline. La standardisation autour d’un conteneur de base unique, ou tout au moins d’un nombre raisonnable de conteneurs, peut considérablement améliorer votre capacité à détecter les problèmes potentiels. Tout écart doit alors déclencher une alerte afin de pouvoir faire l’objet d’une investigation. Par exemple, il est important de comparer les empreintes de hachage et, si possible, de valider les signatures numériques des images de conteneurs. Si vous les récupérez depuis un dépôt distant, celui-ci peut avoir été compromis.

C’est ce qui s’est produit lorsque DockerHub a subi une violation de données qui a exposé les identifiants et les jetons d’accès de 190 000 de ses utilisateurs. Grâce à ces informations, des attaquants auraient pu compromettre des images qui leur auraient ensuite permis d’accéder à d’autres systèmes.

Ne vous limitez pas aux images de conteneurs. N’oubliez pas que les composants applicatifs provenant de sources externes peuvent être compromis. Un exemple concret est l’insertion d’un logiciel de minage de cryptomonnaie dans un paquet NPM Node.js event-stream.

La standardisation autour d’un inventaire tenu à jour d’images et de composants simplifie également la correction des vulnérabilités lorsque celles-ci apparaissent — car elles finiront inévitablement par apparaître. La mise à jour d’une seule couche de système d’exploitation de base est bien plus facile à gérer que celle d’un ensemble hétérogène de conteneurs.

4. Analyser et corriger
Les environnements de conteneurs peuvent être compromis ou devenir vulnérables aux attaques de multiples façons. On pense le plus souvent aux vulnérabilités des logiciels présents dans une image de conteneur. Bien qu’il faille y prêter attention — en les analysant et en appliquant des mises à jour ou des correctifs —, il existe également des problèmes de configuration qui sont moins souvent détectés et corrigés. Bon nombre d’entre eux peuvent être évités grâce à une configuration appropriée. Votre pipeline doit inclure des outils capables de détecter les compromissions ou de signaler les configurations non sécurisées.

Aqua Security propose des outils permettant d’analyser et d’évaluer aussi bien les conteneurs que les configurations. Kube-bench et kube-hunter sont d’excellentes ressources pour identifier les erreurs de configuration courantes (mais critiques) dans les environnements Kubernetes.

o Logiciels libres
https://github.com/aquasecurity/kube-bench
https://github.com/aquasecurity/kube-hunter

o Commercial
https://www.aquasec.com/

Même toutes les analyses du monde ne permettront pas d’éviter une compromission ou une violation de sécurité si vous ne prenez pas les mesures qui s’imposent. Le rapport 2019 de Tripwire sur l’état de la sécurité des conteneurs a révélé que près d’une organisation sur cinq (17 %) avait connaissance de vulnérabilités dans des images de conteneurs, mais les avait tout de même déployées. Dans ce contexte, il n’est sans doute pas surprenant que l’enquête ait constaté que plus de la moitié (60 %) des organisations avaient subi un incident de sécurité lié aux conteneurs au cours des douze mois précédents.

On ne le répétera jamais assez : si vous intégrez des analyses de sécurité à votre pipeline (et vous devriez le faire), il est important de donner suite aux problèmes détectés. Effectuer une analyse ne contribue en rien à améliorer la sécurité si vous ne corrigez pas ces problèmes.

Nous le répétons : effectuer une analyse ne contribue en rien à améliorer la sécurité si vous ne corrigez pas les vulnérabilités détectées.

La sécurité du pipeline est une problématique complexe aux multiples facettes. Le pipeline doit être traité comme n’importe quel autre ensemble d’applications, car c’est bien ce qu’il est en définitive, même s’il s’agit d’un outil opérationnel. Ne négligez pas la sécurité du pipeline lorsque vous intégrez la sécurité dans celui-ci.

Lisez le prochain article de blog de la série :
Principes de base de la sécurité des conteneurs : orchestration