Aider à sécuriser les chaînes d'approvisionnement logicielles sur Google Kubernetes Engine

Cet article explique comment garantir que votre chaîne d'approvisionnement logicielle suive un chemin connu et sécurisé avant le déploiement de votre code dans un cluster Google Kubernetes Engine (GKE). Vous y trouverez une description du fonctionnement de l'autorisation binaire, puis découvrirez comment mettre cette autorisation en œuvre et l'utiliser de façon optimale avec Google Cloud, afin de garantir que votre pipeline de déploiement fournisse un maximum d'informations pour vous aider à appliquer les approbations à chacune des étapes requises.

Les rapports sur l'état du DevOps identifient les fonctionnalités qui améliorent les performances de livraison de logiciels. Cet article vous aidera dans la mise en place des capacités suivantes :

Composants fondamentaux de la sécurisation de votre chaîne d'approvisionnement logicielle

Lorsque vous créez et déployez des applications conteneurisées, en guise d'unité de déploiement, vous devez utiliser des artefacts immuables, qui vous permettent de déployer et de faire évoluer votre logiciel sur de nombreux hôtes et environnements, en sachant qu'il se comportera comme prévu.

Après avoir créé les artefacts immuables, placez-les dans un magasin d'artefacts où ils peuvent être versionnés et catalogués pour une utilisation ultérieure.

À différentes étapes de votre processus de publication, des personnes ou des systèmes automatisés peuvent ajouter des métadonnées décrivant le résultat d'une activité, ce qui équivaudrait à la signalisation d'un point de contrôle. Par exemple, vous pouvez ajouter à une image des métadonnées indiquant qu'elle a réussi une suite de tests d'intégration.

Une fois que vos artefacts comportent des métadonnées, vous pouvez créer une stratégie de déploiement définissant les validations à passer avant de pouvoir les déployer dans votre infrastructure. Dans votre infrastructure, créez un mécanisme visant à valider qu'une charge de travail passe de façon satisfaisante tous les points de contrôle requis avant son admission. Ce type de validation, effectué juste avant que le code ne soit configuré pour être exécuté, garantit qu'aucun déploiement n'ignore les étapes requises de votre flux.

Le schéma suivant illustre un processus général concernant la gestion de chaîne d'approvisionnement logicielle.

processus de gestion de chaîne d'approvisionnement logicielle

Sécuriser des chaînes d'approvisionnement dans GKE

Le tableau suivant met en correspondance les composants fondamentaux de la chaîne d'approvisionnement et les fonctionnalités de Google Cloud.

Composant fondamental Mise en œuvre dans Google Cloud
Artefact immuable Image Docker
Magasin d'artefacts Container Registry
Métadonnées d'artefacts Note
Auditeurs d'artefacts Certificateurs
Validations d'artefacts Attestations
Stratégie de déploiement Stratégie d'autorisation binaire

L'artefact immuable GKE que vous déployez est une image Docker. Cette image est générée une fois, puis transmise à Container Registry, le magasin d'artefacts, où vous pouvez la déployer sur le nombre de clusters GKE que vous souhaitez.

Dans Container Registry, vous ajoutez des informations à propos des images à l'aide de tags, qui représentent une seule métadonnée. La plupart du temps, les tags Docker sont utilisés sur les images pour indiquer la version du logiciel ou un train de versions, tel que v2.0.0 ou beta. Bien que ces informations soient utiles, vous ne pouvez pas utiliser de tags pour ajouter des détails concernant l'artefact, tels que son origine, son code source ou son approbation pour un déploiement dans des environnements de production. Pour cela, vous devez utiliser des attestations.

Les certificateurs peuvent indiquer si une image répond à un critère particulier en ajoutant des notes au sujet des images dans Container Registry. Ces informations peuvent être consultées tout au long du cycle de vie de l'image. Certains genres de notes sont classés pour vous permettre de mieux filtrer les informations relatives à vos images. L'attestation est un genre de note, qui est ajouté par des certificateurs faisant partie de votre projet. Par exemple, vous pouvez avoir un certificateur qui valide que les images sont créées sans failles de sécurité critiques ou qu'une image a été créée par un système de compilation particulier.

Pour ajouter un certificateur à votre projet, vous devez importer une clé publique PGP (Pretty Good Privacy) associée afin de créer et d'identifier votre certificateur. Les certificateurs peuvent ensuite créer des attestations en signant des messages identifiant les condensés spécifiques d'images adressables par le contenu qu'ils attestent.

Le schéma suivant illustre un exemple d’ajout d’une attestation à une image pour un condensé particulier.

ajout d'une attestation à une image

L'autorisation binaire vous permet de configurer une stratégie qui définit les attestations devant figurer sur votre image avant son déploiement sur vos clusters. Cette stratégie crée un composant fondamental permettant de s'assurer que vos images suivent le bon chemin dans votre pipeline de déploiement, sans ignorer aucune étape importante. À chacune des étapes critiques de votre pipeline de déploiement, vous pouvez créer une attestation indiquant que l'image a réussi cette étape. Les attestations peuvent être ajoutées par des systèmes automatisés ou par des personnes.

Par exemple, vous pouvez vous assurer que votre image a été validée par votre équipe de contrôle qualité (QA). Une fois les tests terminés, l'un des membres de l'équipe de QA utilise une clé spécifique pour signer une attestation du certificateur qa-validated. Cette attestation est requise pour que vos clusters de production déploient l'image.

De même, vous pouvez aussi vous assurer que votre image a été analysée à la recherche d'éventuelles failles et qu'aucune anomalie n'a été détectée. Un système automatisé pourrait surveiller l'apparition de nouvelles images dans votre dépôt et ajouter une attestation indiquant qu'elles répondent à une certaine norme en matière de failles. Une fois que le système a validé l'analyse de failles, il peut signer et ajouter une attestation du certificateur not-vulnerable à l'aide de sa clé cryptographique. Vous pouvez chiffrer cette clé avec Cloud Key Management Service, la stocker de manière sécurisée dans Cloud Storage, en contrôler les accès via Identity and Access Management et en auditer l'utilisation via Cloud Logging.

Le schéma suivant montre des images contenues dans Container Registry et comportant des attestations ajoutées par des personnes ainsi que des certificateurs automatisés.

images de Container Registry ajoutées de façon automatique ou par des personnes

L'autorisation binaire vous permet de créer des stratégies qui définissent les clés cryptographiques que vous pouvez utiliser pour valider chacune de vos attestations. Vous pouvez également ajouter certaines images à la liste d'autorisations allowlist afin de contourner la validation d'attestation, ou encore désactiver l'autorisation binaire pour certains clusters.

Même si Google Cloud propose des services gérés pour créer et gérer votre chaîne d'approvisionnement logicielle, vous pouvez également utiliser des mises en œuvre Open Source pour établir des processus similaires dans d'autres environnements.

Le tableau suivant met en correspondance les services Google Cloud et les outils Open Source offrant des fonctionnalités similaires.

Google Cloud Outil Open Source
Container Registry Distribution Docker
API de métadonnées Grafeas
Autorisation binaire Kritis
Analyse des failles Clair, Anchore Engine

Bonnes pratiques en matière de pipeline de diffusion continue

L'efficacité de la validation de votre chaîne d'approvisionnement logicielle est optimale si vous disposez d'un pipeline de diffusion continue qui a recours à l'automatisation pour déployer le code source d'un dépôt de code sur votre infrastructure de production. Les étapes de ces pipelines varient selon les organisations, mais vous pouvez mettre en œuvre des bonnes pratiques de haut niveau pour vous assurer que votre pipeline déploie votre logiciel en toute sécurité.

Conseils d'ordre général concernant le pipeline CI/CD

De nombreuses entreprises permettent à leurs équipes de choisir leur propre processus de livraison continue et leurs propres outils. Bien que cette flexibilité puisse favoriser l'autonomie et permettre aux équipes d'utiliser des outils habituels, elle peut compliquer la tâche visant à garantir que toutes les versions respectent les bonnes pratiques. Vous pouvez centraliser les pipelines de versions des équipes dans un outil tel que Spinnaker, qui vous aide à créer des modèles, à partager et à auditer des méthodologies à un même endroit.

Créer des images

Comme dans toute chaîne d'approvisionnement, le degré de sécurité de votre logiciel dépend du matériel que vous utilisez pour créer vos artefacts exécutables. Lorsque vous utilisez GKE, vous devez vous assurer que les images que vous créez proviennent d'images de base sécurisées.

La première étape pour maximiser la sécurité de vos images de base consiste à utiliser une distribution minimale, qui ne comprend que le logiciel et les bibliothèques nécessaires à l'exécution de votre application. Pour les distributions courantes, telles que Ubuntu, Debian et CentOS, Google Cloud propose des images de base gérées régulièrement mises à jour avec des correctifs de sécurité. Les images Distroless constituent un ensemble d'images de base qui ne comprennent que les bibliothèques et les outils nécessaires à l'exécution d'applications écrites dans divers langages de programmation. Après avoir choisi une base, essayez de minimiser ce que vous ajoutez. Vous pouvez exploiter les créations en plusieurs étapes de Docker pour séparer les dépendances de durée de compilation des dépendances d'environnement d'exécution, ce qui réduit la surface d'attaque.

Une fois l'image créée, assurez-vous qu'elle est conforme aux règles de votre entreprise. Vous pouvez créer des tests container-structure-test qui valident le contenu et les métadonnées de l'image. Vous pouvez également utiliser container-diff pour comparer les conteneurs existants et les nouveaux.

Lorsque vous avez réduit le contenu de l'image de votre application, essayez de vérifier et de réduire la portée des images tierces autorisées dans vos clusters. Vous pouvez utiliser l'autorisation binaire pour ajouter les images à la liste d'autorisations allowlist, qui peut contourner vos exigences d'attestation. Assurez-vous que l'entrée de la liste allowlist est aussi spécifique que possible pour chacune des images dont vous avez besoin, sans pour autant permettre une compilation via votre pipeline de création d'artefacts.

Pour en savoir plus sur la création de conteneurs, consultez la documentation Bonnes pratiques pour la création de conteneurs.

Activer l'analyse de failles des images

Activez l'analyse des failles de Container Registry dans vos projets pour obtenir plus d'informations sur les problèmes de sécurité potentiels dans vos images Docker. Les analyses automatisées exécutées dès que vos images sont transférées peuvent vous aider à comprendre la gravité des failles que peuvent comporter vos images. Bien que vous deviez vérifier l'éventuelle présence de failles avant le déploiement, vous devez également examiner vos images après leur déploiement, car de nouvelles failles pourraient être détectées. L'analyse des failles examine en permanence les images extraites du registre au cours des 30 derniers jours. Vous pouvez utiliser Pub/Sub pour obtenir des notifications lorsque des failles sont détectées dans vos images.

Valider votre stratégie lors du déploiement

Pour sécuriser votre chaîne d'approvisionnement logicielle, activez la validation des images lors du déploiement. Le déploiement, dernière étape d'un pipeline de diffusion continue, est un bon moment pour vous assurer que votre processus inclut toutes les étapes et a passé tous les points de contrôle. En adoptant cette approche, même si une personne obtenait l'accès aux identifiants de vos clusters, elle ne pourrait pas déployer d'images malveillantes.

Avec l'autorisation binaire, vous pouvez configurer une règle par défaut pour tous les clusters du projet, puis remplacer ces règles par des configurations spécifiques à un cluster. Par exemple, vous pouvez vouloir que tous vos clusters requièrent des attestations d'analyse de failles et de validation de QA, tout en vous assurant que les développeurs puissent essayer de nouvelles technologies et images dans le cluster development, sans avoir à passer la validation de QA. Pour en savoir plus sur les stratégies d'autorisation binaire, consultez la documentation de référence sur les règles YAML.

Exemple de pipeline

Voici un exemple de pipeline divisé en deux phases principales : création et déploiement.

exemple de pipeline avec une phase de création et une phase de déploiement

Le tableau ci-dessous donne davantage de détails sur les étapes du pipeline et les points d'ajout des attestations.

Numéro d'étape Résumé Description Icône
d'attestation
1 Obtenir le code source Vérifiez le code source au niveau de la révision à utiliser par le système de création. Aucune
2 Exécuter des tests unitaires Assurez-vous que le code réussit tous les tests unitaires avant de créer un artefact.

Exécuter des tests unitaires

3 Créer une image Docker Utilisez le Dockerfile dans le code source local pour créer une image pouvant être transférée vers le Registry Container. Aucune
4 Vérifier que l'image Docker est conforme à la stratégie Les tests container-structure-test vous permettent de valider le contenu de votre image et de vérifier que ses commandes renvoient le bon résultat.

Vérifier que l'image Docker est conforme à la stratégie

5 Transférer une image dans Container Registry Lorsque le code a passé des tests unitaires et que le contenu de votre image a été validé, vous pouvez transférer l'image dans Container Registry. Une analyse de failles est lancée automatiquement. Aucune
6 Vérifier que l'image ne présente pas de failles critiques L'analyse des failles prend quelques minutes, puis ajoute des notes aux métadonnées de l'image concernant les failles et expositions communes (CVE) qui apparaissent. Attendez que ces données s'affichent, puis ajoutez une attestation si aucune faille critique n'a été détectée.

Vérifier que l'image ne présente pas de failles critiques

7 Déployer l'image en préproduction Lancez un déploiement dans un environnement de préproduction, où votre changement peut être validé et observé dans des scénarios aussi proches que possible de l'environnement de production.

Déployer l'image en préproduction

8 Approuver le code pour son déploiement en production Si tous les signaux indiquent que le changement satisfait aux exigences, approuvez son déploiement en production. Aucune
9 Déployer le code dans les clusters de production Vous pouvez maintenant configurer l'image pour qu'elle se mette à jour sur l'ensemble de vos clusters. Chaque cluster vérifie que toutes les attestations sont complètes avant d'exécuter votre application. Aucune

Exemple d'attestations

Voici certaines des attestations que vous pourriez inclure dans votre pipeline de versions :

  • Les résultats de l'analyse de failles n'incluaient pas de failles critiques.
  • La validation de QA manuelle est réussie.
  • Tous les logiciels inclus dans l'image bénéficient d'une licence appropriée.
  • L'artefact a été créé dans un système de création de confiance.

Étapes suivantes