2.8. 保护构建过程

在容器环境中,软件构建过程是生命周期中应用程序代码与所需的运行时库集成的阶段。管理此构建过程是保护软件堆栈的关键。

2.8.1. 一次构建,随处部署

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

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

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

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

2.8.2. 管理构建

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

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

  • 通过使用代码存储库上的 Webhook 或其他自动持续集成 (CI) 过程进行触发,以从可用的工件、S2I 构建器镜像和新提交的代码中自动编译新镜像。
  • 自动部署新构建的镜像以进行测试。
  • 将测试镜像提升到生产环境中,以使用 CI 过程自动进行部署。
Source-to-Image 构建

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

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

2.8.3. 在构建期间保护输入

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

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

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

  1. 如果 secret 不存在,则进行创建:

    $ oc create secret generic secret-npmrc --from-file=.npmrc=~/.npmrc

    这会创建一个名为 secret-npmrc 的新 secret,其包含 ~/.npmrc 文件的 base64 编码内容。

  2. 将该 secret 添加到现有 BuildConfig 对象的 source 部分中:

    source:
      git:
        uri: https://github.com/sclorg/nodejs-ex.git
      secrets:
      - destinationDir: .
        secret:
          name: secret-npmrc
  3. 要在新 BuildConfig 对象中包含该 secret,请运行以下命令:

    $ oc new-build \
        openshift/nodejs-010-centos7~https://github.com/sclorg/nodejs-ex.git \
        --build-secret secret-npmrc

2.8.4. 设计构建过程

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

设计构建过程

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

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

  • SAST / DAST – 静态和动态安全测试工具。
  • 根据已知漏洞进行实时检查的扫描程序。这类工具会为您的容器中的开源软件包编目,就任何已知漏洞通知您,并在之前扫描的软件包中发现新漏洞时为您提供最新信息。

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

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

2.8.5. 构建 Knative 无服务器应用程序

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

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

2.8.6. 其他资源