서비스, 기능 또는 제품이 공식적으로 지원 중단된 후에도 최소한 서비스 약관에서 정의된 기간 동안에는 계속 사용할 수 있습니다. 이 기간 이후에는 서비스가 종료될 예정입니다.
Binary Authorization은 GKE용 프로젝트 싱글톤 정책을 사용한 기존 지속적 검증(기존 CV)에 대한 지원을 종료합니다.
2024년 4월 15일부터는 새 프로젝트에서 Google Kubernetes Engine(GKE)에 기존 CV를 사용 설정할 수 없습니다.
기존 CV는 2025년 5월 1일까지 이미 사용 설정된 기존 프로젝트의 프로젝트 싱글톤 정책을 통해 GKE 포드를 계속 모니터링합니다. 2025년 5월 1일 이후에는 기존 CV가 더 이상 포드를 모니터링하지 않으며 프로젝트 싱글톤 Binary Authorization 정책을 준수하지 않는 포드 이미지에 대해 Cloud Logging 항목이 더 이상 생성되지 않습니다.
검사 기반 플랫폼 정책으로 CV를 사용하는 방법에 관한 자세한 내용은 지속적 검증 개요를 참조하세요.
마이그레이션
기존 CV 프로젝트 싱글톤 정책에서 상응하는 검사 기반 플랫폼 정책으로 이전하려면 다음 단계를 따르세요.
ALWAYS_ALLOW 프로젝트 싱글톤 정책의 경우 checkSet 블록이 없는 검사 기반 플랫폼 정책을 만듭니다.
ALWAYS_DENY 프로젝트 싱글톤 정책의 경우 alwaysDeny 검사가 있는 단일 checkSet 블록으로 검사 기반 플랫폼 정책을 만듭니다.
증명이 필요한 프로젝트 싱글톤 정책의 경우 단일 검사 기반 정책을 만들고 프로젝트 싱글톤 정책의 각 증명자에 대해 하나의 SimpleSigningAttestationCheck를 검사 기반 정책에 추가합니다 동일한 키 쌍을 사용하면 검사가 기존 증명과 함께 계속 작동하며 유효한 증명이 없는 포드 이미지만 로깅합니다.
검사 기반 플랫폼 정책은 Google Cloud 프로젝트가 아닌 GKE 클러스터로 범위가 지정됩니다. 검사 기반 플랫폼 정책을 만든 후 하나 이상의 클러스터에 해당 정책을 적용할 수 있습니다.
클러스터에서 검사 기반 플랫폼 정책으로 CV를 사용 설정하려면 클러스터 생성 또는 업데이트 프로세스 중에 클러스터의 Binary Authorization 설정을 구성해야 합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 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."]]