Container Scanning

原文:https://docs.gitlab.com/ee/user/application_security/container_scanning/

Container Scanning

Introduced in GitLab Ultimate 10.4.

Overview

应用程序的 Docker 映像本身可能基于包含已知漏洞的 Docker 映像. 通过在管道中包含一个额外的作业来扫描这些漏洞并将其显示在合并请求中,您可以使用 GitLab 来审核基于 Docker 的应用程序. 默认情况下,GitLab 中的容器扫描基于ClairKlar ,这是用于对容器中的漏洞进行静态分析的开源工具. GitLab 的 Klar 分析仪扫描容器并用作 Clair 的包装纸.

注意:要将除 Clair 和 Klar 以外的其他安全扫描器集成到 GitLab 中,请参阅” 安全扫描器集成” .

您可以通过执行以下任一操作来启用容器扫描:

GitLab 比较发现的源分支与目标分支之间的漏洞,并在合并请求中直接显示信息.

Container Scanning Widget

Requirements

要在管道中启用容器扫描,您需要以下内容:

  • 带有DockerKubernetes执行器的GitLab Runner .
  • Docker 18.09.03或更高版本与 Runner 安装在同一台计算机上. 如果您在 GitLab.com 上使用共享的 Runners,那么情况已经如此.
  • 构建 Docker 镜像并将其推送到项目的容器注册表中. Docker 映像的名称应使用以下预定义的环境变量

    1. $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA

    您可以在.gitlab-ci.yml文件中直接使用它们:

    1. build:
    2. image: docker:19.03.12
    3. stage: build
    4. services:
    5. - docker:19.03.12-dind
    6. variables:
    7. IMAGE_TAG: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA
    8. script:
    9. - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    10. - docker build -t $IMAGE_TAG .
    11. - docker push $IMAGE_TAG

Configuration

启用容器扫描的方式取决于您的 GitLab 版本:

要包括Container-Scanning.gitlab-ci.yml模板(GitLab 11.9 及更高版本),请将以下内容添加到您的.gitlab-ci.yml文件中:

  1. include:
  2. - template: Container-Scanning.gitlab-ci.yml

包含的模板:

  • 在 CI / CD 管道中创建container_scanning作业.
  • 从项目的Container Registry 中拉出已构建的 Docker 映像(请参阅要求 ),并扫描其可能的漏洞.

GitLab 将结果保存为” 容器扫描”报告工件 ,您可以稍后下载和分析. 下载时,您始终会收到最新的工件.

以下是一个示例.gitlab-ci.yml ,用于构建您的 Docker 映像,将其推送到 Container Registry 并扫描容器:

  1. variables:
  2. DOCKER_DRIVER: overlay2
  3. stages:
  4. - build
  5. - test
  6. build:
  7. image: docker:stable
  8. stage: build
  9. services:
  10. - docker:19.03.12-dind
  11. variables:
  12. IMAGE: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA
  13. script:
  14. - docker info
  15. - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
  16. - docker build -t $IMAGE .
  17. - docker push $IMAGE
  18. include:
  19. - template: Container-Scanning.gitlab-ci.yml

Customizing the Container Scanning settings

There may be cases where you want to customize how GitLab scans your containers. For example, you may want to enable more verbose output from Clair or Klar, access a Docker registry that requires authentication, and more. To change such settings, use the variables parameter in your .gitlab-ci.yml to set environment variables. The environment variables you set in your .gitlab-ci.yml overwrite those in Container-Scanning.gitlab-ci.yml.

此示例包括容器扫描模板,并通过将CLAIR_OUTPUT环境变量设置为High来启用 Clair 的详细输出:

  1. include:
  2. - template: Container-Scanning.gitlab-ci.yml
  3. variables:
  4. CLAIR_OUTPUT: High

Available variables

可以使用环境变量配置容器扫描.

环境变量 Description Default
SECURE_ANALYZERS_PREFIX 设置用于下载分析器的 Docker 注册表基地址. "registry.gitlab.com/gitlab-org/security-products/analyzers"
KLAR_TRACE 设置为 true 可启用 klar 的更多详细输出. "false"
CLAIR_TRACE 设置为 true 可启用 clair 服务器进程的更多详细输出. "false"
DOCKER_USER 用于访问需要身份验证的 Docker 注册表的用户名. $CI_REGISTRY_USER
DOCKER_PASSWORD 访问需要身份验证的 Docker 注册表的密码. $CI_REGISTRY_PASSWORD
CLAIR_OUTPUT 严重级别阈值. 严重级别高于或等于此阈值的漏洞将被输出. 支持的级别为UnknownNegligibleLowMediumHighCriticalDefcon1 . Unknown
REGISTRY_INSECURE 允许Klar访问不安全的注册表(仅 HTTP). 仅应在本地测试图像时设置为true . "false"
DOCKER_INSECURE 允许Klar使用带有错误(或自签名)SSL 证书的 HTTPS 访问安全的 Docker 注册表. "false"
CLAIR_VULNERABILITIES_DB_URL (不推荐使用-改为使用CLAIR_DB_CONNECTION_STRING )此变量在Container-Scanning.gitlab-ci.yml文件的services 部分中显式设置,并且默认为Container-Scanning.gitlab-ci.yml clair-vulnerabilities-db . 该值表示托管漏洞定义PostgreSQL 服务器正在运行的地址,除非您按照” 运行独立容器扫描工具”部分中的说明在本地运行映像,否则不应更改该地址. clair-vulnerabilities-db
CLAIR_DB_CONNECTION_STRING 该变量表示托管漏洞定义数据库的PostgreSQL 服务器连接字符串 ,除非您按照” 运行独立容器扫描工具”部分中的说明在本地运行映像,否则不应更改该变量. 连接字符串的主机值必须与Container-Scanning.gitlab-ci.yml模板文件的别名值匹配,该别名默认为clair-vulnerabilities-db . postgresql://postgres:password@clair-vulnerabilities-db:5432/postgres?sslmode=disable&statement_timeout=60000
CI_APPLICATION_REPOSITORY Docker repository URL for the image to be scanned. $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG
CI_APPLICATION_TAG 待扫描图像的 Docker 存储库标签. $CI_COMMIT_SHA
CLAIR_DB_IMAGE 托管漏洞定义PostgreSQL 服务器的 Docker 映像名称和标记. 使用特定版本覆盖此值可能很有用,例如,为了进行集成测试而提供一致的漏洞集,或在本地进行脱机安装时引用本地托管的漏洞数据库. arminc/clair-db:latest
CLAIR_DB_IMAGE_TAG (不推荐使用-改为使用CLAIR_DB_IMAGE托管漏洞定义PostgreSQL 服务器的 Docker 映像标记. 可以使用特定版本覆盖此值,例如,为集成测试目的提供一致的漏洞集很有用. latest
DOCKERFILE_PATH 用于生成补救的Dockerfile的路径. 默认情况下,扫描程序将在项目的根目录中查找名为Dockerfile的文件,因此仅当您的Dockerfile位于非标准位置(例如子目录)时,才应配置此变量. 有关更多详细信息,请参见漏洞解决方案 . Dockerfile
ADDITIONAL_CA_CERT_BUNDLE 您要信任的 CA 证书捆绑包. ””
SECURE_LOG_LEVEL 可用的日志级别为: fatalerrorwarninfodebug info

Overriding the Container Scanning template

如果要覆盖作业定义(例如,更改诸如variables属性),则必须在container_scanning模板之后声明一个container_scanning作业,然后指定任何其他键. 例如:

  1. include:
  2. - template: Container-Scanning.gitlab-ci.yml
  3. container_scanning:
  4. variables:
  5. GIT_STRATEGY: fetch

Deprecated: GitLab 13.0 and later doesn’t support only and except. When overriding the template, you must use rules instead.

Vulnerability allowlisting

要允许列表特定漏洞,请按照下列步骤操作:

  1. 设置GIT_STRATEGY: fetch按照覆盖容器扫描模板中的说明, GIT_STRATEGY: fetch .gitlab-ci.yml文件.
  2. 在名为vulnerability-allowlist.yml的 YAML 文件中定义允许列出的漏洞. 这必须使用许可清单示例文件中描述的格式.
  3. vulnerability-allowlist.yml文件添加到项目的 Git 存储库中.

Running Container Scanning in an offline environment

对于在通过互联网有限,受限或间歇性访问外部资源的环境中进行自我管理的 GitLab 实例,需要进行一些调整才能使容器扫描作业成功运行. 有关更多信息,请参阅脱机环境 .

Requirements for offline Container Scanning

要在脱机环境中使用容器扫描,您需要:

注意: GitLab Runner 的默认pull policyalways ,这意味着即使本地副本可用,Runner 也会尝试从 GitLab 容器注册表中拉取 Docker 映像. 如果您只喜欢使用本地可用的 Docker 映像,则可以在离线环境pull_policy GitLab Runner 的pull_policy设置为if-not-present . 但是,如果不在离线环境中,我们建议将拉取策略设置保持为always ,因为这样可以在 CI / CD 管道中使用更新的扫描仪.

Make GitLab Container Scanning analyzer images available inside your Docker registry

对于容器扫描,将以下默认图像从registry.gitlab.com导入本地 Docker 容器注册表

  1. registry.gitlab.com/gitlab-org/security-products/analyzers/klar
  2. https://hub.docker.com/r/arminc/clair-db

将 Docker 映像导入本地脱机 Docker 注册表的过程取决于您的网络安全策略 . 请咨询您的 IT 员工,以找到可以导入或临时访问外部资源的已接受和批准的流程. 请注意,这些扫描程序会定期使用新定义进行更新 ,因此请考虑您是否能够自己进行定期更新.

有关更多信息,请参见有关如何使用管道更新映像的特定步骤 .

有关将 Docker 映像保存和传输为文件的详细信息,请参阅 Docker 有关docker savedocker loaddocker exportdocker import的文档.

Set Container Scanning CI job variables to use local Container Scanner analyzers

  1. 覆盖 .gitlab-ci.yml文件中的容器扫描模板 ,以引用本地 Docker 容器注册表中托管的 Docker 映像:

    1. include:
    2. - template: Container-Scanning.gitlab-ci.yml
    3. container_scanning:
    4. image: $CI_REGISTRY/namespace/gitlab-klar-analyzer
    5. variables:
    6. CLAIR_DB_IMAGE: $CI_REGISTRY/namespace/clair-vulnerabilities-db
  2. 如果您的本地 Docker 容器注册表正在通过HTTPS安全运行,但是您使用的是自签名证书,则必须在.gitlab-ci.yml的上述container_scanning部分中将DOCKER_INSECURE: "true"设置为.

Automating Container Scanning vulnerability database updates with a pipeline

设置计划的管道以按照预设的计划自动构建漏洞数据库的新版本可能是值得的. 使用管道自动执行此操作意味着您不必每次都手动进行操作. 您可以使用以下.gitlab-yml.ci作为模板:

  1. image: docker:stable
  2. stages:
  3. - build
  4. build_latest_vulnerabilities:
  5. stage: build
  6. services:
  7. - docker:19.03.12-dind
  8. script:
  9. - docker pull arminc/clair-db:latest
  10. - docker tag arminc/clair-db:latest $CI_REGISTRY/namespace/clair-vulnerabilities-db
  11. - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
  12. - docker push $CI_REGISTRY/namespace/clair-vulnerabilities-db

上面的模板适用于在本地安装上运行的 GitLab Docker 注册表,但是,如果您使用的是非 GitLab Docker 注册表,则需要更改$CI_REGISTRY值和 Docker docker login凭据以匹配以下内容:您的本地注册表.

Running the standalone Container Scanning Tool

可以对 Docker 容器运行GitLab 容器扫描工具 ,而无需在 CI 作业的上下文中运行它. 要直接扫描图像,请按照下列步骤操作:

  1. Run Docker Desktop or Docker Machine.
  2. 运行最新的预填充漏洞数据库 Docker 映像:

    1. docker run -p 5432:5432 -d --name clair-db arminc/clair-db:latest
  3. Configure an environment variable to point to your local machine’s IP address (or insert your IP address instead of the LOCAL_MACHINE_IP_ADDRESS variable in the CLAIR_DB_CONNECTION_STRING in the next step):

    1. export LOCAL_MACHINE_IP_ADDRESS=your.local.ip.address
  4. 运行分析器的 Docker 映像,并在CI_APPLICATION_REPOSITORYCI_APPLICATION_TAG环境变量中传递要分析的映像和标签:

    1. docker run \
    2. --interactive --rm \
    3. --volume "$PWD":/tmp/app \
    4. -e CI_PROJECT_DIR=/tmp/app \
    5. -e CLAIR_DB_CONNECTION_STRING="postgresql://postgres:password@${LOCAL_MACHINE_IP_ADDRESS}:5432/postgres?sslmode=disable&statement_timeout=60000" \
    6. -e CI_APPLICATION_REPOSITORY=registry.gitlab.com/gitlab-org/security-products/dast/webgoat-8.0@sha256 \
    7. -e CI_APPLICATION_TAG=bc09fe2e0721dfaeee79364115aeedf2174cce0947b9ae5fe7c33312ee019a4e \
    8. registry.gitlab.com/gitlab-org/security-products/analyzers/klar

结果存储在gl-container-scanning-report.json .

Reports JSON format

容器扫描工具会发出 JSON 报告文件. 有关更多信息,请参见此报告架构 .

这是示例容器扫描报告:

  1. { "version": "2.3", "vulnerabilities": [ { "id": "ac0997ad-1006-4c81-81fb-ee2bbe6e78e3", "category": "container_scanning", "message": "CVE-2019-3462 in apt", "description": "Incorrect sanitation of the 302 redirect field in HTTP transport method of apt versions 1.4.8 and earlier can lead to content injection by a MITM attacker, potentially leading to remote code execution on the target machine.", "severity": "High", "confidence": "Unknown", "solution": "Upgrade apt from 1.4.8 to 1.4.9", "scanner": { "id": "klar", "name": "klar" }, "location": { "dependency": { "package": { "name": "apt" }, "version": "1.4.8" }, "operating_system": "debian:9", "image": "registry.gitlab.com/gitlab-org/security-products/dast/webgoat-8.0@sha256:bc09fe2e0721dfaeee79364115aeedf2174cce0947b9ae5fe7c33312ee019a4e" }, "identifiers": [ { "type": "cve", "name": "CVE-2019-3462", "value": "CVE-2019-3462", "url": "https://security-tracker.debian.org/tracker/CVE-2019-3462" } ], "links": [ { "url": "https://security-tracker.debian.org/tracker/CVE-2019-3462" } ] } ], "remediations": [ { "fixes": [ { "id": "c0997ad-1006-4c81-81fb-ee2bbe6e78e3" } ], "summary": "Upgrade apt from 1.4.8 to 1.4.9", "diff": "YXB0LWdldCB1cGRhdGUgJiYgYXB0LWdldCB1cGdyYWRlIC15IGFwdA==" } ] }

Security Dashboard

安全仪表板向您显示组,项目和管道中所有安全漏洞的概述.

Vulnerabilities database update

有关漏洞数据库更新的更多信息,请查看维护表 .

Interacting with the vulnerabilities

一旦发现漏洞,便可以与其进行交互 .

Solutions for vulnerabilities (auto-remediation)

可以通过应用 GitLab 自动生成的解决方案来修复某些漏洞.

为了使整治的支持,对扫描工具必须能够访问Dockerfile指定由DOCKERFILE_PATH环境变量. 为确保扫描工具可以访问此文件,有必要设置GIT_STRATEGY: fetch按照本文档中” 覆盖容器扫描模板”部分中介绍的说明,在.gitlab-ci.yml文件中进行GIT_STRATEGY: fetch .

阅读有关漏洞解决方案的更多信息.

Troubleshooting

docker: Error response from daemon: failed to copy xattrs

当 GitLab Runner 使用 Docker 执行程序并使用 NFS 时(例如, /var/lib/docker在 NFS 挂载上),容器扫描可能会失败,并显示以下错误:

  1. docker: Error response from daemon: failed to copy xattrs: failed to set xattr "security.selinux" on /path/to/file: operation not supported.

这是由于 Docker 中的一个错误而导致的,该错误现已修复 . 为避免该错误,请确保 Runner 使用的 Docker 版本为18.09.03或更高. 有关更多信息,请参见问题#10241 .