Flux项目谈安全：镜像来源

关于 Flux 项目谈安全的博客系列的下一篇文章将介绍我们如何以及为什么要为 Flux CLI 及其所有控制器镜像使用签名，以及你可以在工作流中做些什么来验证镜像来源。

自 Flux 0.26 以来，我们的安全文档添加了以下内容：

The Flux CLI and the controllers' images are signed using Sigstore[1] Cosign and GitHub OIDC. The container images along with their signatures are published on GitHub Container Registry and Docker Hub.

To verify the authenticity of Flux's container images, install cosign[2]and run:

代码语言：javascript复制

COSIGN_EXPERIMENTAL=1 cosign verify ghcr.io/fluxcd/source-controller:v0.21.1

Verification for ghcr.io/fluxcd/source-controller:v0.21.1
The following checks were performed on each of these signatures:>
- The cosign claims were validated
- Existence of the claims in the transparency log was verified offline
- Any certificates were verified against the Fulcio roots.

我们很高兴向你介绍这一点，并鼓励你在工作流程中使用它，以使你的集群更加安全。但是，让我们把上面这一节所说的全部内容都分解一下。

为什么要在一开始就签署发布工件？

从本质上说，我们希望你能够核实 Flux 的镜像来源，这可以归结为确保：

你刚刚下载的版本实际上来自我们——Flux 团队
它没有被篡改过

密码签名是这方面的首选，已经使用了几十年，但并不是没有挑战。

优秀的sigstore 文档[3]这样说的：

Software supply chains are exposed to multiple risks. Users are susceptible to various targeted attacks, along with account and cryptographic key compromise. Keys in particular are a challenge for software maintainers to manage. Projects often have to maintain a list of current keys in use, and manage the keys of individuals who no longer contribute to a project. Projects all too often store public keys and digests on git repo readme files or websites, two forms of storage susceptible to tampering and less than ideal means of securely communicating trust. The tool sets we've historically relied on were not built for the present circumstance of remote teams either. This can be seen by the need to create a web of trust, with teams having to meet in person and sign each others' keys. The current tooling (outside of controlled environments) all too often feel inappropriate to even technical users.

我们很高兴sigstore[4]的存在。这是一个由谷歌、红帽公司和普渡大学支持的 Linux 基金会项目，旨在为开源社区建立一个新的签名、验证和来源检查标准。

我们的 cosign 工作流使用：

cosign[5]来签署我们的发布工件，并将签名存储在 OCI 注册中心（在我们的例子中是 GHCR 和 Docker Hub）
OpenID Connect（OIDC）事先通过我们的电子邮件地址进行识别
Fulcio，根证书颁发机构（CA），它为已身份验证的用户颁发一个带有时间戳的证书
Rekor 作为透明日志存储，证书和签名元数据存储在一个可搜索的分类帐中，不会被篡改

这有很多术语和项目名称，但 cosign 的美妙之处在于，你可以使用 GitHub Actions 相对容易地集成它（看看它是如何在源代码控制器中完成[6]的）。

如何验证签名

如果你希望一次性手动完成此操作，安装 cosign 工具[7]并对要验证的镜像运行：

代码语言：javascript复制

COSIGN_EXPERIMENTAL=1 cosign verify ghcr.io/fluxcd/source-controller:v0.21.1

目前（cosign 1.5.1 版本）还需要 COSIGN_EXPERIMENTAL=1 来验证透明日志。

输出结果显示：

代码语言：javascript复制

Verification for ghcr.io/fluxcd/source-controller:v0.21.1
The following checks were performed on each of these signatures:
- The cosign claims were validated
- Existence of the claims in the transparency log was verified offline
- Any certificates were verified against the Fulcio roots.

现在让我们看看如何进一步实现自动化。

在集群中强制验证签名

幸运的是，cosign 与 Connaisseur、Kyverno 和 OPA Gatekeeper 等策略引擎兼容并支持。现在让我们以 Kyverno 为例。要确保 Flux 镜像签名已被验证，你只需要添加以下清单：

代码语言：javascript复制

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-flux-images
spec:
  validationFailureAction: enforce
  background: false
  webhookTimeoutSeconds: 30
  failurePolicy: Fail
  rules:
    - name: verify-cosign-signature
      match:
        resources:
          kinds:
            - Pod
      verifyImages:

现在列出所有需要验证的镜像。例如，对于 helm-controller，添加：

代码语言：javascript复制

      - image: "ghcr.io/fluxcd/helm-controller:*"
        repository: "ghcr.io/fluxcd/helm-controller"
        roots: |
          -----BEGIN CERTIFICATE-----
          MIIB9zCCAXygAwIBAgIUALZNAPFdxHPwjeDloDwyYChAO/4wCgYIKoZIzj0EAwMw
          KjEVMBMGA1UEChMMc2lnc3RvcmUuZGV2MREwDwYDVQQDEwhzaWdzdG9yZTAeFw0y
          MTEwMDcxMzU2NTlaFw0zMTEwMDUxMzU2NThaMCoxFTATBgNVBAoTDHNpZ3N0b3Jl
          LmRldjERMA8GA1UEAxMIc2lnc3RvcmUwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAAT7
          XeFT4rb3PQGwS4IajtLk3/OlnpgangaBclYpsYBr5i 4ynB07ceb3LP0OIOZdxex
          X69c5iVuyJRQ Hz05yi UF3uBWAlHpiS5sh0 H2GHE7SXrk1EC5m1Tr19L9gg92j
          YzBhMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBRY
          wB5fkUWlZql6zJChkyLQKsXF jAfBgNVHSMEGDAWgBRYwB5fkUWlZql6zJChkyLQ
          KsXF jAKBggqhkjOPQQDAwNpADBmAjEAj1nHeXZp 13NWBNa EDsDP8G1WWg1tCM
          WP/WHPqpaVo0jhsweNFZgSs0eE7wYI4qAjEA2WB9ot98sIkoF3vZYdd3/VtWB5b9
          TNMea7Ix/stJ5TfcLLeABLE4BNJOsQ4vnBHJ
          -----END CERTIFICATE-----

这里复制的证书是Fulcio（sigstore CA）的根证书[8]。请查看fluxcd/flux2-multi-tenancy[9]，以了解一个更详细的示例，以及 Kyverno 策略是如何应用到那里的。

通过验证我们所有的工件，你可以确保它们的来源，并保证它们从我们签署和发布的那一刻起就没有被修改过。这只是我们为确保你们的安全而采取的又一项措施。

参考资料

[1]Sigstore: https://www.sigstore.dev/

[2]cosign: https://docs.sigstore.dev/cosign/installation/

[3]sigstore 文档: https://docs.sigstore.dev/

[4]sigstore: https://www.sigstore.dev/

[5]cosign: https://docs.sigstore.dev/cosign/overview

[6]如何在源代码控制器中完成: https://github.com/fluxcd/source-controller/pull/550/files

[7]安装 cosign 工具: https://docs.sigstore.dev/cosign/installation

[8]Fulcio（sigstore CA）的根证书: https://github.com/SigStore/fulcio#status

[9]fluxcd/flux2-multi-tenancy: https://github.com/fluxcd/flux2-multi-tenancy

[10]开发会议: https://fluxcd.io/community/#meetings

[11]CNCF Slack: https://slack.cncf.io/

[12]采用者: https://fluxcd.io/adopters/

对象存储网络安全 react https

0 人点赞