使用 Kritis Signer 创建证明

本教程介绍了如何构建 Kritis Signer；以及如何使用它先检查容器映像中是否存在漏洞，然后再创建 Binary Authorization 证明。

概览

Kritis Signer 是一种开源命令行工具，可以根据您配置的政策创建 Binary Authorization 证明。您还可以使用 Kritis Signer 先检查映像中是否存在由 Artifact Analysis 发现的漏洞，然后再创建证明。

此外，Cloud Build 可以在构建流水线中将 Kritis Signer 作为自定义构建器运行。

在本教程中，您将对 Kritis Signer 自定义构建器执行一次性构建，然后运行示例构建流水线。每个示例流水线都包含以下构建步骤：

1. 构建示例容器映像。
2. 将映像推送到 Container Registry。
3. 检查映像并对映像签名：使用 Kritis Signer 根据政策创建证明。

在每个流水线的检查并签名构建步骤中，Kritis Signer 都会执行以下操作：

1. 使用 Artifact Analysis 扫描新构建的映像，并检索漏洞列表。
2. 根据政策中的漏洞签名规则检查漏洞列表，然后执行以下操作：
   1. 如果所有已识别出的漏洞都符合漏洞签名规则，则 Kritis Signer 会创建证明。
   2. 如果有任何已识别出的漏洞违反了漏洞签名规则，则 Kritis Signer 不会创建证明。

在部署时，Binary Authorization Enforcer 会检查是否存在可验证的证明。如果没有可验证的证明，强制执行程序会禁止部署映像。

本教程还介绍了如何在 Cloud Build 流水线中以“仅检查”模式运行 Kritis Signer。在此模式下，Kritis Signer 不会创建证明，而只会检查漏洞结果是否满足政策中的漏洞签名规则。如果满足，Kritis Signer 构建步骤将成功完成且流水线会继续运行，否则该步骤将失败且流水线会退出。

目标

在本教程中，您将执行以下操作：

1. 将 Kritis Signer 设置为 Cloud Build 自定义构建器。
2. 查看包含漏洞签名规则的政策。
3. 运行 Kritis Signer 以根据漏洞扫描结果创建证明。
4. 以“仅检查”模式运行 Kritis Signer。

费用

本教程使用以下 Google Cloud 产品。

• Container Registry
• Artifact Analysis
• Cloud Build
• Cloud Key Management Service

请使用价格计算器根据您的预计使用情况来估算费用。

准备工作

在本部分中，您将对系统执行一次性设置。

设置环境

1. 将您的 Google Cloud 项目存储在环境变量中。

   注意：此 Google Cloud 项目在本教程中始终使用。

   export PROJECT_ID=PROJECT_ID
   

   将 PROJECT_ID 替换为您的 Google Cloud 项目。

2. 将默认项目 ID 设置为您的 Google Cloud 项目：

   gcloud config set project $PROJECT_ID
   

3. 将项目编号存储在环境变量中，以供后续步骤使用：

   export PROJECT_NUMBER=$(gcloud projects list --filter="${PROJECT_ID}" \
    --format="value(PROJECT_NUMBER)")
   

4. 启用 API：

   如需确保本指南所需的服务已启用，请执行以下命令：

   gcloud services enable \
     cloudbuild.googleapis.com \
     containerregistry.googleapis.com \
     containerscanning.googleapis.com \
     cloudkms.googleapis.com
   

设置 IAM 角色

运行以下命令以给 Cloud Build 服务账号配置以下角色：

• containeranalysis.notes.editor：添加 Artifact Analysis Notes Editor 角色以管理证明者。
• containeranalysis.notes.occurrences.viewer：添加 Artifact Analysis Occurrences for Notes 角色以管理漏洞和证明发生实例。
• roles/containeranalysis.occurrences.editor：添加 Artifact Analysis Occurrences Editor 角色以在 Artifact Analysis 中创建证明发生实例。

• cloudkms.signer：添加 Cloud KMS CryptoKey Signer 角色，以允许服务账号访问 Cloud KMS 签名服务。

  gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$[e-mail] --role roles/containeranalysis.notes.editor
  gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$[e-mail] --role roles/containeranalysis.notes.occurrences.viewer
  gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$[e-mail] --role roles/containeranalysis.occurrences.editor
  gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$[e-mail] --role roles/cloudkms.signer
  

设置 Kritis Signer 自定义构建器

在本部分中，您将对 Kritis Signer 自定义构建器执行一次性设置。您获取、构建和推送 Kritis Signer 后，便可以在任何 Cloud Build 流水线中使用它。

本部分介绍了如何执行以下操作：

• 克隆 Kritis 代码库。
• 构建 Kritis Signer Cloud Build 自定义构建器。
• 将 Kritis Signer 推送到 Container Registry，使其可作为 Cloud Build 构建步骤使用。

运行以下命令以获取本指南中使用的代码和配置文件：

1. 克隆 Kritis 代码库：

   git clone https://github.com/grafeas/kritis.git
   

   此代码库包含以下内容：

   • Kritis 的源代码，其中也包括 Kritis Signer。
   • Cloud Build 配置文件，Cloud Build 使用它构建 Kritis Signer 自定义构建器。
   • 包含漏洞签名规则的示例政策。
   • Cloud Build 配置文件示例。每个配置文件都将在漏洞扫描流水线中使用 Kritis Signer。

2. 导航到 kritis/ 目录：

   cd kritis
   

3. 构建并注册 Kritis Signer 自定义构建器。

   此一次性设置步骤可构建 Kritis Signer 自定义构建器，并将其注册到 Cloud Build。注册后，您可以在任何 Cloud Build 流水线中使用自定义构建器。

   gcloud builds submit . --config deploy/kritis-signer/cloudbuild.yaml
   

查看现有政策

本部分展示了一个 Kritis Signer 政策示例。

此政策将 Kritis Signer 配置为请求 Artifact Analysis 扫描映像中是否存在漏洞。扫描完成后，Kritis Signer 会根据政策中的漏洞签名规则检查返回的漏洞结果。

您可以修改此政策中的漏洞签名规则，以根据以下内容创建证明：

• 已识别漏洞的严重级别。
• 特定漏洞。

您还可以将政策设置为无条件创建 (ALLOW_ALL) 或不创建 (BLOCK_ALL) 证明。

如需查看 Kritis Signer 政策，请执行以下命令：

cat samples/signer/policy-strict.yaml

政策类似于以下内容：

apiVersion: kritis.grafeas.io/v1beta1
kind: VulnzSigningPolicy
metadata:
  name: my-vsp
spec:
  imageVulnerabilityRequirements:
    maximumFixableSeverity: MEDIUM
    maximumUnfixableSeverity: MEDIUM
    allowlistCVEs:
    - projects/goog-vulnz/notes/CVE-2021-20305

其中：

• maximumUnfixableSeverity 和 maximumFixableSeverity 针对常见漏洞和威胁 (CVE) 定义了 Kritis Signer 在创建证明时最大限度能够容忍的严重级别；如果超过该严重级别，Kritis Signer 便不会创建证明。maximumUnfixableSeverity 定义了当前没有修复可用的漏洞的严重程度阈值。maximumFixableSeverity 定义了当前有修复可用的漏洞的严重程度阈值。maximumUnfixableSeverity 和 maximumFixableSeverity 均可设置为以下严重级别之一：

  • CRITICAL
  • HIGH
  • MEDIUM
  • LOW

  如需详细了解严重级别，请参阅严重级别。

  或者，您也可以将 maximumUnfixableSeverity 和 maximumFixableSeverity 设置为以下项：

  • BLOCK_ALL：发现任何漏洞时，不会创建证明。
  • ALLOW_ALL：始终创建证明。

• allowlistCVEs 是要列入许可名单的特定 CVE 的列表。在评估是否要创建证明时，Kritis Signer 会忽略此列表中的 CVE。许可名单中的每个条目都必须与该 CVE 在 Artifact Analysis 中的备注名称完全匹配。详细了解 Artifact Analysis 漏洞来源。如需详细了解备注，请参阅元数据存储。

创建 Cloud KMS 签名密钥

Cloud Key Management Service 密钥用于创建证明。

1. 创建名为 KEY_RING 的新 Cloud KMS 密钥环：

   gcloud kms keyrings create KEY_RING \
      --location global
   

2. 在密钥环中创建名为 KEY_NAME 的新 Cloud KMS 密钥：

   gcloud kms keys create KEY_NAME \
       --keyring KEY_RING \
       --location global \
       --purpose "asymmetric-signing" \
       --default-algorithm "rsa-sign-pkcs1-2048-sha256"
   

3. 将摘要算法和 Cloud KMS 存储在环境变量中，以供后续步骤使用：

   export KMS_DIGEST_ALG=SHA256
   export KMS_KEY_NAME=projects/$PROJECT_ID/locations/global/keyRings/KEY_RING/cryptoKeys/KEY_NAME/cryptoKeyVersions/1
   

注意：要了解其他签名算法，请参阅创建非对称密钥。

定义备注名称

所有证明都引用 Artifact Analysis 备注。Kritis Signer 会自动为给定名称创建备注。您也可以重复使用现有的备注名称。

export NOTE_ID=my-signer-note
export NOTE_NAME=projects/${PROJECT_ID}/notes/${NOTE_ID}

在 Cloud Build 流水线中使用 Kritis Signer 创建证明

本部分演示了如何使用 Kritis Signer 自定义 Cloud Build 构建器，根据漏洞扫描结果创建 Binary Authorization 证明。

以下步骤演示了 Kritis Signer 如何使用 Kritis Signer 代码库中的示例构建配置文件。每个示例配置文件都包含以下构建步骤：

1. 用于构建 Docker 容器映像的 docker build 步骤。
2. docker push 步骤，用于将新构建的容器映像推送到 Container Registry。

3. vulnsign 步骤，用于通过以下方式检查容器映像并进行签名：

   1. 等待 Artifact Analysis 返回在新构建的容器映像中发现的漏洞结果。
   2. 根据政策中的漏洞签名规则检查发现结果。
   3. 如果发现结果符合漏洞规则，请创建证明。

您可以将每个示例构建提交到 Cloud Build。每个构建都会产生漏洞结果：

• 失败案例：漏洞结果违反了漏洞签名规则。此构建失败，并且不会创建任何证明。
• 成功案例：漏洞结果符合漏洞签名规则。此构建成功，并创建证明。

提交属于失败案例的示例构建

在本部分中，您将构建容器映像并扫描漏洞。构建失败，因为容器映像基于 Debian 10 的特定快照，该快照包含许多严重级别为 HIGH 的漏洞。这些漏洞违反了漏洞签名规则。因此，构建器不会生成证明。

1. （可选）查看失败案例的漏洞签名政策文件。

   cat samples/signer/policy-strict.yaml
   

   注意：此构建配置文件还包含用户定义的替代变量。替代变量是在构建流水线中使用的变量，通过包含 --substitutions 参数的 gcloud builds submit 命令传入。

2. 提交构建：

   gcloud builds submit \
     --substitutions=_KMS_KEY_NAME=$KMS_KEY_NAME,_KMS_DIGEST_ALG=$KMS_DIGEST_ALG,_NOTE_NAME=$NOTE_NAME \
     --config=samples/signer/cloudbuild-bad.yaml samples/signer
   

   您将看到如下所示的输出内容：

   "ERROR: (gcloud.builds.submit) build BUILD_ID completed with status "FAILURE"
   

3. 保存上一个构建的构建 ID：

   export BUILD_ID=$(gcloud builds list --limit=1 --format="value('ID')")
   

4. 验证结果：

    gsutil cat gs://${PROJECT_NUMBER}.cloudbuild-logs.googleusercontent.com/log-${BUILD_ID}.txt | grep "does not pass VulnzSigningPolicy"
   

提交属于成功案例的示例构建

在本部分中，您将构建一个容器映像，其中所包含的漏洞没有违反漏洞签名规则。在此示例中，Kritis Signer 自定义构建器会创建一项证明。

重要提示：在此示例中，创建证明是因为关联的漏洞签名政策配置为非常宽松，而不是因为映像没有明显的漏洞。此方法仅用于说明目的，不适用于生产目的。

如需将属于成功案例的示例构建提交到 Cloud Build，请运行以下命令：

1. （可选）查看成功案例的漏洞签名政策文件。

   cat samples/signer/policy-loose.yaml
   

   注意：此构建配置文件还包含用户定义的替代变量。替代变量是在构建流水线中使用的变量，通过包含 --substitutions 参数的 gcloud builds submit 命令传入。

2. 提交构建：

   gcloud builds submit \
     --substitutions=_KMS_KEY_NAME=$KMS_KEY_NAME,_KMS_DIGEST_ALG=$KMS_DIGEST_ALG,_NOTE_NAME=$NOTE_NAME \
     --config=samples/signer/cloudbuild-good.yaml samples/signer
   

3. 保存上一个构建的构建 ID：

   export BUILD_ID=$(gcloud builds list --limit=1 --format="value('ID')")
   

4. 验证结果：

   gcloud builds describe $BUILD_ID | grep status
   

以“仅检查”模式使用 Kritis Signer

本部分介绍如何在 check-only 模式下使用 Kritis Signer。在此模式下，Kritis Signer 不会创建证明。它只会检查映像中是否存在漏洞，然后根据漏洞签名规则使构建步骤成功完成或失败退出。

提交属于失败案例的示例构建

1. （可选）查看失败案例的漏洞签名政策文件。

   cat samples/policy-check/policy-strict.yaml
   

   请注意，在 Kritis Signer 构建步骤中，mode 标志设置为 check-only。

2. 提交构建：

   gcloud builds submit \
     --config=samples/policy-check/cloudbuild-bad.yaml samples/policy-check
   

   请注意，构建失败。

3. 保存上一个构建的构建 ID：

   export BUILD_ID=$(gcloud builds list --limit=1 --format="value('ID')")
   

4. 验证结果：

    gsutil cat gs://${PROJECT_NUMBER}.cloudbuild-logs.googleusercontent.com/log-${BUILD_ID}.txt | grep "does not pass VulnzSigningPolicy"
   

提交属于成功案例的示例构建

1. （可选）查看成功案例的漏洞签名政策文件。

   cat samples/policy-check/policy-loose.yaml
   

2. 提交构建：

   gcloud builds submit \
    --config=samples/policy-check/cloudbuild-good.yaml samples/policy-check
   

3. 保存上一个构建的构建 ID：

   export BUILD_ID=$(gcloud builds list --limit=1 --format="value('ID')")
   

4. 验证结果：

   gcloud builds describe $BUILD_ID | grep status
   

创建证明者

如需创建要求提供使用本指南中所述方法创建的证明的政策，您必须先创建证明者。

如需创建证明者，请执行以下操作：

1. 从您在本指南前面部分中创建的 Cloud KMS 密钥检索公钥资料：

   gcloud kms keys versions get-public-key 1 \
   --key KEY_NAME \
   --keyring KEY_RING \
   --location global \
   --output-file OUTPUT_PATH
   

   • KEY_NAME：密钥名称
   • KEY_RING：密钥环名称
   • OUTPUT_PATH：文件路径，例如 my-key.pem

2. 使用该文件中的公钥材料和您在本指南前面部分中创建的备注来创建证明者。您可以通过 Google Cloud 控制台或 gcloud CLI 创建证明者。

3. 创建要求提供证明的政策，并提供您在本部分创建的证明者。您可以通过 Google Cloud 控制台或 gcloud CLI 创建政策

创建证明

如需使用证明者创建证明，请参阅使用 Cloud KMS 创建证明。

清理

如需清理本文档中使用的资源，您可以删除相关项目：

gcloud projects delete ${PROJECT_ID}

后续步骤

• GitHub 上的 Kritis Signer 文档
• Binary Authorization 概览
• 通过 Google Cloud Console 或命令行工具创建证明者
• 通过 Google Cloud Console 或命令行工具配置政策以要求提供证明
• 使用 Voucher 创建证明
• Artifact Analysis 和漏洞扫描
• Cloud Build 社区和自定义 Cloud Build 构建器