持续验证概览

使用基于检查的平台政策的持续验证 (CV) 是 Binary Authorization 的一项功能，可让您监控在 Google Kubernetes Engine (GKE) 上运行的 Pod，以确保其关联的容器映像持续符合您指定的 Binary Authorization 基于检查的平台政策。

在 CV 确定 Pod 违反了平台政策时，它会将违规行为记录到 Cloud Logging 中。

使用平台政策的 CV 取代了旧版持续验证（已弃用）。

为何使用 CV？

虽然 Binary Authorization 强制执行会在您部署容器映像时提供一次性映像验证，但 CV 会持续监控与正在运行的 Pod 关联的映像是否始终符合政策。

因此，当您同时启用 Binary Authorization 强制执行和使用基于检查的政策的 CV 时，您可以确保在整个编排生命周期中验证政策合规性。

CV 在以下情况下非常有用：

  • 政策更改：当您更新 Binary Authorization 项目单例强制执行政策时，Binary Authorization 仅验证更新后部署的映像。已在运行的 Pod 不受影响。即使使用更新政策的 Binary Authorization 现在会阻止部署同一映像，它们也会继续运行。

    因此，当您更新 Binary Authorization 项目单例政策时，我们还建议您创建或更新 CV 平台政策，以匹配项目单例政策。这样，CV 就会通知您正在运行的 Pod 违反了更新后的政策。

  • 监控图片元数据：CV 会对映像元数据中的更改提供特定检查，包括：

    • 证明：Pod 映像上的证明失效时，CV 会记录日志。
    • 新鲜度：CV 会在检测到 Pod 映像不再最新时记录日志。
    • 来源：CV 可以使用可信源代码库中的配置构建配置来检查 Pod 的映像是否是通过可信的构建器构建的。
    • Sigstore 签名：如果 Pod 的映像上缺少有效的 Sigstore 签名，CV 会记录日志。
    • 可信目录：当 Pod 的映像驻留在平台政策中未列出的代码库目录中时，CV 会记录日志。
    • 漏洞：在 Pod 映像中发现漏洞时，CV 会记录日志。

  • 试运行监控：启用试运行后，Binary Authorization 会允许部署所有映像。通过启用使用与项目单例政策匹配的平台政策的 CV，CV 会定期记录违反平台政策的映像。

  • Breakglass 监控：使用 Breakglass 部署 Pod 时，Binary Authorization 会绕过项目单例政策强制执行，并将单个事件记录到 Cloud Audit Logs。但是，通过使用匹配的平台政策，CV 会继续定期记录违反政策的 Pod，包括使用 Breakglass 部署的 Pod。

CV 的工作原理

如需使用 CV，您必须在 GKE 集群上启用 CV。

在集群上部署映像后，CV 会监控关联的 Pod，以确保它们符合基于检查的平台政策。

CV 不支持映像标记，豁免映像中指定的标记除外。

CV 定期审核正在运行的 Pod

为了监控正在运行的 Pod，CV 至少每 24 小时审核一次与每个 Pod 关联的映像。CV 还会监控 init 容器和临时容器。

在每次审核期间，CV 会检索与每个 Pod 关联的映像列表。之后，CV 会验证映像信息是否符合平台政策。

CV 记录违反平台政策的行为

在 CV 确定映像违反了平台政策时，会将违规行为和其他发现结果记录到 Cloud Logging 中。系统会针对每个 Pod 违反的每个平台政策写入单独的日志条目。

当 CV 使用平台政策评估 Pod 的映像时，这些映像可能会符合某些检查，但会违反其他检查。只要 Pod 的任何映像违反了任何检查，CV 就会生成日志条目。日志条目仅包含违反平台政策的 Pod 映像。如果所有映像都通过所有检查，则不会生成日志条目。

在映像不符合政策的 Pod 终止之前，CV 会继续记录违反政策的情况。如果在两次验证之间的时间间隔内终止不符合政策的 Pod，则最终 CV 生成的日志条目可能会在终止后的下一次 CV 评估期间显示。

不符合政策的 Pod 应至少记录一次，即使对于短期 Pod 也是如此。

CV 不会终止正在运行的 Pod。

CV 使用 Feed 资源

如需检索在 GKE 集群上运行的 Pod 的相关信息，CV 会创建一个名为 binauthz-cv-cai-feed 的 Feed 资源。

CV 平台政策

如需使用 CV，请先配置平台政策。

平台政策与旧版 Binary Authorization 政策（也称为项目单例政策）不同。虽然部署项目只能有一个旧版项目单例政策，但您可以配置多个平台政策。每个平台政策可以位于一个或多个项目中。

平台政策仅适用于 CV，不支持 Binary Authorization 强制执行。因此，如果您要同时使用 Binary Authorization 强制执行和 CV 监控，我们建议您为强制执行创建项目单例政策，为监控创建平台政策。

例如，假设您想要配置 Binary Authorization 以强制您的映像在经过证明后才以部署，并且您还想要确保正在运行的 Pod 符合相同的要求。为此，您可以为项目单例强制执行政策配置证明者。然后，您将使用简单签名证明检查创建平台政策。该检查包含的身份验证器基于与证明者相同的备注和公钥。

平台政策因平台而异。GKE 是唯一受支持的平台。

您可以在平台政策中配置检查。检查分组为一个或多个检查集。每个检查集可以指定一个或多个检查。

平台政策可以豁免映像，使其不受 CV 评估。

所需权限

如需列出或描述平台政策，您需要拥有 binaryauthorization.policyViewer 角色。如需创建、修改和删除平台政策，您需要 binaryauthorization.policyEditor 角色。 如需了解详情，请参阅管理平台政策。

政策更新

更新平台政策会使用您在 YAML 文件中提供的政策描述信息覆盖现有政策。要向现有平台政策添加新检查，我们建议您描述现有政策，将其保存到 YAML 文件，添加新检查，然后使用更新后的文件更新政策。

多平台政策

您可以在集群所在的项目中创建平台政策（本地平台政策），也可以任何其他项目中创建平台政策。

由于您可以配置多个平台政策，因此请使用唯一资源名称为每个平台政策命名。运行 gcloud CLI 命令时，您将使用 ID 引用本地平台政策。在其他项目中引用平台政策时，请使用以下格式的资源名称：projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID

您可以选择要与每个 GKE 集群关联的平台政策，可以是本地平台政策，也可以是其他项目中的政策。

每个平台政策进行多个检查

您可以在每个平台政策中配置多个检查，方法是将它们添加到政策的 checks 块中。如需详细了解您可以配置的特定检查，请参阅检查。

如果您的 CV 平台政策指定了多个检查，则由一个检查评估的映像将继续由另一个检查进行评估。

Binary Authorization 会评估平台政策中为每个映像配置的所有检查，除非该映像与豁免映像许可名单模式匹配。如需了解详情，请参阅豁免映像。

单项目设置

您可以在单个项目中设置 CV。

在单项目设置中，Binary Authorization 会自动在 Binary Authorization 服务代理中设置所需的角色。

如果 GKE 集群、绑定到集群的平台政策以及检查所需的元数据都位于同一项目中，则无需其他 Identity and Access Management (IAM) 角色。

如需详细了解如何配置多项目设置以提高安全性，请参阅关注点分离。

多项目设置

在配置包含平台政策的多项目 CV 设置时，平台政策、映像、GKE 集群和其他类型的 CV 依赖资源可以分别位于不同的项目中。

在多项目设置中，必须了解每个项目的用途以及 CV 需要访问的资源并相应地设置所需的 IAM 角色和权限。

如何使用 CV

如需使用 CV，您通常要执行以下操作：

  1. 确定要使用的检查。
  2. 使用 YAML 格式政策文件编写一个或多个平台政策。该文件指定要使用的检查。
  3. 创建平台政策。 该政策可以存储在您选择的项目中。
  4. 选择是在单个集群还是在舰队中启用 CV。
  5. 在 Logging 中检查 CV 日志以了解事件。
  6. 查看日志并更新构建流程和其他流程，以生成通过检查的映像。

检查

本部分介绍 CV 提供的特定检查。

基于检查的政策具有以下规范格式：

gkePolicy:
  checkSets:
  - checks:
    - CHECK_TYPE1:
        CHECK_TYPE1_PARAMETERS
      displayName: CHECK_TYPE1_DISPLAY_NAME
    - CHECK_TYPE2:
        CHECK_TYPE2_PARAMETERS
      displayName: CHECK_TYPE2_DISPLAY_NAME
    displayName: CHECK_SET_DISPLAY_NAME

checks 和 checkSets 中的 displayName 字段为可选字段。它仅在 CV 记录违反政策的情况时使用。在本指南后面的某些示例中省略了此字段。

“始终拒绝”检查

始终拒绝检查可确保受此检查约束的所有映像都未通过评估。每当 CV 通过检查此审核正在运行的 Pod 时，它就会为每个 Pod 生成一个日志条目。

您可以将“始终拒绝”检查与许可名单或多个检查集结合使用，以确保 Binary Authorization 在某些情况下始终为 Pod 生成日志。

如需使用“始终拒绝”检查，请在 checks 块中添加 alwaysDeny: true，如下所示：

gkePolicy:
  checkSets:
    - displayName: "My check set"
      checks:
        - alwaysDeny: true

alwaysDeny 的值不能设置为 false。请改为移除该检查。

如需查看如何使用“始终拒绝”检查的示例，请参阅使用多个检查集。

映像新鲜度检查

映像新鲜度检查会计算映像已运行的时长，并记录时长在何时超过阈值 maxUploadAgeDays。

在以下示例平台政策 YAML 中，CV 会记录 Pod，其中的映像在超过 30 天前上传到作为部署来源的代码库。

gkePolicy:
  checkSets:
    checks:
    - imageFreshnessCheck:
        maxUploadAgeDays: 30
      displayName: "My image freshness check"
    displayName: "My check set"

简单签名证明检查

您可以使用 CV 简单签名证明检查来检查 Pod 的每个映像是否具有有效的签名证明。

此检查等效于 Binary Authorization 强制执行政策中的证明评估。您可以使用在证明者中使用的备注和密钥来配置此检查。我们建议您使用此检查，而不是旧版持续验证（已弃用）。

以下是包含简单签名证明检查的平台政策示例：

gkePolicy:
  checkSets:
    checks:
      simpleSigningAttestationCheck:
        containerAnalysisAttestationProjects:
        - "projects/my-attestation-project1"
        - "projects/my-attestation-project2"
        attestationAuthenticators:
          pkixPublicKeySet:
            pkixPublicKeys:
              publicKeyPem: |
                -----BEGIN PUBLIC KEY-----
                MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQxXxgAEvgQuW1FHYZPB2PTQfOJKUkS9sjMO/1os10xOWrhl1kQo4EnzMOovROWVLo+m9mcwp7nRQ2qQDThZdSFi0nFJ1A==
                -----END PUBLIC KEY-----
              signatureAlgorithm: ECDSA_P256_SHA256

CV 证明检查具有身份验证器，而不是 Binary Authorization 证明者。您可以直接在政策的 attestationAuthenticators 块中指定身份验证器。

在平台政策中，simpleSigningAttestationCheck 可以在每个 pkixPublicKeySet 中有多个 attestationAuthenticators 和多个密钥。如果每个 Pod 的映像都有使用任何身份验证器的 pkixPublicKeySet 中的任何密钥进行签名的有效证明，则检查通过。

CV 平台政策在以下方面与项目单例强制执行政策不同：

  • 不支持 PGP 密钥。
  • 不需要证明者。 但您可以手动创建密钥，然后描述平台政策，以检索随后用于创建证明的密钥 ID。
  • 您可以手动创建载荷和并对其签名，创建证明 JSON 文件，然后使用 Artifact Analysis API 创建证明。
  • 您仍然可以创建 Artifact Analysis 备注，但不会在政策中指定该备注。相反，CV 会在 containerAnalysisAttestationProjects 字段中列出的每个项目中查找证明。
  • 证明仍存储在 Artifact Analysis 发生实例中，但它们可以存储在多个项目中。
  • 您必须使用资源名称 projects/ATTESTATION_PROJECT_ID 明确指定包含证明的一个或多个项目。

CV 不支持映像标记，但豁免映像中指定的标记除外。

如果使用映像标记（而非摘要）部署映像，CV 会先根据豁免映像对其进行评估，因为许可名单可以包含标记。如果映像不受豁免，则 CV 会尝试查找映像摘要。因为没有映像摘要，映像就会违反检查。

SLSA 检查

SLSA 检查会检查 Pod 映像的 SLSA 指定的来源。

以下是 CV 平台政策 YAML 配置的示例：

gkePolicy:
  checkSets:
    checks:
      imageAllowlist:
        allowPattern: "gcr.io/my-images/not-built-by-GCB/**"
    - slsaCheck:
        rules:
          trustedBuilder: GOOGLE_CLOUD_BUILD
          attestationSource:
          - containerAnalysisAttestationProjects: "projects/attestation-project1"
          - containerAnalysisAttestationProjects: "projects/attestation-project2"
          # Require that images were built using a checked-in top-level config file.
          configBasedBuildRequired: true
          # Which repos the config file can be from.
          trustedSourceRepoPatterns:
          - "source.cloud.google.com/my-project/my-source-repo"
          - "github.com/my-github-user/*"
      displayName: "My SLSA check"
    displayName: "My check set"

当 CV 使用此平台政策审核映像时，它会检查以下内容：

  • 映像必须由可信构建器构建。Cloud Build 是 SLSA 检查支持的唯一可信构建器。

  • Cloud Build 必须在 attestation-project1 或 attestation-project2 中生成证明。

  • 必须使用以下任一可信代码库中的顶级配置文件来构建映像：

    • 代码库 source.cloud.google.com/my-project/my-source-repo/
    • github.com/my-github-user/ 中的任何代码库

  • gcr.io/my-images/not-built-by-GCB/ 或其子目录中的映像（这些映像不是由 Cloud Build 构建的）可以免于检查，因为它们将违反检查。

Sigstore 签名检查

Sigstore 签名检查会验证映像已使用 Sigstore 签名进行签名。

此检查仅支持 Artifact Registry 中托管的映像。它会检查从 Artifact Registry 提取的任何签名是否可以由政策中的任何密钥成功验证。

以下示例平台政策展示了如何配置 Sigstore 签名检查：

  gkePolicy:
    checkSets:
    - checks:
      - displayName: sigstore-signature-check
        sigstoreSignatureCheck:
          sigstoreAuthorities:
          - displayName: sigstore-authority
            publicKeySet:
              publicKeys:
                publicKeyPem: |
                  -----BEGIN PUBLIC KEY-----
                  MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQxXxgAEvgQuW1FHYZPB2PTQfOJKUkS9sjMO/1os10xOWrhl1kQo4EnzMOovROWVLo+m9mcwp7nRQ2qQDThZdSFi0nFJ1A==
                  -----END PUBLIC KEY-----

在平台政策中，sigstoreSignatureCheck 可以在每个 publicKeySet 中有多个 sigstoreAuthorities 和多个密钥。如果每个 Pod 的映像都有使用任何身份验证器的 publicKeySet 中的任何密钥进行签名的有效证明，则检查通过。

可信目录检查

可信目录检查会检查 Pod 的映像是否位于您在平台政策中指定的某个提供的可信目录中。

使用此检查时，我们还建议您保护在政策中列为可信目录的代码库，以防止未经授权的访问。

以下平台政策示例介绍了如何配置可信的目录检查：

gkePolicy:
  checkSets:
    checks:
      trustedDirectoryCheck:
        trustedDirPatterns:
        - "gcr.io/my-project/gcr-directory"
        - "us-central1-docker.pkg.dev/my-project/ar-directory"
        displayName: "My trusted directory check"
    displayName: "My check set"

在示例平台政策中，trustedDirPatterns 列出了可信目录。如果所有 Pod 的映像都位于列出的目录中，则它们符合政策。不在所列目录中的 Pod 的映像违反了政策，且 CV 会记录违规行为。

漏洞检查

漏洞检查使用 Artifact Analysis 漏洞扫描来检查 Pod 的映像是否包含漏洞。这包括自 Pod 部署后通过漏洞扫描发现的新漏洞。在漏洞检查中，您可以配置漏洞严重级别阈值和特定漏洞（作为 CVE）。包含漏洞的映像违反漏洞检查，会被记录到 Logging 中。

如需使用此检查，您必须先在 Artifact Analysis 中启用漏洞扫描。

以下示例平台政策配置包含漏洞检查：

gkePolicy:
  checkSets:
    - displayName: "Default check set"
      checks:
        - vulnerabilityCheck:
           maximumFixableSeverity: MEDIUM
           maximumUnfixableSeverity: HIGH
           allowedCves:
             - "CVE-2022-11111"
             - "CVE-2022-22222"
           blockedCves:
             - "CVE-2022-33333"
             - "CVE-2022-44444"
           containerAnalysisVulnerabilityProjects: "projects/my-project"

在此示例中，maximumUnfixableSeverity 和 maximumFixableSeverity 定义了与 Artifact Analysis 可以识别的任何漏洞关联的常见漏洞评分系统 (CVSS) 严重级别。 此外，blockedCves 列出了特定的常见漏洞披露 (CVE)。如果识别出的漏洞超出某个规定的严重级别或与 blockedCves 中列出的某个 CVE 匹配，并且与 allowedCves 中列出的某个 CVE 不匹配，则 CV 会将条目记录到 Logging 中。

验证更新后的政策

更新 CV 平台政策后，我们强烈建议您验证 Binary Authorization 和 CV 是否继续按预期运行。

验证您的配置

如需检查您的配置，请检查 Binary Authorization 项目单例政策和 CV 平台政策。

验证操作

如需验证 Binary Authorization 和 CV 是否按预期运行，您可以部署测试 Pod，然后在 Logging 中检查 Binary Authorization 条目。

使用许可名单豁免映像

创建平台政策时，您可以通过将映像的网址添加到许可名单来豁免这些映像。政策级层的许可名单可让映像获得整个政策的豁免。检查集级层的许可名单可获得检查集的豁免，它仅在评估该检查集时适用。某个检查中的许可名单只能让映像获得该检查的豁免。

许可名单格式是与一个或多个图片网址匹配的格式。许可名单格式可以是以下任一项：

  • 映像名称前缀，以通配符 * 或 ** 结尾。
  • 只是映像名称，不带标记或摘要。
  • 带标记的映像名称（或带通配符 * 的标记前缀）。
  • 带摘要的映像名称。
  • 同时带标记和摘要的映像名称。

以下是许可名单格式示例：

  • us-central1.pkg.dev/my-project/my-image:latest@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c 与映像名称、标记和摘要完全匹配。
  • us-central1.pkg.dev/my-project/my-image:latest 匹配带任何摘要（或无摘要）的名称和标记。
  • us-central1.pkg.dev/my-image:foo* 匹配带任何摘要（或无摘要）的名称和标记前缀（例如 myimage:foo 和 myimage:foobar）。
  • us-central1.pkg.dev/my-project/my-image@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c 匹配带任何标记（或无标记）的名称和摘要。
  • us-central1.pkg.dev/my-project/my-image 匹配带任何标记和/或摘要的名称。

通配符 * 和 ** 可用于匹配带特定前缀的任何名称。* 匹配不包含 / 的后缀。** 匹配可以包含 / 的后缀，但 ** 只能在 / 之后使用。请注意，* 和 ** 不能与标记或摘要一起使用。

例如：

  • us-central1.pkg.dev/my-project/my-image* 匹配带任何标记和/或摘要的 us-central1.pkg.dev/myproject/my-image、us-central1.pkg.dev/myproject/my-image1 和 us-central1.pkg.dev/myproject/my-image2。
  • us-central1.pkg.dev/my-project/** 匹配带任何标记和/或摘要的 us-central1.pkg.dev/myproject/my-image 和 us-central1.pkg.dev/my-project/some-directory/other-image。

请注意，名称前缀和标记前缀不得为空。因此，只有单独的 * 或 ** 不是有效的模式，us-central1.pkg.dev/my-image:* 也不是。

gkePolicy 级层的豁免

以下示例展示了如何在平台政策级层豁免映像。exempt-images1 和 exempt-images2 目录及其子目录中的所有映像都会从 CV 监控中排除。

gkePolicy:
  imageAllowlist:
  - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
  - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
  checkSets:
      checks:
        ...

在该政策中，imageAllowlist 下列出的映像将获得 gkePolicy 下列出的所有检查集 (checkSets) 的豁免。

checkSet 级层的豁免

以下示例展示了如何在检查集级层豁免映像：

gkePolicy:
  checkSets:
    imageAllowlist:
    - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
    - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
    checks:
      ...

在该政策中，imageAllowlist 下列出的映像将获得 checkSets 下列出的所有检查的豁免。

检查级层的豁免

以下示例展示了如何在检查级层豁免映像：

gkePolicy:
  checkSets:
    checks:
      imageAllowlist:
      - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
      - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
      ...

使用多个检查集

CV 基于检查的政策可以包含多个检查集。 CV 每次评估政策时都会评估一个检查集。您可以将检查集视为应该在不同情况下评估的子政策。例如，如果要在开发环境中应用与生产环境不同的检查，可以将每个环境的检查放在单独的检查集中，一个检查集仅在开发环境获得评估，一个检查集在生产环境中获得评估。

每个检查集的范围限定为 Kubernetes 命名空间或 Kubernetes 服务账号。范围决定了检查集适用的 Pod。

如果检查集配置了范围，则该范围将仅适用于在该范围内运行的 Pod。

如果检查集没有范围，则称为默认检查集，这意味着检查将应用于所有 Pod，无论其 Kubernetes 命名空间或服务账号的范围如何。

CV 指南中的大多数示例政策都仅使用默认检查集。

以下示例政策配置配置了三个检查集：

gkePolicy:
  checkSets:
    - displayName: "Prod check set"
      scope:
        kubernetesNamespace: "prod-namespace"
      checks:
        - trustedDirectoryCheck:
            trustedDirPatterns: "gcr.io/my-project/prod-images"
        - imageFreshnessCheck:
            maxUploadAgeDays: 30
    - displayName: "Dev check set"
      scope:
        kubernetesNamespace: "dev-namespace"
      checks:
        - trustedDirectoryCheck:
            trustedDirPatterns: "gcr.io/my-project/dev-images"
    - displayName: "Default check set"
      checks:
        - alwaysDeny: true

在该示例配置中，第一个检查集的范围限定为 prod-namespace，因此其检查仅影响该范围内运行的 Pod。第二个检查集的范围限定为 dev-namespace，因此其检查仅影响该范围内运行的 Pod。第三个检查集是默认检查集。其检查适用于集群中在 prod-namespace 和 dev-namespace 范围之外运行的所有 Pod。

在 CV 评估名为 Prod check set 的检查集时，它会对 prod-namespace Kubernetes 命名空间中运行的 Pod 映像检查以下项目：

  • 这些映像是否存储在可信的 prod-images 目录中。
  • 这些映像是否是过去 30 天内上传的。

在 CV 评估名为 Dev check set 的检查集时，它会评估 dev-namespace Kubernetes 命名空间中运行的 Pod，检查 Pod 中的映像是否来自 dev-images 目录。

默认检查集充当无限别名。“始终拒绝”检查可确保 CV 记录在任何其他命名空间中运行的所有 Pod。

如需使用 Kubernetes 服务账号作为检查集的范围，请将示例中的密钥 kubernetesNamespace 替换为 kubernetesServiceAccount。该值的格式为 my-namespace:my-service-account。

检查集范围具有以下规则：

  • 在平台政策中，每个范围只能有一个检查集。

  • 如果政策同时包含命名空间范围和服务账号范围的检查集，则必须首先列出服务账号范围的检查集，然后列出命名空间范围的检查集。

  • 只能有一个默认检查集，并且必须列在最后。

如果平台政策包含任何检查集，则必须至少包含默认检查集。允许没有检查集的平台政策，但由于没有检查进行违反，因此 CV 不会生成任何日志条目。

旧版 CV

本部分介绍旧版 CV 政策。如果您刚接触 CV，我们建议您改用使用基于检查的政策的 CV。

为了支持旧版 CV 用户，可以在运行 GKE 的项目上启用 CV。这样，CV 就会使用 Binary Authorization 强制执行政策来检查在该项目中所有集群上运行的所有 Pod，包括未启用 Binary Authorization 强制执行的集群。

了解如何使用旧版 CV（已弃用）以及如何在 Cloud Logging 中查看旧版 CV 事件。

后续步骤