Abandon et arrêt des anciennes validations continues

Les Conditions d'utilisation de Google Cloud Platform (section 1.4(d), "Arrêt des services") définissent le règlement relatif aux abandons applicable à Binary Authorization. Le règlement relatif aux abandons ne s'applique qu'aux services, aux fonctionnalités ou aux produits répertoriés ici.

Une fois qu'un service, une fonctionnalité ou un produit est officiellement obsolète, il reste disponible pendant une période au moins égale à celle définie dans les conditions d'utilisation. Passé ce délai, l'abandon du service est planifié.

L'autorisation binaire met fin à la prise en charge de l'ancienne validation continue (ancienne CV) avec les règles singleton de projet pour GKE.

• Depuis le 15 avril 2024, vous ne pouvez plus activer l'ancienne CV pour Google Kubernetes Engine (GKE) sur les nouveaux projets.
• L'ancienne CV continuera de surveiller vos pods GKE à l'aide de règles Singleton de projet pour les projets existants pour lesquels elle est déjà activée jusqu'au 1er mai 2025. Après le 1er mai 2025, l'ancienne CV ne surveillera plus vos pods et les entrées Cloud Logging ne seront plus générées pour les images de pods non conformes à la règle d'autorisation binaire Singleton du projet.

Remplacement: validation continue (CV) avec des règles de plate-forme basées sur la vérification

Surveillez vos pods à l'aide de la validation continue (CV) avec des règles de plate-forme basées sur la vérification.

En plus de la prise en charge des attestations, les règles de plate-forme basées sur les vérifications vous permettent de surveiller les métadonnées des images de conteneurs associées à vos pods pour vous aider à atténuer les problèmes de sécurité potentiels. Les règles basées sur les vérifications de la CV fournissent des vérifications qui incluent les éléments suivants:

• Vérification des failles: l'image est vérifiée pour détecter les failles de sécurité dont le niveau de gravité est défini par l'utilisateur.
• Vérification Sigstore: l'image comporte des attestations signées par Sigstore.
• Vérification SLSA: l'image a été créée à partir de la source dans un répertoire de confiance et par un compilateur de confiance.
• Vérification du répertoire de confiance: l'image doit se trouver dans un répertoire de confiance au sein d'un dépôt d'images de confiance.

Comme l'ancienne validation continue, la CV avec des règles basées sur les vérifications journalise également les pods avec des images non conformes dans le journal.

Si vous utilisez l'ancienne validation continue, consultez la section Migration.

Pour en savoir plus sur l'utilisation de la CV avec des règles de plate-forme basées sur la vérification, consultez la section Présentation de la validation continue.

Migration

Pour passer d'une ancienne règle Singleton de projet de CV à une règle de plate-forme basée sur des vérifications équivalente, procédez comme suit:

• Pour une règle Singleton de projet ALWAYS_ALLOW, créez une règle de plate-forme basée sur des vérifications sans bloc checkSet.
• Pour une règle Singleton de projet ALWAYS_DENY, créez une règle de plate-forme basée sur des vérifications avec un seul bloc checkSet avec une vérification alwaysDeny.
• Pour une règle Singleton de projet nécessitant des attestations, créez une seule règle basée sur des vérifications, puis ajoutez une vérification SimpleSigningAttestationCheck à la règle basée sur des vérifications pour chaque certificateur de la règle Singleton de projet. En utilisant la même paire de clés, la vérification continue de fonctionner avec vos attestations existantes et ne consigne que les images de pods qui ne possèdent pas d'attestations valides.

Les règles de plate-forme basées sur les vérifications s'appliquent à un cluster GKE, et non à un projet Google Cloud. Une fois que vous avez créé une règle de plate-forme basée sur des vérifications, vous pouvez l'appliquer à un ou plusieurs clusters.

Pour activer la CV avec des règles de plate-forme basées sur des vérifications sur un cluster, les paramètres d'autorisation binaire du cluster doivent être configurés lors du processus de création ou de mise à jour du cluster.