GSP521

概览

在实验室挑战赛中，我们会为您提供一个场景和一系列任务。您将使用从课程的各个实验中学到的技能自行确定如何完成这些任务，而不是按照分步说明进行操作。自动评分系统（显示在本页面中）会提供有关您是否已正确完成任务的反馈。

在您参加实验室挑战赛期间，我们不会再教授新的 Google Cloud 概念知识。您需要拓展所学的技能，例如通过更改默认值和查看并研究错误消息来更正您自己所犯的错误。

要想获得满分，您必须在该时间段内成功完成所有任务！

建议已报名参加保护软件交付流程课程的学员参加此实验室挑战赛。准备好接受挑战了吗？

挑战场景

您是 Cymbal Bank 的一名软件工程师，负责将新的 Web 应用安全部署到云端。该应用将处理敏感的客户数据，因此安全性至关重要。您的目标是实现一条稳健的自动化流水线，用于构建、扫描、签名并部署容器化应用，同时遵守严格的安全标准。在本挑战赛中，您将使用 Artifact Registry、Binary Authorization 和 Cloud Build 等 Google Cloud 服务，在示例应用上实现此目标。

测试的主题

• 创建 Artifact Registry 仓库：设置 Artifact Registry 仓库，以存储用于扫描和生产的 Docker 映像。
• 推送 Docker 映像：通过 Cloud Build 构建 Docker 映像并将其推送到 Artifact Registry，以便进行漏洞扫描。
• 设置 Binary Authorization：使用证明者和密钥配置 Binary Authorization，以强制执行映像签名政策。
• 查看漏洞扫描：检查 Artifact Registry 中的漏洞扫描结果，以识别和了解潜在的安全风险。
• 创建安全的 CI/CD 流水线：构建 Cloud Build 流水线，自动执行映像构建、漏洞扫描和映像签名。
• 查看和修复：分析因严重漏洞而失败的构建，并修复应用代码中的问题。
• 重新构建和部署：使用修复后的代码重新运行 CI/CD 流水线，并确保成功部署到 Cloud Run。

设置和要求

点击“开始实验”按钮前的注意事项

请阅读以下说明。实验是计时的，并且您无法暂停实验。计时器在您点击开始实验后即开始计时，显示 Google Cloud 资源可供您使用多长时间。

此实操实验可让您在真实的云环境中开展实验活动，免受模拟或演示环境的局限。为此，我们会向您提供新的临时凭据，您可以在该实验的规定时间内通过此凭据登录和访问 Google Cloud。

为完成此实验，您需要：

• 能够使用标准的互联网浏览器（建议使用 Chrome 浏览器）。

注意：请使用无痕模式（推荐）或无痕浏览器窗口运行此实验。这可以避免您的个人账号与学生账号之间发生冲突，这种冲突可能导致您的个人账号产生额外费用。

• 完成实验的时间 - 请注意，实验开始后无法暂停。

注意：请仅使用学生账号完成本实验。如果您使用其他 Google Cloud 账号，则可能会向该账号收取费用。

任务 1. 启用 API 并设置环境

在开始构建安全的 CI/CD 流水线之前，您需要启用必要的 Google Cloud API 并设置开发环境。这将确保您可以使用所有必需的服务和工具。

1. 启用本实验所需的 API：

gcloud services enable \ cloudkms.googleapis.com \ run.googleapis.com \ cloudbuild.googleapis.com \ container.googleapis.com \ containerregistry.googleapis.com \ artifactregistry.googleapis.com \ containerscanning.googleapis.com \ ondemandscanning.googleapis.com \ binaryauthorization.googleapis.com

2. 在 Cloud Shell 中运行以下命令，以下载示例 Python、Docker 和 Cloud Build 文件：

mkdir sample-app && cd sample-app gcloud storage cp gs://spls/gsp521/* .

3. 创建两个 Artifact Registry 仓库：一个用于扫描，另一个用于生产。将这两个仓库分别命名为 artifact-scanning-repo 和 artifact-prod-repo。

扫描仓库用于存储在扫描漏洞之前的 Docker 映像，而生产仓库用于存储已签名并准备好部署的映像。

点击检查我的进度以验证是否完成了以下目标：

启用 API 并设置 Artifact Registry。

任务 2. 创建 Cloud Build 流水线

在此任务中，您将首先创建一个基本的 Cloud Build 配置，以构建 Docker 映像并将其推送到 Artifact Registry，从而为 CI/CD 流水线打下坚实的基础。完成这一初始步骤后，您可以在本实验的后续步骤中扫描映像是否存在漏洞。

1. 首先，将以下角色添加到 Cloud Build 服务账号：

   • roles/iam.serviceAccountUser
   • roles/ondemandscanning.admin

2. 在 Cloud Shell Editor 中，打开 sample-app/cloudbuild.yaml 文件。

3. 完成待办事项：填写映像名称占位符 (<image-name>)。为此，您需要引用 artifact-scanning-repo 仓库，映像名称应为 sample-image。请务必使用 区域。

4. 提交构建。

5. 查看您推送到 artifact-scanning-repo 仓库的映像，并验证您是否可以在扫描结果中看到一些严重漏洞。

点击检查我的进度以验证是否完成了以下目标：

创建 Cloud Build 流水线。

任务 3. 设置 Binary Authorization

为了对容器部署强制执行严格的安全政策，您将利用 Binary Authorization。借助此服务，您可以定义谁可以在什么条件下部署哪些映像。在此任务中，您将创建并配置 Binary Authorization 的必要组件，包括证明者、备注和 KMS 密钥。这将帮助您做好准备，将 Binary Authorization 集成到 CI/CD 流水线中。

创建证明者

1. 在 Cloud Shell 中，创建一个 JSON 文件。此文件将定义包含证明提示的证明者备注。证明提示的 human_readable_name 应设置为“Container Vulnerabilities attestation authority”（容器漏洞证明授权方）。

2. 使用 Container Analysis API 创建 ID 为 vulnerability_note 的新备注。该备注的详细信息应在上一步中创建的备注文件中定义。请确保在 API 请求中包含正确的身份验证，并设置对应的 Content-Type 标头。

3. 使用 Container Analysis API 检索您刚刚创建的证明者备注的详细信息。请确保在 API 请求中包含正确的身份验证。

4. 使用 gcloud 命令行工具创建新的 Binary Authorization 证明者。证明者 ID 应为 vulnerability-attestor，并且应与您之前创建的证明者备注相关联。

5. 使用 gcloud 命令行工具列出所有现有的 Binary Authorization 证明者。验证您刚刚创建的证明者是否包含在列表中。

6. 构建 IAM 政策，向 Binary Authorization 服务账号授予 roles/containeranalysis.notes.occurrences.viewer 角色，使其能够访问您创建的证明者备注。然后，使用 Container Analysis API 为该备注设置此 IAM 政策。

生成 KMS 对

在本部分，您将生成一个 KMS 密钥对来签署证明。

1. 设置密钥管理：

   • 在 global 位置创建一个名为 binauthz-keys 的 KMS 密钥环，以便存储密钥。
   • 在此密钥环中，生成一个新的非对称签名密钥对。将此密钥命名为 lab-key，并确保它是版本 1。

2. 将密钥关联到证明者：

   • 使用 gcloud 命令行工具将 lab-key（版本 1）与您的 Binary Authorization 证明者相关联。引用密钥时，请务必指定 global 位置和 binauthz-keys 密钥环。

更新 Binary Authorization 政策

1. 修改政策：调整 Binary Authorization 政策，以强制执行默认规则的证明要求。

2. 纳入证明者：将您之前创建的 vulnerability-attestor 纳入政策配置。

点击检查我的进度以验证是否完成了以下目标：

创建证明者、KMS 对并更新政策。

任务 4. 创建包含漏洞扫描的 Cloud Build CI/CD 流水线

以任务 2 中构建的基础流水线为起点，您现在将为其集成关键安全功能，以提升其能力。其中包括用于识别容器映像中潜在弱点的漏洞扫描功能，以及用于确保映像完整性的映像签名。在此任务中，您将把漏洞扫描和映像签名集成到 CI/CD 流水线中，使其更加稳健和安全。

向 Cloud Build 服务账号添加所需角色

1. 在您的项目中为 Cloud Build 服务账号授予以下 IAM 角色：

   • roles/binaryauthorization.attestorsViewer
   • roles/cloudkms.signerVerifier
   • roles/containeranalysis.notes.attacher
   • roles/iam.serviceAccountUser
   • roles/ondemandscanning.admin

2. 此外，还要确保 Compute Engine 默认服务账号也具有 cloudkms.signerVerifier 角色。

执行“自定义构建”步骤

1. 在 Cloud Build 中，您将使用自定义构建步骤来简化证明流程。Google 提供了此自定义构建步骤，其中包含一些辅助函数，可用于简化流程。在使用前，必须将自定义构建步骤的代码构建到容器中，并推送到 Cloud Build。要执行此操作，请运行以下命令：

git clone https://github.com/GoogleCloudPlatform/cloud-builders-community.git cd cloud-builders-community/binauthz-attestation gcloud builds submit . --config cloudbuild.yaml cd ../.. rm -rf cloud-builders-community

更新 Cloud Build 流水线

在本部分，您将完成 Cloud Build 流水线，使其包含漏洞扫描、严重性检查、映像签名，并部署到 Cloud Run。下面提供的代码是该流水线的部分实现。您需要填写缺失的部分才能完成流水线。

1. 完成待办事项：填写流水线的缺失部分，包括：
   • 指定 Artifact Registry 中的映像位置以进行漏洞扫描。请注意，您要扫描 artifact-scanning-repo 仓库中的映像。
   • 为漏洞检查设置适当的严重级别。如果发现任何严重漏洞，该流水线应该会失败。
   • 使用正确的证明者和 KMS 密钥信息配置映像签名步骤。证明者名称为 vulnerability-attestor，密钥版本是 lab-key 版本 1 的完整路径。
   • 为映像重新添加生产环境标记，并将其推送到生产环境仓库中。为此，您应该使用 artifact-prod-repo 仓库。
   • 将映像部署到 Cloud Run。在此步骤中，您将使用 artifact-prod-repo 仓库中的生产映像。

注意：在本实验的第二个任务中，您已经填写了 cloudbuild.yaml 文件中的前几个待办事项。请务必将剩余的占位符替换为剩余待办事项的正确值。

cloudbuild.yaml

steps: # TODO: #1. Build Step. Replace the <image-name> placeholder with the correct value. - id: "build" name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', '<image-name>', '.'] waitFor: ['-'] # TODO: #2. Push to Artifact Registry. Replace the <image-name> placeholder with the correct value. - id: "push" name: 'gcr.io/cloud-builders/docker' args: ['push', '<image-name>'] # TODO: #3. Run a vulnerability scan. Replace the <image-name> placeholder with the correct value. - id: scan name: 'gcr.io/cloud-builders/gcloud' entrypoint: 'bash' args: - '-c' - | (gcloud artifacts docker images scan \ <image-name> \ --location us \ --format="value(response.scan)") > /workspace/scan_id.txt # TODO: #4. Analyze the result of the scan. IF CRITICAL vulnerabilities are found, fail the build. # Replace the <correct vulnerability> placeholders with the correct values. Case sensitive! - id: severity check name: 'gcr.io/cloud-builders/gcloud' entrypoint: 'bash' args: - '-c' - | gcloud artifacts docker images list-vulnerabilities $(cat /workspace/scan_id.txt) \ --format="value(vulnerability.effectiveSeverity)" | if grep -Fxq <correct vulnerability>; \ then echo "Failed vulnerability check for <correct vulnerability> level" && exit 1; else echo \ "No <correct vulnerability> vulnerability found, congrats !" && exit 0; fi # TODO: #5. Sign the image only if the previous severity check passes. # Replace the placeholders with the correct values: <image-name>, <attestor-name>, and <key-version>. # Note the <key-version> should be the **full** path to the key version. - id: 'create-attestation' name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest' args: - '--artifact-url' - '<image-name>' - '--attestor' - '<attestor-name>' - '--keyversion' - '<key-version>' # TODO: #6. Re-tag the image for production and push it to the production repository using the latest tag. # Replace the <image-name> and <production-image-name> placeholders with the correct values. - id: "push-to-prod" name: 'gcr.io/cloud-builders/docker' args: - 'tag' - '<image-name>' - '<production-image-name>' - id: "push-to-prod-final" name: 'gcr.io/cloud-builders/docker' args: ['push', '<production-image-name>'] # TODO: #7. Deploy to Cloud Run. Replace the <image-name> and <your-region> placeholders with the correct values. - id: 'deploy-to-cloud-run' name: 'gcr.io/cloud-builders/gcloud' entrypoint: 'bash' args: - '-c' - | gcloud run deploy auth-service --image=<image-name> \ --binary-authorization=default --region=<your-region> --allow-unauthenticated # TODO: #8. Replace <image-name> placeholder with the valueplaceholder with the value from the build step. images: - <image-name>

3. 触发构建：

   • 提交您创建的 Cloud Build 配置，以启动构建流程。
   • 提交构建时，请注意您所使用的区域。

4. 查看构建失败情况：

   • 前往 Google Cloud 控制台中的 Cloud Build 记录页面。
   • 找到您刚刚触发的构建，并检查其状态。
   • 确认构建因存在严重级别为 CRITICAL 的漏洞而失败的情况。

注意：由于存在严重级别为 CRITICAL 的漏洞，您的构建应该会失败。您将在下一个任务中解决此问题。

点击检查我的进度以验证是否完成了以下目标：

将漏洞扫描功能集成到 CI/CD 流水线中。

任务 5. 修复漏洞并重新部署 CI/CD 流水线

在实际场景中，漏洞扫描通常会发现需要解决的问题。此任务模拟了这样一种场景：由于存在严重漏洞，您的构建失败了。在此任务中，您将分析构建失败的原因，找出漏洞，并通过更新应用的依赖项来修复漏洞。然后，您将重新触发 Cloud Build 流水线，以确保构建成功完成，并且没有任何严重漏洞。

1. 更新 Dockerfile：修改 Dockerfile 以使用 python:3.8-alpine 基础映像。将 Flask、Gunicorn 和 Werkzeug 依赖项更新为以下版本：

   • Flask：3.0.3
   • Gunicorn：23.0.0
   • Werkzeug：3.0.4

2. 重新触发构建：提交更新后的 Cloud Build 配置，以启动新的构建。

3. 验证构建是否成功：检查 Cloud Build 记录页面，确认构建已成功完成，并没有 CRITICAL 漏洞问题。

4. 为了进行测试，请运行以下命令，允许未经身份验证而访问 Cloud Run 服务，以便验证部署。将 <your-region> 替换为您部署服务的区域。

gcloud beta run services add-iam-policy-binding --region=<your-region> --member=allUsers --role=roles/run.invoker auth-service 注意：此命令仅用于测试目的，不应在生产环境中使用！

5. 验证部署：访问 Cloud Run 服务网址，确保您的应用已部署且运行正常。

点击检查我的进度以验证是否完成了以下目标：

修复漏洞并重新部署 CI/CD 流水线。

恭喜！

恭喜！在本实验中，您成功实现了一条安全的 CI/CD 流水线，可用于构建、扫描、签署和部署 Web 应用到云端。通过这次实操体验，您已经掌握了在云端构建和部署安全应用的基本技能，能够将安全最佳实践融入开发工作流，并确保软件交付流程的完整性。

后续步骤/了解详情

请查看以下资源，详细了解本实验中介绍的主题：

• Binary Authorization 文档
• 快速入门：使用 GKE 配置 Binary Authorization 政策
• Artifact Analysis 和漏洞扫描

Google Cloud 培训和认证

…可帮助您充分利用 Google Cloud 技术。我们的课程会讲解各项技能与最佳实践，可帮助您迅速上手使用并继续学习更深入的知识。我们提供从基础到高级的全方位培训，并有点播、直播和虚拟三种方式选择，让您可以按照自己的日程安排学习时间。各项认证可以帮助您核实并证明您在 Google Cloud 技术方面的技能与专业知识。

上次更新手册的时间：2025 年 12 月 10 日

上次测试实验的时间：2025 年 9 月 4 日

版权所有 2026 Google LLC 保留所有权利。Google 和 Google 徽标是 Google LLC 的商标。其他所有公司名和产品名可能是其各自相关公司的商标。