Ce document décrit les bonnes pratiques à suivre 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é avec les règles avant et après le déploiement. La définition d'une stratégie qui n'autorise 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.
Voici quelques exemples de critères de déploiement:
- Aucune faille connue avec un niveau de gravité supérieur à Moyenne
- Le code source provient d'un dépôt source de confiance
- Un service de compilation de confiance 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 concernant une compilation, telles que les condensés des images compilées, l'emplacement des sources d'entrée, la chaîne d'outils de 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 l'une des catégories d'exigences dans le framework. Chaque exigence est associée à des niveaux SLSA afin que vous puissiez mettre en œuvre progressivement des mesures d'atténuation.
- Pour l'assurance SLSA de niveau 1, la provenance doit être disponible.
- Pour l'assurance SLSA de niveau 2, la provenance doit être générée, et les consommateurs doivent pouvoir vérifier son authenticité et son intégrité.
- Les niveaux SLSA 3 et 4 du framework SLSA présentent des exigences plus strictes en termes de signature de la provenance et de profondeur de détail des données de provenance.
Certains services de compilation génèrent des métadonnées de provenance de compilation.
- Dans Google Cloud, Cloud Build génère et signe la provenance de la compilation pour les images de conteneurs compatibles avec les compilations SLSA de niveau 3.
- Le framework SLSA fournit un outil de provenance GitHub. Les outils génèrent une provenance SLSA non falsifiable sur GitHub qui répond aux exigences des catégories build et provenance pour le niveau SLSA 3.
- Le projet Open Source sigstore inclut l'outil cosign pour signer les conteneurs.
- Failles
Un logiciel d'analyse des failles vérifie votre code source et génère des artefacts pour détecter les failles connues. Artifact Analysis peut analyser automatiquement les images de conteneur transférées vers Artifact Registry afin de détecter d'éventuelles 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, par exemple 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 règles.
Dans Google Cloud, vous pouvez configurer une stratégie pour vos déploiements via l'autorisation binaire. L'autorisation binaire applique une stratégie pour les tentatives de déploiement sur des plates-formes compatibles basées sur des conteneurs. Il peut également effectuer une validation continue de la stratégie pour les charges de travail exécutées sur GKE, Cloud Run et GKE Enterprise.
Les vérifications pré-déploiement peuvent bloquer toutes les images qui ne figurent pas dans la liste des 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 indiquant que l'image a été créée avec succès avec un processus spécifique et requis. Par exemple, une attestation peut indiquer qu'une image:
- Conçu par Cloud Build.
- Ne contient pas de failles au-delà d'un niveau de gravité spécifié. Si des failles spécifiques ne s'appliquent pas à vos applications, vous pouvez les ajouter à une liste d'autorisation.
La validation continue étend la validation des stratégies à l'environnement de post-déploiement. Lorsqu'elle est activée, l'autorisation binaire effectue une validation tout au long du cycle de vie du pod en enregistrant régulièrement la conformité aux règles dans Cloud Logging. Cette fonctionnalité est utile dans diverses 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 contrôlé
Le portail de déploiement vous permet d'approuver ou de refuser des déploiements à des stades 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 contrôlés empêchent les utilisateurs non autorisés d'apporter des modifications aux environnements d'application. Ils offrent une surveillance supplémentaire du processus de déploiement et une meilleure visibilité des approbations.
Dans Google Cloud, 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 contrôlé permet aux utilisateurs de spécifier si une approbation est nécessaire pour la promotion sur une cible.
Surveiller vos charges de travail
Les charges de travail sont des applications exécutées 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 avoir une configuration renforcée qui limite leur surface d'attaque.
Il peut être difficile de vérifier manuellement les charges de travail à grande échelle sur plusieurs clusters. Software Delivery Shield est une solution de sécurité sur la chaîne d'approvisionnement logicielle entièrement gérée sur Google Cloud. Elle fournit des tableaux de bord dans Cloud Run et l'interface utilisateur de GKE dans la console Google Cloud afin d'afficher des insights de sécurité pour les charges de travail.
Le tableau de bord de stratégie de sécurité GKE vous fournit des conseils pour renforcer la stratégie de sécurité de vos clusters en fonction des recommandations de Google. Elle inclut une analyse automatique de la configuration des charges de travail, qui recherche les problèmes de configuration connus pour toutes les charges de travail. GKE vérifie que chaque charge de travail déployée 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 bénéficier d'une piste vérifiable des problèmes et améliorer la création de rapports et l'observabilité. Pour savoir comment afficher les insights de sécurité dans le tableau de bord de stratégie de sécurité 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 des informations sur la conformité SLSA au niveau de la compilation, la preuve de compilation et les failles détectées dans les services en cours d'exécution. Pour obtenir des instructions sur l'affichage des insights sur la sécurité dans le panneau "Insights sur la sécurité" de Cloud Run, consultez la section Déployer sur Cloud Run et afficher les insights sur la sécurité.
Software Delivery Shield fournit également d'autres services et fonctionnalités pour améliorer votre stratégie de sécurité tout au long du cycle de développement logiciel. Pour en savoir plus, consultez la présentation de Software Delivery Shield.
Étapes suivantes
- Découvrez les bonnes pratiques pour protéger le code source.
- Découvrez les bonnes pratiques pour protéger les dépendances.
- Découvrez les bonnes pratiques pour protéger les builds.