常见问题解答 DevSecOps

了解有关使用 DevSecOps 的常见问题解答。

CI 和 CC 管道有什么区别？

您可能会注意到，CI 和 CC 管道有共同的步骤。所进行的扫描和检查在性质和细节上都大同小异。下表列出了 CI 和 CC 管道之间的区别。

CI 和 CC 管道的区别
CI 管道	CC 管道
它是 CI 工具链的一部分。	它是 CC 工具链的一部分。
它在合并请求与 `master` 分支合并后触发	它可以手动触发，也可以按预定的时间间隔触发，与部署计划无关。
在设置过程中，需要输入应用程序 URL 和应用程序代码库的详细信息。	在配置CC工具链之后，在首次启动流水线运行之前，将提供应用程序 URL 和应用程序代码仓库的详细信息。
在合规性检查过程中，作为各种扫描和检查的一部分而产生的事件问题没有截止日期。	在合规性检查过程中，作为各种扫描和检查的一部分而创建的事件问题都有一个到期日。
所产生的事件问题是在构建过程中发现的。	创建的事件问题是在对暂存或生产环境进行定期扫描时发现的。
`summary.json` 文件不会在每次 CI 管道运行结束时生成。	`summary.json` 文件不会在每次 CI 管道运行结束时生成。
它包括应用程序构件创建、构件签名和部署到开发集群等步骤。这反过来又为 CD 管道提供了输入。	它只运行合规性测试所需的扫描和检查。

用户如何定制管道？

管道可通过使用自定义脚本进行定制。自定义脚本是管道中的扩展点，采用者、团队和用户可在此提供脚本，为其 CI/CD 策略运行自定义任务。

自定义脚本可控制管道的各个阶段。您可以使用配置文件 (pipeline-config.yaml) 来配置阶段行为、脚本内容和运行脚本的基础工具。管道阶段的脚本和配置从类似于 .travis.yml 或 Jenkinsfile 的应用程序资源库或自定义资源库加载。

有关更多信息，请参阅使用自定义脚本自定义管道。

针对 s390x 和 Power 平台限制的多操作系统映像

One-Pipeline 在 one-pipeline 配置文件中使用 runtimeClassName （表示运行时配置文件的字符串）为 s390x 和 Power 平台提供本地支持。不过，这种本地支持也有一些限制和建议：

限制：
- 此功能仅在 v11 中可用。
- pod 的启动时间高于 x86 运行时类。
- 您必须在 s390x 或 Power 工作负载中使用 podman。 Docker 不可用。
  - 用户脚本需要更新，以便使用 podman 命令而不是 docker 命令
  - 舞台镜像应安装 podman。
建议：使用 x86 运行时类进行
- 扫描，因为各种扫描工具的图像可能都不支持多层结构。
- 图像签名，因为不支持多操作系统（工作正在进行中）。

如何构建自定义的多架构基础镜像？

One Pipeline 提供了一个官方的多架构基础镜像，支持以下平台：

linux/amd64
linux/ppc64le
linux/s390x

对于大多数使用场景，我们建议直接使用官方基础镜像：

icr.io/continuous-delivery/toolchains/devsecops/baseimage:<version>

如果您的应用程序需要额外的操作系统软件包、语言运行时或其他自定义依赖项，您可以作为 CI 管道的一部分，构建自己的自定义多架构基础镜像。

在您的 build-artifact 步骤中，使用 Docker Buildx 并指定 --platform 选项：

docker buildx build \
  --platform linux/amd64,linux/ppc64le,linux/s390x \
  -t <registry>/<namespace>/<image>:<tag> \
  --push .

该操作会构建特定于架构的镜像，并将它们发布为一个多架构镜像清单。容器运行时会自动为目标平台拉取相应的镜像。

建议的做法

在您的 Dockerfile 中，将 One Pipeline 基础镜像用作 FROM 镜像。
请仅添加您的应用程序所需的额外软件包或依赖项。
在您的 CI 管道中，使用 Docker Buildx 构建并发布镜像。
请使用 docker buildx imagetools inspect 或 skopeo inspect 验证已发布的图片。

有关多架构支持及其限制的更多信息，请参阅《 s390x 和Power平台多架构镜像的限制》。

使用 CLI 触发流水线

可以使用 IBM Cloud CLI 或 API 触发管道。使用 CLI，您可以通过提供工具链和管道 ID 来启动管道。您可以使用应用程序接口发送带有正确验证和标头的 POST 请求，以触发管道。

更多信息，请参阅使用触发器

克隆 Git 仓库时使用了哪个环境变量？

DevSecOps 管道采用分层令牌系统来验证 Git 仓库的操作，包括克隆操作。 git-token 环境属性用作默认令牌，但您可以使用更具体的令牌覆盖它，以实现更强的安全性和访问控制。

令牌优先级顺序

该管道按以下优先级顺序（从高到低）解析 Git 身份验证令牌：

特定存储库的工具链集成中指定的个人访问令牌 (PAT)
仓库专用令牌：git-token-[repo_name]-[repo_org]
特定于组织的令牌：git-token-[repo_org]
默认令牌：git-token
OAuth 代币 来自工具链集成（如果使用 OAuth 而非PAT）

代币命名示例

对于位于 https://github.com/my-org/my-app 的仓库：

针对特定仓库：git-token-my-app-my-org
针对特定组织的：git-token-my-org

重要注意事项

如果同一组 git-token 既用于读取仓库（克隆），又用于写入操作（设置PR/CI状态、更新库存），则仅具备只读权限是不够的。该令牌必须具有写入权限。
使用仓库或组织专属令牌，可让您遵循最小权限原则，仅为每个仓库授予必要的权限。

有关存储库令牌功能的更多信息，请参阅《检索存储库信息和令牌》。

如何测试对 OnePipeline 配置的更改？

测试 OnePipeline 配置的更改需要采取系统化的方法，以便在验证自定义设置的同时，避免中断生产管道。

了解 OnePipeline 的组件

OnePipeline 由两个主要的可自定义组件组成：

Tekton 管道定义：针对 PR、CI、CD 和 CC 工作流的集中管理型管道定义（可在 compliance-pipelines 仓库中获取）。新版本每两周发布一次。
- v10：稳定版，并发数有限
- v11：新一代版本，具备极高的可定制性和并发能力
管道配置（.pipeline-config.yaml ）：自定义配置文件，用于覆盖默认管道行为，包括管道镜像、脚本、体系结构和属性。该文件可以存储在您的应用程序存储库中，也可以存储在集中式配置存储库中。

测试方法 1：使用测试配置文件

这是在不影响生产管道的情况下测试配置更改的推荐方法。

创建一个测试分支
- 在包含您的 .pipeline-config.yaml 文件的仓库中创建一个分支
- 请在此分支中进行配置更改
设置测试触发器
- 在您的工具链中复制现有的管道触发器
- 请明确命名（例如：Manual-Test-Config ）
- 更新触发器属性，使其指向您的测试配置：
  - pipeline-config: 配置文件的文件名
  - pipeline-config-branch: 您的测试分支名称
  - pipeline-config-repo: 包含配置的仓库 URL
在开发模式下进行测试
- 在触发器属性中启用开发模式
- 运行管道以验证您的自定义脚本
- 开发模式会跳过证据收集、合规问题创建和库存更新，因此非常适合快速迭代
- 重要提示：开发模式不适用于生产环境的工作负载
包含合规性检查的测试
- 在开发模式下验证脚本后，请禁用 dev-mode
- 测试期间保持库存更新功能处于禁用状态
- 运行包含证据收集和问题管理的完整流程
- 验证所有合规性检查是否均按预期通过
升级到生产级别
- 当测试结果令人满意时，请创建一个拉取请求，将您的更改合并到主分支
- 这些更改将自动应用于生产环境中的触发器
- 如果出现问题，您可以快速撤销这些更改

测试方法 2：修改管道布局

分支管道定义 （高级）

（分叉 compliance-pipelines 仓库）
在您的分支中开发并测试更改
在您的工具链中将分叉的仓库添加为 Git 集成
暂时更新管道定义，使其引用您的分支
配置一个开发模式触发器，以测试新的管道定义
请按照方法 1 中的测试步骤进行操作

最佳实践

请务必先在开发模式下进行测试，以便快速发现脚本错误
为测试触发器使用描述性名称，以避免混淆
在提交信息中记录配置变更
请保持测试触发器处于禁用状态，或在测试结束后将其删除，以防止意外触发
建议针对重大管道变更创建专用的测试工具链
仔细检查管道日志，以确保所有阶段均按预期执行

有关自定义管道的更多信息，请参阅 “自定义脚本”和