Alors, vous pensez que votre environnement CI/CD est sécurisé ?

Cet article, coécrit par Weaveworks et Snyk, explique comment un pipeline GitOps d’intégration continue (CI) et de livraison continue (CD), associé à de bonnes pratiques de sécurité, renforce la sécurité globale de votre workflow de développement sur Kubernetes.

Le pipeline CI/CD classique

Votre pipeline CI/CD ressemble peut-être beaucoup au modèle simplifié ci-dessous. Le processus commence tout à gauche, lorsque le code se trouve sur la machine du développeur et est envoyé vers un dépôt de code, comme GitHub. Un outil CI récupère ensuite le code, exécute des tests, puis crée un artefact, comme une image de conteneur. L’image est envoyée vers le dépôt d’images et déployée sur un orchestrateur open source comme Kubernetes ou un système similaire.

Mais on oublie souvent de se demander si le modèle classique de déploiement par push dans votre pipeline CI/CD est sécurisé. Posez-vous les deux questions suivantes :

• Votre environnement CI a-t-il un accès direct au dépôt d’images de conteneur ?

• Votre environnement CI a-t-il un accès direct au cluster de production ?

Examinons à nouveau le pipeline, mais cette fois en nous intéressant aux étapes qui ont accès les unes aux autres. Dans l’image ci-dessous, RW signifie « lecture et écriture » et RO, « lecture seule ». Il y a sans doute bien plus de lignes rouges que vous ne l’imaginiez ! Ce pipeline simple enfreint certains des principes de sécurité de l’Open Web Application Security Project (OWASP), notamment le principe du moindre privilège et la séparation des tâches. Par exemple, le développeur dispose d’un accès en lecture et en écriture au dépôt de code et au cluster.

En supprimant l’accès direct des développeurs au dépôt d’images et au cluster, on réduit la surface d’attaque et les accès privilégiés, tout en séparant les tâches.

Place à GitOps

GitOps est une méthode de livraison continue pour les applications cloud natives. Elle utilise Git comme source de vérité pour l’infrastructure déclarative et les applications. Les pipelines de livraison déploient automatiquement les modifications de votre infrastructure lorsque des changements sont apportés à Git. Mais l’approche va plus loin : elle s’appuie également sur des outils qui examinent l’état réel de la production et vous signalent les écarts entre la source et la réalité.

La méthode GitOps corrige les failles d’un pipeline non sécurisé en exécutant un opérateur de réconciliation directement dans le cluster. Celui-ci agit sur un dépôt Git de configuration à l’aide d’identifiants distincts. L’opérateur compare l’état souhaité, défini dans les fichiers manifestes stockés dans le dépôt Git, à l’état réel du cluster, puis les met en concordance.

Ainsi, aucun identifiant ne fuit d’une zone à l’autre. Le système CI peut fonctionner dans une « zone » de sécurité distincte, et non sur le cluster cible. Chaque composant du pipeline n’a besoin que d’un seul identifiant RW. Comme les identifiants du cluster ne quittent jamais celui-ci, vous pouvez désormais « garder vos secrets près de vous ».

Dois-je encore me soucier de la sécurité ?

En adoptant cette approche, vous réduisez les risques de sécurité en résolvant notamment les problèmes liés au principe du moindre privilège et à la séparation des tâches. Bien sûr, cela ne répond pas à toutes vos préoccupations en matière de sécurité. En fait, cela souligne encore davantage l’importance de sécuriser votre dépôt de code.

Place à GitSecOps

D’accord, notre secteur compte déjà assez de mots à la mode, inutile d’en inventer un autre. Cela dit, la plupart des idées de James Governor, alias @monkchips, finissent tôt ou tard par se concrétiser. Merci pour l’idée, James, et nous espérons que cet article vous plaira !

Voici quelques conseils pour mieux sécuriser votre dépôt de code.

Ajoutez des tests de sécurité à vos PR

Tous les principaux dépôts de code disposent de puissants frameworks de hooks déclenchés par des événements. Ils vous permettent d’envoyer des requêtes HTTP POST à un service de votre choix lorsqu’un événement survient. Vous pouvez choisir parmi un grand nombre d’événements, mais l’un des plus utiles pour tester vos modifications de code incrémentielles est l’événement pull_request.

De nombreux outils d’analyse statique du code prennent en charge les hooks : lorsqu’une PR est créée, une requête HTTP POST est envoyée pour lancer le test de vos dernières modifications. C’est également le moment idéal pour vérifier que les changements apportés au code et à la configuration respectent vos exigences de sécurité.

Analysez statiquement votre dépôt avec Snyk

Snyk analyse statiquement votre dépôt pour détecter les dépendances vulnérables que vous utilisez peut-être, puis vous aide à les corriger. Vous pouvez tester vos dépôts dans l’interface Snyk pour détecter les problèmes, mais aussi empêcher l’ajout de nouvelles bibliothèques vulnérables en testant les pull requests et en faisant échouer un test lorsqu’une nouvelle vulnérabilité est introduite.

En plus de s’intégrer facilement à GitHub, GitLab et Bitbucket, les pull requests sont préférables au fait de « casser la build ». En effet, elles n’ont même pas besoin de bloquer une fusion, puisqu’elles sont informatives par défaut. Les tests portent uniquement sur vos modifications, et non sur le résultat global. Ils échouent seulement si vous avez introduit une bibliothèque vulnérable, et non si celle-ci était déjà présente avant vos changements.

Ne stockez jamais d’identifiants dans le code ou la configuration

Une recherche rapide sur GitHub montre à quel point les mots de passe stockés dans les dépôts sont répandus. Les 350 000 commits trouvés par cette simple recherche ne comprennent ni ceux dont les messages de commit étaient moins explicites, ni ceux qui ont tenté de dissimuler leurs traces en supprimant leur historique.

Vous pouvez aussi utiliser des outils comme git-secrets pour faire échouer automatiquement les builds lorsque des informations sensibles sont détectées dans le code ou un fichier de configuration. Mettre en place des règles applicables à toute l’équipe est un excellent moyen de prévenir les mauvaises pratiques dans le workflow de développement existant.

Il existe de nombreuses façons d’éviter d’ajouter des identifiants à votre dépôt. Essayez d’en appliquer autant que possible, mais même ainsi, des informations sensibles peuvent toujours s’y glisser. Pensez aussi à auditer régulièrement vos dépôts et à utiliser des outils comme GitRob ou truffleHog, qui analysent votre base de code à la recherche d’informations sensibles en faisant correspondre des modèles.

Si vous découvrez des données sensibles stockées dans votre dépôt de code, vous devrez prendre plusieurs mesures pour remédier à la situation :

1. Vous devrez invalider les jetons et les mots de passe qui ont été exposés.

2. Dès qu’un secret est accessible au public sur Internet, partez du principe qu’il est entre les mains d’attaquants et réagissez en conséquence.

3. Supprimez toute trace de vos secrets de l’historique, afin qu’ils ne figurent ni dans le code ni dans la piste d’audit.

Contrôlez étroitement les accès

Imposez les pratiques de base suivantes à vos contributeurs :

• Exigez l’authentification à deux facteurs sur le compte GitHub de chaque contributeur.

• Ne laissez jamais les utilisateurs partager des comptes ou des mots de passe.

• Sécurisez correctement tous les ordinateurs et appareils qui accèdent à votre code source.

• Les comptes sont souvent personnels et ne sont pas automatiquement désactivés lorsque leurs utilisateurs quittent l’entreprise. Veillez à révoquer rigoureusement les accès des personnes qui ne travaillent plus avec vous.

• Les administrateurs du dépôt doivent gérer les accès de l’équipe aux données. Donnez aux contributeurs uniquement accès aux données dont ils ont besoin pour travailler.

Ajoutez un fichier SECURITY.md

Il est naturel pour la plupart des propriétaires et des responsables de projet d’ajouter un fichier README.md à leur dépôt. D’ailleurs, de nos jours, l’absence de README est plutôt mal vue. De même, il est de plus en plus courant d’ajouter un fichier SECURITY.md qui présente les informations de sécurité relatives à votre projet. Ce fichier fournit aux utilisateurs les informations de sécurité essentielles et incite les responsables à réfléchir à la gestion des signalements de vulnérabilités, des mises à jour et des pratiques générales de sécurité. Vous trouverez de bons exemples de fichiers SECURITY.md dans les dépôts Apache Storm et TensorFlow.

En résumé

Votre serveur CI peut parfaitement orchestrer le développement, la fusion dans la branche principale, la compilation et les tests. Toutefois, d’autres considérations de sécurité entrent en jeu lorsque les serveurs CI commencent à effectuer des opérations de livraison continue. Avec GitOps, Kubernetes ou le cluster gère les déploiements en interne à partir des mises à jour de la branche principale. On parle également de « modèle pull pour la CD ».

Git constitue l’unique source de vérité pour le code, mais aussi pour la configuration et la pile associée. Il devient donc un enjeu de sécurité bien plus important. De nombreuses bonnes pratiques d’hygiène pour votre dépôt de code peuvent vous aider : lancer automatiquement des outils de test comme Snyk sur chaque pull request, créer un fichier SECURITY.MD qui décrit les procédures de sécurité appliquées et utiliser des coffres-forts pour stocker les secrets au lieu de les intégrer au code.

Pour renforcer la sécurité de vos workflows Git ou de vos pipelines CI/CD, testez Snyk gratuitement ! Vous pouvez également réserver une démonstration privée avec notre équipe pour découvrir Snyk en action.