Protéger les déploiements

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Ce document décrit les bonnes pratiques à adopter pour protéger vos déploiements.

Créer et appliquer des règles de déploiement

Pour protéger vos environnements d'exécution, définissez des règles avec des critères de déploiement et validez la conformité des règles avant et après le déploiement. Définir une stratégie n'autorisant que le code signé par des certificateurs prédéfinis permet de contrôler les déploiements et de déployer uniquement du code provenant d'origines de confiance.

Exemples de critères de déploiement:

  • Aucune faille connue avec une gravité supérieure à moyenne
  • Le code source provient d'un dépôt source approuvé
  • Un service de compilation fiable a exécuté la compilation
  • Les artefacts de compilation que vous déployez proviennent d'un dépôt d'artefacts de confiance

Générer des métadonnées

Pour valider ces exigences, vous devez fournir des métadonnées sur vos artefacts de compilation.

Origines de la compilation

La origine de la compilation est une collection de données vérifiables sur une compilation, telles que les condensés des images de compilation, les emplacements des sources d'entrée, la chaîne d'outils de la compilation et la durée de la compilation. SLSA, un framework permettant d'évaluer le niveau de sécurité, fournit un modèle de provenance et des exigences de provenance. La provenance est une catégorie d'exigences dans le framework. Chaque exigence est associée à des niveaux d'authentification SLSA afin que vous puissiez implémenter progressivement les mesures d'atténuation.

  • Pour les garanties de niveau 1, la provenance doit être disponible.
  • Pour obtenir l'assurance SLSA de niveau 2, la provenance doit être générée, et les consommateurs doivent pouvoir en vérifier l'authenticité et l'intégrité.
  • Les niveaux 3 et 4 sont plus stricts pour la signature de provenance et pour les détails de la profondeur de provenance.

Certains services de compilation génèrent des métadonnées de provenance de compilation.

vulnérabilités

Un logiciel d'analyse des failles vérifie votre code source et génère des artefacts pour détecter les failles connues. Container Analysis peut analyser automatiquement les images de conteneurs transférées vers Artifact Registry pour détecter les failles. Pour rechercher les failles dans les artefacts avant de les stocker, vous pouvez utiliser l'API On-Demand Scanning dans un environnement de développement local ou dans un pipeline CI/CD, comme une étape de compilation Cloud Build.

Configurer l'application des règles

Une fois que vous disposez de métadonnées sur vos artefacts déployables, vous avez besoin d'outils pour appliquer vos stratégies.

Dans Google Cloud, vous pouvez configurer une stratégie dans l'autorisation binaire pour vos déploiements. L'autorisation binaire applique la stratégie pour les tentatives de déploiement sur les plates-formes compatibles basées sur des conteneurs. Il peut également effectuer une validation continue des règles pour les charges de travail exécutées sur GKE, Cloud Run et Anthos.

Les vérifications de prédéploiement peuvent bloquer toutes les images qui ne figurent pas dans la liste d'images exemptées, afin que seules les images de confiance soient déployées à partir de registres de confiance. Votre stratégie peut également exiger des attestations, des documents numériques qui indiquent que l'image a bien été créée avec un processus spécifique requis. Par exemple, une attestation peut indiquer qu'une image est:

La validation continue étend la validation des stratégies à l'environnement post-déploiement. Lorsqu'elle est activée, l'autorisation binaire assure la validation tout au long du cycle de vie du pod en consignant régulièrement la conformité avec la règle dans Cloud Logging. Cette fonctionnalité est utile dans de nombreuses situations. Par exemple, si vous modifiez votre stratégie après avoir déployé un conteneur, la validation continue consigne les pods qui ne respectent pas la stratégie mise à jour. Il consigne également les cas de non-respect des règles pour les pods déployés avec une simulation ou un bris de glace.

Utiliser des services de déploiement verrouillé

Le contrôle du déploiement vous permet d'approuver ou de refuser des déploiements à des étapes spécifiques du processus de déploiement à l'aide d'un service CI/CD autonome ou d'un service CI/CD intégré à un système d'automatisation des processus. Les déploiements avec formulaire empêchent les utilisateurs non autorisés de modifier les environnements d'application. Elles offrent une surveillance supplémentaire du processus de déploiement et une plus grande visibilité des approbations.

Dans Google Cloud, Google Cloud Deploy offre un service entièrement géré pour le déploiement de charges de travail sur Google Kubernetes Engine. La fonctionnalité de déploiement verrouillé permet aux utilisateurs de spécifier si une approbation est nécessaire pour promouvoir une cible.

Surveiller vos charges de travail

Les charges de travail sont des applications qui s'exécutent sur des plates-formes basées sur des conteneurs, telles que GKE et Cloud Run. Idéalement, les charges de travail que vous déployez doivent disposer d'une configuration renforcée qui limite leur surface d'attaque.

Il peut être difficile de vérifier manuellement les problèmes de configuration des charges de travail sur plusieurs clusters à grande échelle. Software Delivery Shield est une solution de sécurité de la chaîne d'approvisionnement logicielle entièrement gérée sur Google Cloud qui fournit des tableaux de bord dans Cloud Run et l'interface utilisateur de GKE dans Google Cloud Console pour afficher les insights de sécurité des charges de travail.

Le tableau de bord de sécurité de GKE vous fournit des conseils pour renforcer la stratégie de sécurité de vos clusters en fonction des recommandations de Google. Elle inclut l'analyse automatique de la configuration des charges de travail, qui recherche les problèmes de configuration connus dans toutes les charges de travail. GKE vérifie chaque charge de travail déployée pour s'assurer qu'elle respecte les bonnes pratiques du secteur, telles que les règles définies dans les normes de sécurité des pods. GKE évalue la gravité des problèmes détectés et renvoie des recommandations et des journaux exploitables. Vous pouvez utiliser Cloud Logging pour obtenir une piste de préoccupations vérifiable afin d'améliorer la création de rapports et l'observabilité. Pour savoir comment afficher des insights de sécurité dans le tableau de bord de sécurité de GKE, consultez la page Déployer sur GKE et afficher les insights de sécurité.

Cloud Run contient un panneau de sécurité qui affiche des insights sur la sécurité de la chaîne d'approvisionnement logicielle, tels que les informations de conformité au niveau de la compilation SLSA, la provenance de la compilation et les failles détectées dans les services en cours d'exécution. Pour savoir comment afficher des insights de sécurité dans le panneau des insights de sécurité Cloud Run, consultez la page Déployer sur Cloud Run et afficher les insights sur la sécurité.

Software Delivery Shield propose également d'autres services et fonctionnalités permettant d'améliorer votre stratégie de sécurité tout au long du cycle de vie du développement logiciel. Pour en savoir plus, consultez la page Présentation de Software Delivery Shield.

Étapes suivantes