2.8. 保护构建过程

使用 OpenShift Container Platform 作为容器构建的标准平台可保证构建环境的安全。遵循“一次构建，随处部署”的原则可确保构建过程的产品就是在生产环境中部署的产品。

保持容器的不可变性也是很重要的。您不应该修补运行中的容器，而应该重建并重新部署这些容器。

随着您的软件逐步进入构建、测试和生产阶段，组成软件供给链的工具必须是可信的。下图演示了可整合到容器化软件的可信软件供应链中的流程和工具：

OpenShift Container Platform 可以与可信代码存储库（如 GitHub）和开发平台（如 Che）集成，用于创建和管理安全代码。单元测试可以依赖 Cucumber 和 JUnit。您可以通过 Anchore 或 Twistlock 检查容器中的漏洞和合规问题，并使用镜像扫描工具，如 AtomicScan 或 Clair。Sysdig 等工具可以提供对容器化应用程序的持续监控。

您可以使用 Source-to-Image (S2I) 将源代码和基础镜像组合起来。构建器镜像利用 S2I 使您的开发和运维团队能够就可重复生成的构建环境展开合作。对于可作为通用基础镜像 (UBI) 镜像的 Red Hat S2I 镜像，您现在可以使用从真实 RHEL RPM 软件包构建的基础镜像自由重新分发您的软件。红帽取消了订阅限制以允许这一操作。

当开发人员使用构建镜像通过 Git 提交某个应用程序的代码时，OpenShift Container Platform 可以执行以下功能：

您可以使用集成的 OpenShift Container Registry 来管理对最终镜像的访问。S2I 和原生构建镜像会自动推送到 OpenShift Container Registry。

除了包含的用于 CI 的 Jenkins 外，您还可以使用 RESTful API 将您自己的构建和 CI 环境与 OpenShift Container Platform 集成，并使用与 API 兼容的镜像 registry。

在某些情况下，构建操作需要凭证才能访问依赖的资源，但这些凭证最好不要在通过构建生成的最终应用程序镜像中可用。您可以定义输入 secret 以实现这一目的。

例如，在构建 Node.js 应用程序时，您可以为 Node.js 模块设置私有镜像。要从该私有镜像下载模块，您必须为包含 URL、用户名和密码的构建提供自定义的 .npmrc 文件。为安全起见，不应在应用程序镜像中公开您的凭证。

通过使用此示例场景，您可以在新 BuildConfig 对象中添加输入 secret：

您可以对容器镜像管理和构建过程进行设计以使用容器层，以便您可以分开控制。

例如，一个运维团队负责管理基础镜像，而架构师则负责管理中间件、运行时、数据库和其他解决方案。然后开发人员可以专注于应用程序层并专注于编写代码。

由于每天都会识别出新的漏洞，因此您需要一直主动检查容器内容。要做到这一点，您应该将自动安全测试集成到构建或 CI 过程中。例如：

您的 CI 过程应该包含相应的策略，为构建标记出通过安全扫描发现的问题，以便您的团队能够采取适当行动来解决这些问题。您应该为自定义构建容器签名，以确保在构建和部署之间不会修改任何内容。

利用 GitOps 方法，您不仅可以使用相同的 CI/CD 机制来管理应用程序配置，还可以管理 OpenShift Container Platform 基础架构。

通过使用 Kubernetes 和 Kourier，您可以在 OpenShift Container Platform 中使用 OpenShift Serverless 来构建、部署和管理无服务器应用程序。

和其他构建一样，您可以使用 S2I 镜像来构建容器，然后使用 Knative 服务提供它们。通过 OpenShift Container Platform Web 控制台的 Topology 视图 查看 Knative 应用程序构建。