Sécurisation de la Supply Chain et des Images de Conteneurs

0 commentaires

Introduction

La supply chain logicielle est aujourd’hui l’un des vecteurs d’attaques les plus préoccupants en cybersécurité. Kubernetes, en tant que plateforme orchestrant des conteneurs, repose largement sur des pipelines CI/CD, des registres d’images, et des dépendances externes. Chacune de ces étapes peut être compromise si des mesures de sécurité adéquates ne sont pas mises en place.

1.1. Pourquoi la supply chain Kubernetes est une cible ?

Les attaques sur la supply chain Kubernetes sont devenues un enjeu majeur pour les entreprises et les infrastructures cloud-native. Voici quelques raisons expliquant cette tendance :

  • Multiplication des dépendances logicielles : Un cluster Kubernetes repose sur de nombreux composants (images de conteneurs, fichiers YAML, Helm charts, etc.), rendant le système plus vulnérable.
  • Automatisation des déploiements : Les outils de CI/CD accélèrent les déploiements, mais peuvent aussi faciliter la propagation de code malveillant.
  • Confiance excessive dans les registres publics : Beaucoup d’équipes téléchargent des images depuis Docker Hub ou d’autres sources externes, sans vérification.
  • Complexité de Kubernetes : De nombreuses organisations utilisent Kubernetes sans mettre en place les bonnes pratiques de sécurité, laissant des failles exploitables.

1.2. Exemples concrets d’attaques sur la supply chain

🔥 Cas 1 : SolarWinds et l’attaque supply chain la plus marquante

En 2020, l’attaque SolarWinds a montré la puissance des attaques sur la supply chain logicielle. Les hackers ont compromis un build CI/CD pour injecter du code malveillant dans le logiciel Orion. Celui-ci a ensuite été déployé chez des milliers de clients, dont des agences gouvernementales.

🐳 Cas 2 : Docker Hub et la prolifération d’images malveillantes

Des études récentes ont révélé que plusieurs milliers d’images sur Docker Hub contiennent des malwares, cryptominers ou portes dérobées. Par exemple :

  • Une image prétendument « officielle » a été découverte avec un minage de cryptomonnaie intégré.
  • Certaines images contiennent des clés SSH permettant aux attaquants de prendre le contrôle des conteneurs une fois déployés.

🔓 Cas 3 : Compromission d’un pipeline CI/CD

En 2021, un attaquant a compromis un compte GitHub Actions pour injecter du code dans un pipeline CI/CD. Résultat ? Tous les artefacts générés étaient infectés et ont été déployés en production.

1.3. Standards et frameworks de protection

Heureusement, plusieurs frameworks et standards permettent de réduire les risques liés à la supply chain :

  • CIS Kubernetes Benchmark : Définit des règles pour sécuriser les environnements Kubernetes.
  • NIST SP 800-204 : Recommandations sur la sécurité des microservices et conteneurs.
  • SLSA (Supply Chain Levels for Software Artifacts) : Un framework de Google pour évaluer la sécurité d’une supply chain logicielle.
  • Sigstore : Solution de Google permettant la signature et vérification des artefacts logiciels.
  • Notary/Docker Content Trust : Garantit l’intégrité des images Docker.

2. Sécurisation des Registres d’Images

Les registres d’images contiennent des artefacts critiques pour les déploiements Kubernetes. Un registre mal configuré peut permettre :

  • Le vol d’images sensibles contenant des configurations ou des secrets.
  • L’injection d’images malveillantes par des attaquants qui poussent des versions modifiées d’une image légitime.
  • L’exposition d’images obsolètes qui contiennent des vulnérabilités non corrigées.

2.1. Mise en Place d’un Registre Sécurisé

Pour éviter ces risques, il est crucial de sécuriser les registres d’images via des bonnes pratiques :

  1. Utiliser un registre privé plutôt que Docker Hub ou d’autres registres publics.
  2. Activer l’authentification et le contrôle d’accès sur le registre.
  3. Forcer le chiffrement des communications en utilisant TLS.
  4. Restreindre les accès en lecture et en écriture via des politiques RBAC.
  5. Scanner régulièrement les images avant leur utilisation.

👉 Exemple de configuration d’un registre privé avec authentication sur Harbor :

Cela déploie un registre Harbor avec TLS activé et un accès restreint.

2.2. Activation des Politiques de Retention et de Suppression

  • Évitez d’accumuler des images obsolètes qui contiennent des failles.
  • Activez des politiques de rétention pour supprimer automatiquement les images non utilisées après X jours.

👉 Exemple d’activation d’une règle de suppression automatique dans Harbor :

Cela supprime les images de plus de 30 jours.

2.3. Vérification des Images Avant Déploiement

Pour s’assurer qu’aucune image compromise ou non validée n’est utilisée, il est possible d’imposer des politiques de validation dans Kubernetes.

5.3.1. Gatekeeper et OPA pour Refuser les Images Non Signées

Gatekeeper peut être configuré pour refuser les déploiements d’images non vérifiées.

👉 Exemple de policy Gatekeeper interdisant les images provenant de registres non approuvés :

Cela garantit que seules les images provenant de Harbor ou Google Container Registry sont autorisées.

2.4. Signature et Vérification Automatique des Images

Une approche avancée consiste à forcer la signature des images avant leur déploiement.

2.4.1. Intégration de Cosign dans le Pipeline CI/CD

Avec Cosign, il est possible de signer automatiquement les images avant leur push dans le registre.

👉 Exemple d’intégration Cosign dans GitHub Actions :

Ainsi, toute image poussée dans le registre doit être signée avant son utilisation.

3. Monitoring et Audit des Images Utilisées

Même avec toutes ces précautions, il est indispensable de surveiller en continu les images utilisées dans Kubernetes.

3.1. Analyse Automatique des Images Déployées

Des outils comme KubeClarity permettent de scanner en continu les images en cours d’utilisation.

👉 Exemple de déploiement de KubeClarity pour l’analyse en continu des vulnérabilités :

Cela déploie une analyse continue des images exécutées.

3.2. Vérification des Logs pour Détecter les Anomalies

Il est possible d’intégrer un monitoring avancé des logs de registre et des scans de vulnérabilités avec Grafana et Loki.

Nous pouvons réduire drastiquement les risques liés aux images compromises dans Kubernetes.

3. Sécurisation des Dépendances et des Artefacts CI/CD

Un pipeline CI/CD sécurisé doit empêcher l’introduction de dépendances vulnérables et assurer l’intégrité des artefacts générés. Une mauvaise gestion peut entraîner :

  • L’exécution de bibliothèques compromises dans les images de conteneurs.
  • L’altération des fichiers binaires avant leur déploiement.
  • La contamination d’une image propre par du code malveillant injecté en amont.

3.1. Vérification et Filtrage des Dépendances

La plupart des projets Kubernetes utilisent des bibliothèques tierces (frameworks, modules NPM/PyPi, packages Java/Maven, etc.).
Il est impératif d’utiliser des outils d’analyse des dépendances pour détecter les versions vulnérables.

👉 Outils recommandés :

  • Dependabot (GitHub) : Vérifie automatiquement les dépendances et propose des mises à jour.
  • Snyk : Identifie et corrige les failles de sécurité dans les dépendances.
  • Trivy pour fichiers YAML et Helm Charts : Permet d’analyser les fichiers de configuration pour identifier les failles.

👉 Exemple d’activation de Dependabot dans GitHub :


Cela force la mise à jour quotidienne des dépendances NPM pour éviter l’usage de versions vulnérables.

3.2. Sécurisation des Artefacts Générés

Les artefacts produits (images Docker, fichiers Helm, binaires compilés) peuvent être modifiés avant leur déploiement si leur intégrité n’est pas vérifiée.

3.2.1. Utilisation des Checksums et Signatures

Chaque artefact doit être signé et vérifié avant utilisation.

👉 Exemple de vérification d’un binaire avec sha256sum :

Cela garantit que le binaire n’a pas été altéré entre la phase de build et la phase de déploiement.

3.2.2. Notary v2 pour Signer et Vérifier les Artefacts

Notary v2 permet d’assurer que seuls des artefacts signés peuvent être déployés.

👉 Exemple d’intégration avec Docker :

Ainsi, toute tentative de déploiement d’une image non signée sera bloquée.

3.3. Sécurisation des Pipelines CI/CD

Les pipelines Jenkins, GitHub Actions, GitLab CI/CD ou ArgoCD sont souvent des cibles privilégiées. Voici les bonnes pratiques :

  1. Limiter l’accès aux secrets : Stocker les credentials dans un Vault sécurisé.
  2. Restreindre les permissions des runners CI/CD : Utiliser des identités temporaires plutôt que des accès permanents.
  3. Exécuter les pipelines dans des environnements isolés : Éviter les exécutions en mode root.

👉 Exemple : Ajout d’un GitHub Secret pour un pipeline sécurisé

Cela garantit que les secrets ne sont pas exposés en clair dans les logs.

3.4. Vérification des Déploiements en Continu

Une dernière couche de protection consiste à vérifier en temps réel que les images et artefacts déployés respectent les standards de sécurité.

👉 Outils recommandés :

  • Kyverno : Vérifie les politiques de conformité des pods Kubernetes.
  • TUF (The Update Framework) : Permet de garantir l’intégrité des artefacts déployés.

4. Détection et Remédiation des Anomalies dans la Supply Chain Kubernetes

Même avec des images signées, des pipelines sécurisés et des artefacts protégés, il est essentiel de détecter et remédier aux menaces en temps réel. Une compromission peut survenir via un déploiement frauduleux, une modification des artefacts ou une exécution d’un conteneur suspect.

4.1. Surveillance Continue avec des Outils de Détection

Il est indispensable d’avoir une surveillance active des registres d’images, des pipelines CI/CD et des pods exécutés dans Kubernetes.
👉 Outils recommandés :

  • Falco : Détecte des comportements anormaux au niveau des pods.
  • Sysdig Secure : Surveille les actions malveillantes dans les conteneurs.
  • KubeClarity : Analyse les images et les dépendances déployées.

4.1.1. Mise en Place de Falco pour la Détection des Anomalies

Falco est un outil open-source permettant de détecter des comportements suspects dans Kubernetes.

👉 Exemple de détection d’un processus anormal dans un conteneur :


👉 Déploiement rapide de Falco sur Kubernetes :

Cela permet de surveiller en continu les activités suspectes dans les pods.

4.2. Protection en Temps Réel avec Kyverno et Gatekeeper

Pour empêcher les déploiements non sécurisés, il est possible d’utiliser des policies en temps réel avec Kyverno ou OPA Gatekeeper.

4.2.1. Blocage des Images Non Vérifiées avec Kyverno

Kyverno permet de forcer la vérification des signatures d’images avant déploiement.

👉 Exemple de policy Kyverno refusant les images non signées :

👉 Ce que cela fait :

  • Bloque toute image non signée avant son exécution.
  • Applique une validation stricte des images utilisées.

4.3. Audit des Logs pour Identifier les Tentatives de Compromission

L’analyse des logs est essentielle pour détecter des attaques potentielles sur la supply chain.
👉 Outils recommandés :

  • Loki + Grafana : Centralisation et analyse des logs Kubernetes.
  • Elastic Stack (ELK) : Recherche et détection d’anomalies.
  • Audit2RBAC : Analyse des logs d’accès pour affiner les permissions RBAC.

4.3.1. Exemple de Surveillance avec Loki et Grafana

Loki collecte les logs des conteneurs et permet de détecter les tentatives de compromission.

👉 Installation rapide de Loki sur Kubernetes :

👉 Exemple de requête Loki pour détecter une exécution suspecte de kubectl exec :

Cela permet de repérer les tentatives d’exécution interactive dans un pod.

4.4. Réaction Automatisée aux Anomalies

Une fois qu’une menace est détectée, il est crucial d’agir rapidement.

👉 Actions possibles :

  • Supprimer immédiatement le pod suspect (kubectl delete pod <nom-du-pod>).
  • Bloquer un registre compromis via OPA Gatekeeper ou Kyverno.
  • Notifier une équipe de sécurité avec Prometheus Alertmanager.

4.4.1. Exemple d’Alerte Automatisée avec Alertmanager

Si un événement suspect est détecté, il est possible d’envoyer une alerte automatique.

👉 Exemple de configuration Alertmanager envoyant une alerte sur Slack :


Cela prévient immédiatement l’équipe de sécurité lorsqu’un comportement anormal est repéré.

5. Gestion des Clés et Secrets dans la Supply Chain Kubernetes

Les clés et secrets jouent un rôle essentiel dans la sécurité des pipelines CI/CD, des registres d’images et des applications Kubernetes. Une mauvaise gestion peut entraîner :

  • La fuite de credentials sensibles dans les registres publics ou dans le code source.
  • L’utilisation de clés non sécurisées pour signer les images.
  • Un accès non contrôlé aux ressources Kubernetes via des tokens exposés.

Dans cette section, nous allons voir comment sécuriser la gestion des clés et secrets dans la supply chain Kubernetes.

5.1. Risques liés à la Gestion des Secrets dans CI/CD

Les secrets Kubernetes et les credentials API sont souvent exposés accidentellement. Voici les erreurs courantes :

  • Stockage de secrets en clair dans les fichiers de configuration YAML.
  • Stockage des clés d’authentification dans un dépôt Git.
  • Partage non sécurisé des tokens d’accès entre services.
  • Utilisation de secrets statiques sans rotation automatique.

👉 Cas réel d’une fuite de clé AWS : Un développeur a commis accidentellement sa clé AWS dans un dépôt public sur GitHub. En quelques minutes, des attaquants ont utilisé cette clé pour démarrer des centaines d’instances EC2 pour du minage de cryptomonnaie.

5.2. Sécurisation des Secrets avec Kubernetes et Vault

Une bonne gestion des secrets repose sur 3 principes fondamentaux :

  1. Ne jamais stocker les secrets en clair dans les fichiers YAML.
  2. Utiliser une solution centralisée pour gérer les credentials.
  3. Appliquer des mécanismes de rotation automatique des secrets.

5.2.1. Utilisation de Kubernetes Secrets

Kubernetes propose nativement un mécanisme de gestion des secrets.

👉 Exemple de création d’un secret Kubernetes :

kubectl create secret generic db-credentials --from-literal=username=admin --from-literal=password=securepassword

Cela crée un secret encodé en base64, mais non chiffré par défaut.

5.2.2. Utilisation de HashiCorp Vault pour la Gestion Dynamique des Secrets

Vault permet de générer et stocker les secrets de manière sécurisée et évite leur stockage dans Kubernetes.

👉 Exemple d’intégration de Vault avec Kubernetes :

Ce secret expire après une heure, ce qui empêche son exploitation prolongée.

5.2.3. Automatisation de la Rotation des Secrets

Un bon système de gestion de secrets doit permettre :

  • Une rotation automatique des credentials après une période définie.
  • L’accès temporaire aux secrets avec expiration automatique.
  • L’utilisation de permissions fines pour restreindre l’accès aux secrets.

👉 Exemple de policy Vault pour restreindre l’accès à un secret :


Cela empêche toute modification accidentelle des credentials.

5.3. Sécurisation des Clés de Signature d’Images

Les clés utilisées pour signer les images (Cosign, Notary) doivent être protégées contre le vol et la fuite accidentelle.

5.3.1. Stockage Sécurisé des Clés avec KMS (Key Management Service)

Il est recommandé d’utiliser un KMS (AWS KMS, Google Cloud KMS, HashiCorp Vault) pour stocker les clés de signature.

👉 Exemple d’utilisation d’AWS KMS pour signer une image avec Cosign :

Cela empêche le stockage local de la clé privée.

5.3.2. Restriction des Permissions sur les Clés de Signature

Les clés privées de signature ne doivent être accessibles qu’aux pipelines CI/CD et non aux développeurs.

👉 Exemple de policy IAM restreignant l’accès aux clés KMS :

Cette règle bloque l’accès à la clé pour tout utilisateur hors pipeline CI/CD.

5.4. Protection des Secrets dans les Registres d’Images

Les registres d’images nécessitent des credentials pour pousser et tirer des images. Une mauvaise gestion peut entraîner :

  • L’exfiltration des tokens de connexion au registre.
  • L’exploitation d’images non sécurisées via un accès non contrôlé.

5.4.1. Utilisation des Tokens de Courte Durée

Plutôt que d’utiliser un token statique, il est recommandé d’utiliser des tokens à durée limitée.

👉 Exemple de génération d’un token temporaire sur Harbor :

Cela génère un token valide seulement 1 heure.

5.4.2. Restreindre l’Accès aux Registres d’Images

Les accès aux registres doivent être limités à des utilisateurs et services précis.

👉 Exemple de configuration Harbor pour n’autoriser que des utilisateurs validés :

Cela empêche l’accès non autorisé aux images.

5.5. Détection des Fuites de Secrets

Malgré toutes les précautions, il peut arriver qu’un secret fuite accidentellement dans un dépôt Git ou un fichier public.

5.5.1. Scan des Dépôts Git pour Détecter les Secrets

Des outils comme GitLeaks et TruffleHog permettent d’identifier les secrets exposés dans le code source.

👉 Exemple d’exécution de GitLeaks sur un projet GitHub :

Cela scanne le dépôt pour détecter toute fuite de credential.

5.5.2. Révocation Immédiate des Secrets Fuités

Si un secret a fuité, il faut immédiatement :

  1. Révoquer l’accès du token exposé.
  2. Générer une nouvelle clé ou un nouveau secret.
  3. Analyser les logs pour détecter d’éventuels accès non autorisés.

6. Meilleures Pratiques et Stratégies pour une Supply Chain Sécurisée

Nous avons exploré en détail les différents aspects de la sécurisation de la supply chain Kubernetes :
✅ Signature et validation des images
✅ Sécurisation des registres et artefacts
✅ Protection des pipelines CI/CD
✅ Détection et remédiation des anomalies
✅ Gestion des clés et secrets

Dans cette dernière section, nous allons voir comment assembler toutes ces pratiques en une stratégie cohérente et mettre en place une politique de sécurité robuste.

6.1. Approche Globale de Sécurisation de la Supply Chain Kubernetes

Une supply chain sécurisée repose sur trois piliers fondamentaux :

  1. Prévention 🔒
    • Éviter les erreurs de configuration et les fuites de secrets.
    • Restreindre l’accès aux ressources critiques.
    • Signer et vérifier systématiquement les images et artefacts.
  2. Détection 👀
    • Surveiller en continu les déploiements et les images utilisées.
    • Utiliser des outils comme Falco, Kyverno et Loki pour détecter les anomalies.
    • Auditer régulièrement les pipelines CI/CD et les accès.
  3. Remédiation 🔧
    • Agir immédiatement en cas de compromission.
    • Révoquer et régénérer les secrets exposés.
    • Appliquer des correctifs de sécurité dès qu’une vulnérabilité est détectée.

6.2. Checklist des Bonnes Pratiques

Voici une checklist récapitulative pour garantir la sécurité de votre supply chain Kubernetes :

Sécurisation des Images et Registres ✅

☑️ Utiliser un registre privé sécurisé (Harbor, AWS ECR, GCR).
☑️ Activer l’authentification et les permissions d’accès (RBAC).
☑️ Signer toutes les images avec Cosign ou Notary v2.
☑️ Scanner toutes les images avant déploiement avec Trivy ou Grype.
☑️ Appliquer des politiques de rétention et suppression des images obsolètes.

Sécurisation des Pipelines CI/CD 🛠️

☑️ Ne jamais stocker les secrets en clair dans les fichiers YAML ou Git.
☑️ Utiliser HashiCorp Vault ou un KMS pour gérer les clés API et tokens.
☑️ Vérifier l’intégrité des artefacts générés avec des checksums.
☑️ Appliquer des règles OPA/Gatekeeper pour refuser les images non signées.
☑️ Restreindre l’exécution des pipelines CI/CD dans des environnements isolés.

Surveillance et Détection 🔍

☑️ Déployer Falco pour détecter les anomalies en temps réel.
☑️ Analyser les logs Kubernetes avec Loki + Grafana.
☑️ Mettre en place des alertes via Prometheus Alertmanager.
☑️ Scanner régulièrement les dépendances avec Dependabot/Snyk.
☑️ Auditer les permissions RBAC avec Audit2RBAC.

Réaction et Remédiation 🚨

☑️ En cas de fuite d’un secret, révoquer et régénérer immédiatement.
☑️ Supprimer et recréer les images compromises.
☑️ Isoler et stopper tout pod suspect exécutant une commande anormale.
☑️ Appliquer les correctifs de sécurité sur les images vulnérables.

6.3. Mise en Place d’une Stratégie DevSecOps

L’adoption d’une approche DevSecOps permet d’intégrer la sécurité dès la phase de développement et tout au long du cycle de vie des applications Kubernetes.

6.3.1. Intégration de la Sécurité dans le Pipeline CI/CD

👉 Exemple d’un pipeline CI/CD sécurisé sur GitHub Actions :


🔹 Ce pipeline :
✔️ Vérifie les vulnérabilités des dépendances.
✔️ Analyse l’image avant son déploiement.
✔️ Signe l’image avant de la pousser vers le registre.

6.3.2. Automatisation des Politiques de Sécurité

L’utilisation d’outils comme Kyverno ou OPA Gatekeeper permet de faire respecter automatiquement les règles de sécurité.

👉 Exemple : Interdiction des conteneurs exécutés en mode root avec Kyverno :


🔹 Avantages :
✔️ Bloque automatiquement les conteneurs avec accès root.
✔️ Renforce la sécurité des workloads Kubernetes.

6.4. Résumé et Perspectives

La sécurisation de la supply chain Kubernetes doit être intégrée dans l’ensemble du cycle de vie des applications.

Récapitulatif des points clés

✅ Sécuriser les images et registres en limitant les accès et en forçant la signature.
✅ Protéger les pipelines CI/CD en supprimant les secrets en clair et en validant les artefacts.
✅ Mettre en place une détection avancée avec Falco et Loki pour surveiller les anomalies.
✅ Automatiser les politiques de sécurité avec Kyverno et Gatekeeper.
✅ Adopter une approche DevSecOps pour sécuriser dès le développement.

Vers une Supply Chain Kubernetes Résiliente

L’évolution des attaques montre que les chaînes d’approvisionnement logicielles sont des cibles de plus en plus privilégiées. Une organisation qui anticipe et automatise la sécurité dans Kubernetes réduit drastiquement son risque d’exposition.

En appliquant ces bonnes pratiques, vous serez en mesure de détecter, prévenir et remédier aux menaces affectant votre supply chain Kubernetes.