Docker Scout 策略评估入门

目录

在软件供应链管理中，维护工件的安全性和可靠性是重中之重。Docker Scout 中的策略评估在现有分析功能的基础上引入了一层控制。它允许您为工件定义供应链规则，并帮助您跟踪工件随时间相对于您的规则和阈值的表现。

了解如何使用策略评估来确保您的工件符合既定的最佳实践。

策略评估如何工作

当您为存储库激活 Docker Scout 时，您推送的镜像会被自动分析。分析结果让您深入了解镜像的组成，包括它们包含的包以及它们面临的漏洞。策略评估建立在镜像分析功能之上，根据策略定义的规则解释分析结果。

策略定义了您的工件应满足的镜像质量标准。例如，**无 AGPL v3 许可**策略会标记任何包含以 AGPL v3 许可分发的包的镜像。如果镜像包含此类包，则该镜像不符合此策略。某些策略，例如**无 AGPL v3 许可**策略，是可配置的。可配置策略允许您调整标准以更好地满足您组织的需求。

在 Docker Scout 中，策略旨在帮助您提高安全性和供应链地位。与其他工具专注于提供通过或失败状态不同，Docker Scout 策略可视化了微小的增量变化如何影响策略状态，即使您的工件尚未满足策略要求。通过跟踪失败差距随时间的变化，您可以更容易地看到您的工件相对于策略是正在改善还是正在恶化。

策略不一定必须与应用程序安全和漏洞相关。您还可以使用策略来衡量和跟踪供应链管理的其他方面，例如开源许可使用情况和基础镜像的最新程度。

策略类型

在 Docker Scout 中，一个*策略*是从一个*策略类型*派生出来的。策略类型是定义策略核心参数的模板。您可以将策略类型与面向对象编程中的类进行比较，每个策略都充当从其相应策略类型创建的实例。

Docker Scout 支持以下策略类型

Docker Scout 会自动为启用它的存储库提供默认策略，但 SonarQube 质量门禁策略除外，该策略在使用前需要与 SonarQube 集成。

您可以根据任何受支持的策略类型创建自定义策略，或者删除不适用于您项目的默认策略。有关更多信息，请参阅配置策略。

基于严重性的漏洞

基于严重性的漏洞策略类型检查您的工件是否暴露于已知漏洞。

默认情况下，此策略仅标记具有可用修复版本的严重和高危漏洞。从本质上讲，这意味着对于不符合此策略的镜像，您可以部署一个简单的修复：将易受攻击的包升级到包含漏洞修复的版本。

如果镜像包含一个或多个不符合指定策略标准的漏洞，则认为该镜像不符合此策略。

您可以通过创建策略的自定义版本来配置此策略的参数。以下策略参数在自定义版本中可配置：

  • 年龄：漏洞首次发布以来的最短天数

    只标记达到一定最小年龄的漏洞的理由是，新发现的漏洞不应导致您的评估失败，直到您有机会解决它们。

  • 严重性：要考虑的严重性级别（默认：Critical, High）

  • 仅可修复漏洞：是否仅报告具有可用修复版本的漏洞（默认启用）。

  • 包类型：要考虑的包类型列表。

    此选项允许您指定要包含在策略评估中的包类型，作为 PURL 包类型定义。默认情况下，该策略会考虑所有包类型。

有关配置策略的更多信息，请参阅配置策略。

合规许可

合规许可策略类型检查您的镜像是否包含以不适当许可分发的包。如果镜像包含一个或多个具有此类许可的包，则认为该镜像不合规。

您可以配置此策略应查找的许可列表，并通过指定允许列表（以 PURL 形式）添加例外。请参阅配置策略。

最新基础镜像

最新基础镜像策略类型检查您使用的基础镜像是否最新。

如果用于构建镜像的标签指向的摘要与您正在使用的摘要不同，则认为该镜像不符合此策略。如果摘要不匹配，则表示您正在使用的基础镜像已过时。

您的镜像需要出处证明才能成功评估此策略。有关更多信息，请参阅无基础镜像数据。

高危漏洞

高危漏洞策略类型检查您的镜像是否包含来自 Docker Scout 精选列表中的漏洞。此列表会及时更新，以包含广泛认为具有风险的新披露漏洞。

该列表包括以下漏洞：

您可以自定义此策略，通过配置策略来更改被视为高危的 CVE。自定义配置选项包括：

  • 排除的 CVE：指定您希望此策略忽略的 CVE。

    默认值：[]（不忽略任何高危 CVE）

  • CISA KEV：启用跟踪 CISA 已知被利用漏洞 (KEV) 目录中的漏洞

    CISA KEV 目录包含野外正在积极利用的漏洞。启用后，此策略会标记包含 CISA KEV 目录中漏洞的镜像。

    默认启用。

有关策略配置的更多信息，请参阅配置策略。

供应链证明

供应链证明策略类型检查您的镜像是否具有SBOM和出处证明。

如果镜像缺少 SBOM 证明或具有*最大模式*出处的出处证明，则认为它不合规。为确保合规性，请更新您的构建命令以在构建时附加这些证明：

$ docker buildx build --provenance=true --sbom=true -t <IMAGE> --push .

有关使用证明构建的更多信息，请参阅证明。

如果您使用 GitHub Actions 构建和推送镜像，请了解如何配置操作以应用 SBOM 和出处证明。

默认非 root 用户

默认情况下，容器以具有容器内完整系统管理权限的 root 超级用户身份运行，除非 Dockerfile 指定了不同的默认用户。以特权用户身份运行容器会削弱其运行时安全性，因为这意味着在容器中运行的任何代码都可以执行管理操作。

默认非 root 用户策略类型检测设置为以默认 root 用户身份运行的镜像。为了符合此策略，镜像必须在镜像配置中指定一个非 root 用户。如果镜像未为运行时阶段指定非 root 默认用户，则它们不符合此策略。

对于不合规的镜像，评估结果会显示是否为镜像显式设置了 root 用户。这有助于您区分由 root 用户隐式存在的镜像导致的策略违规，以及由故意设置 root 的镜像导致的策略违规。

以下 Dockerfile 默认以 root 身份运行，尽管未明确设置：

FROM alpine
RUN echo "Hi"

而在以下情况下，root 用户是明确设置的：

FROM alpine
USER root
RUN echo "Hi"
注意

此策略仅检查镜像的默认用户，如镜像配置 blob 中所设置。即使您确实指定了非 root 默认用户，仍然可以在运行时覆盖默认用户，例如通过对 docker run 命令使用 --user 标志。

要使您的镜像符合此策略，请使用 USER Dockerfile 指令为运行时阶段设置一个不具有 root 权限的默认用户。

以下 Dockerfile 片段显示了合规镜像和不合规镜像之间的区别。

FROM alpine AS builder
COPY Makefile ./src /
RUN make build

FROM alpine AS runtime
COPY --from=builder bin/production /app
ENTRYPOINT ["/app/production"]
FROM alpine AS builder
COPY Makefile ./src /
RUN make build

FROM alpine AS runtime
COPY --from=builder bin/production /app
USER nonroot
ENTRYPOINT ["/app/production"]

批准的基础镜像

批准的基础镜像策略类型确保您在构建中使用的基础镜像得到维护和安全。

此策略检查您的构建中使用的基础镜像是否与策略配置中指定的任何模式匹配。下表显示了此策略的一些示例模式。

用例模式
允许所有 Docker Hub 镜像docker.io/*
允许所有 Docker 官方镜像docker.io/library/*
允许来自特定组织的镜像docker.io/orgname/*
允许特定存储库的标签docker.io/orgname/repository:*
允许主机名为 registry.example.com 的注册表上的镜像registry.example.com/*
允许 NodeJS 镜像的 slim 标签docker.io/library/node:*-slim

星号 (*) 匹配直到紧随其后的字符，或直到镜像引用的末尾。请注意，为了匹配 Docker Hub 镜像，需要 docker.io 前缀。这是 Docker Hub 的注册表主机名。

此策略可配置以下选项：

  • 批准的基础镜像来源

    指定您要允许的镜像引用模式。策略会根据这些模式评估基础镜像引用。

    默认值：[*]（任何引用都是允许的基础镜像）

  • 仅受支持的标签

    使用 Docker 官方镜像时仅允许受支持的标签。

    启用此选项后，使用官方镜像不支持的标签作为其基础镜像的镜像会触发策略违规。官方镜像的受支持标签列在 Docker Hub 上的存储库概览的**受支持标签**部分。

    默认启用。

  • 仅受支持的操作系统分发版

    仅允许受支持的 Linux 分发版版本的 Docker 官方镜像。

    启用此选项后，使用已达到生命周期结束的（例如 ubuntu:18.04）不受支持的 Linux 分发版的镜像会触发策略违规。

    启用此选项可能会导致策略在无法确定操作系统版本时报告无数据。

    默认启用。

您的镜像需要出处证明才能成功评估此策略。有关更多信息，请参阅无基础镜像数据。

SonarQube 质量门禁

SonarQube 质量门禁策略类型建立在 SonarQube 集成之上，用于评估您的源代码质量。此策略通过将 SonarQube 代码分析结果摄取到 Docker Scout 来工作。

您使用 SonarQube 的质量门禁来定义此策略的标准。SonarQube 会根据您在 SonarQube 中定义的质量门禁评估您的源代码。Docker Scout 将 SonarQube 评估作为 Docker Scout 策略呈现。

Docker Scout 使用出处证明或 org.opencontainers.image.revision OCI 注释将 SonarQube 分析结果与容器镜像链接起来。除了启用 SonarQube 集成之外，您还必须确保您的镜像具有证明或标签。

Git commit SHA links image with SonarQube analysis

一旦您推送镜像并完成策略评估，SonarQube 质量门禁的结果将作为策略显示在 Docker Scout 控制面板和 CLI 中。

注意

Docker Scout 只能访问在集成启用后创建的 SonarQube 分析。Docker Scout 无法访问历史评估。在启用集成后触发 SonarQube 分析和策略评估，以在 Docker Scout 中查看结果。

无基础镜像数据

在某些情况下，无法确定构建中使用的基础镜像信息。在这种情况下，最新基础镜像和批准的基础镜像策略会被标记为**无数据**。

出现“无数据”状态的原因是：

  • Docker Scout 不知道您使用了哪个基础镜像标签
  • 您使用的基础镜像版本有多个标签，但并非所有标签都已过时

为确保 Docker Scout 始终了解您的基础镜像，您可以在构建时附加出处证明。Docker Scout 使用出处证明来查找基础镜像版本。

© . This site is unofficial and not affiliated with Kubernetes or Docker Inc.