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 la vérification
En plus de la prise en charge des 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 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 analysée pour détecter les failles de sécurité dont le niveau de gravité est celui que vous définissez.
Comme l'ancienne validation continue, la CV avec règles basées sur la vérification enregistre également les pods avec des images non conformes dans Logging.
Si vous utilisez l'ancienne validation continue, consultez Migration.
Pour migrer d'une ancienne règle Singleton de projet CV vers 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 blocage 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 comportant 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 des vérifications sont limitées à 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 de la création ou de la mise à jour du cluster.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/04 (UTC)."],[[["\u003cp\u003eBinary Authorization is discontinuing support for legacy continuous validation (legacy CV) with project-singleton policies for GKE, with new projects unable to enable it after April 15, 2024, and existing projects losing monitoring capabilities after May 1, 2025.\u003c/p\u003e\n"],["\u003cp\u003eContinuous validation (CV) with check-based platform policies is the replacement for legacy CV, allowing for monitoring of container image metadata and offering checks such as vulnerability, Sigstore, SLSA, and trusted directory checks.\u003c/p\u003e\n"],["\u003cp\u003eMigrating from a legacy CV project-singleton policy to a check-based platform policy involves creating a corresponding check-based policy with appropriate \u003ccode\u003echeckSet\u003c/code\u003e configurations.\u003c/p\u003e\n"],["\u003cp\u003eUnlike legacy CV policies, check-based platform policies are scoped to a GKE cluster, allowing the same policy to be applied to multiple clusters.\u003c/p\u003e\n"],["\u003cp\u003eTo use CV with check-based policies, the cluster's Binary Authorization must be configured during the cluster creation or update process.\u003c/p\u003e\n"]]],[],null,["# Legacy continuous validation deprecation and shutdown\n\nThe\n[Google Cloud Platform Terms of Service (section \"Discontinuation of Services\")](/terms)\ndefines the deprecation policy that applies to Binary Authorization.\nThe [deprecation policy](/terms/deprecation) only applies to the services,\nfeatures, or products listed therein.\n\n\nAfter a service, feature, or product is officially\ndeprecated, it continues to be available for at least the period of time defined in the\nTerms of Service. After this period of time, the service is scheduled for shutdown.\n\nBinary Authorization is ending support for legacy continuous validation (legacy CV)\nwith project-singleton policies for GKE.\n\n- As of April 15, 2024, you can't enable legacy CV for Google Kubernetes Engine (GKE) on new projects.\n- Legacy CV will continue monitoring your GKE Pods through project-singleton policies for existing projects for which it is already enabled until May 1, 2025. After May 1, 2025, legacy CV will no longer monitor your Pods, and Cloud Logging entries will no longer be produced for Pod images that don't conform to the project-singleton Binary Authorization policy.\n\nReplacement: Continuous validation (CV) with check-based platform policies\n--------------------------------------------------------------------------\n\nMonitor your Pods using [continuous validation (CV) with check-based platform policies](/binary-authorization/docs/overview-cv).\n\nIn addition to support for attestations, check-based platform policies let you\nmonitor the metadata of container images associated with your Pods to help you\nmitigate potential security issues. CV check-based policies\nprovide checks that include the following:\n\n- [Vulnerability check](/binary-authorization/docs/cv-vulnerability-check): The image is checked for security vulnerabilities that are at a level of severity that you define.\n- [Sigstore check](/binary-authorization/docs/cv-sigstore-check): The image has attestations that are signed by sigstore.\n- [SLSA check](/binary-authorization/docs/cv-slsa-check): The image was built from source in a trusted directory and by a trusted builder.\n- [Trusted directory check](/binary-authorization/docs/cv-trusted-directory-check): The image must reside in a trusted directory within a trusted image repository.\n\nLike legacy continuous validation, CV with check-based policies also logs\nPods with non-conformant images to Logging.\n\nIf you use legacy continuous validation (legacy CV), see [Migration](#migration).\n\nFor more information on how to use CV with check-based platform policies, see\n[Continuous validation overview](/binary-authorization/docs/overview-cv).\n\nMigration\n---------\n\nTo migrate from a legacy CV project-singleton policy to an\nequivalent check-based platform policy, do the following:\n\n- For an `ALWAYS_ALLOW` project-singleton policy, create a check-based platform policy without any `checkSet` block.\n- For an `ALWAYS_DENY` project-singleton policy, create a check-based platform policy with a single `checkSet` block that has an `alwaysDeny` check.\n- For a project-singleton policy that requires attestations, create a single check-based policy, and for each attestor in the project-singleton policy, add one [SimpleSigningAttestationCheck](/binary-authorization/docs/overview-cv#simple-signing-check) to the check-based policy. By using the same key pair, the check continues to work with your existing attestations, and logs only Pod images that don't have valid attestations.\n\nCheck-based platform policies are scoped to a GKE cluster, rather\nthan a Google Cloud project. After you create a check-based platform\npolicy, you can apply that policy to one or more clusters.\n\nTo enable CV with check-based platform policies on a cluster,\nthe cluster's Binary Authorization settings must be [configured](/binary-authorization/docs/creating-cluster#console)\nduring the cluster creation or update process."]]
