Les Conditions d'utilisation de Google Cloud Platform (section 1.4(d), "Discontinuation 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 ne prend plus en charge 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 des vérifications
Surveillez vos pods à l'aide de la validation continue (CV) avec des règles de plate-forme basées sur des vérifications.
En plus de la compatibilité avec les attestations, les règles de plate-forme basées sur des vérifications vous permettent de surveiller les métadonnées des images de conteneurs associées à vos pods afin de limiter 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é au niveau de gravité que vous définissez.
- Vérification Sigstore: l'image possède 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 pour l'ancienne validation continue, la CV avec règles basées sur des vérifications consigne également les pods avec des images non conformes dans Logging.
Si vous utilisez l'ancienne validation continue (ancienne CV), consultez la page Migration.
Pour en savoir plus sur l'utilisation de la CV avec des règles de plate-forme basées sur des vérifications, consultez la page Présentation de la validation continue.
Migration
Pour migrer d'une ancienne règle Singleton de projet CV vers une règle de plate-forme équivalente basée sur des vérifications, 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 aucun bloccheckSet. - 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 bloccheckSetdoté d'une vérificationalwaysDeny. - 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 des vérifications s'appliquent à un cluster GKE, et non à un projet Google Cloud. Après avoir 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 la vérification 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.