CNCF社区首个！KubeEdge到达软件供给链SLSA L3品级_互联网资讯__分享互联网新鲜有趣好玩的事物-云易优站长平台

摘要：在v1.13.0版本中，KubeEdge项目已到达 SLSAL3品级（包罗二进造和容器镜像构件），成为CNCF社区首个到达SLSA L3品级的项目。

本文分享自华为云社区《CNCF社区首个！云原生边沿计算KubeEdge到达软件供给链SLSA L3品级-云社区-华为云》，做者：KubeEdge SIG-Security （首发于KubeEdge博客[1]）

KubeEdge社区已于2022年7月份完成整个KubeEdge项目标第三方平安审计[2]，已发布云原生边沿计算平安威胁阐发和防护白皮书，并按照平安威胁模子和平安审计的建议，对KubeEdge软件供给链停止持续平安加固。颠末社区的不竭勤奋，我们很兴奋地颁布发表，在2023年1月18日发布的v1.13.0版本中，KubeEdge项目已到达 SLSA[3] L3品级（包罗二进造和容器镜像构件），成为CNCF社区首个到达SLSA L3品级的项目。

为什么到达SLSA L3品级对KubeEdge项目非常重要

软件供给链完好性攻击（对软件包的未经受权的修改）在过去三年中呈上升趋向，KubeEdge实现SLSA L3品级尺度后，能够端到端的从源码构建到发布流程停止平安加固，保障用户获取到的二进造或容器镜像产品不被歹意窜改。基于SLSA平安框架，能够潜在地加强软件构件的完好性。SLSA供给端到端的指点原则，能够做为软件的一组防御办法，并避免对构成软件产物的软件包的窜改或任何类型的未经受权的修改。接纳SLSA框架能够庇护项目软件免受常见的供给链攻击。

关于SLSA

什么是SLSA（Supply chain Levels for Software Artifacts软件构件的供给链级别）：

Google提出的用于包管整个软件供给链完好性的框架SLSA，是一套基于行业共识的平安原则，也是一个平安框架、一份尺度和控造清单，用于避免窜改、进步完好性以及庇护项目、营业或企业中的软件包和根底设备。它不是一个单一的东西，而是一个逐渐接纳的纲领，以避免工件被窜改和被窜改的工件被利用，并在更高条理上强化构成供给链的平台。消费商遵照SLSA原则使他们的软件愈加平安，用户则按照软件包的平安情况来做出决策。

截行目前，SLSA尺度处于alpha阶段，相关的定义可能会发作变革。

下图描述了软件供给链中已知的攻击点。更多详细描述，可参考https://slsa.dev/ 。

SLSA框架引入了许多新的东西和概念，例如：

• Artifact（软件成品）：由构建流水线生成的任何成品文件，如容器镜像、语言包、编译的二进造文件等；

• PRovenance （来源证据链）：构建的元数据包罗构建过程、构建源和依赖关系；

• Digest （数字摘要）：加密哈希函数的成果，该函数生成独一标识工件的固定大小值，例如容器镜像的SHA-256哈希；

• Attestation （证书）：一个加密签名的文件，记录其时生成软件产品的来源；

• Immutable references（不成变引用-一种标识符）：，包管始末指向不异的、不成变的软件成品，如特定的容器图像或语言包；

• Build integrity（构建完好性）：验证构建流水线的输出完好性。

KubeEdge项目若何到达SLSA L3

截行目前，SLSA评估品级共分为4个品级L1~L4，平安性由低到高，每个品级有差别的达标要求，详细的达标要求可参考SLSA详细尺度（https://slsa.dev/sPEc/v0.1/requirements ）。

在去年7月发布的第三方平安审计陈述中，KubeEdge项目在软件供给链SLSA Provenance维度暂未到达L3品级，颠末SIG-Security的持续平安加固，在本年1月发布的v1.13.0版本中，KubeEdge项目在所有的SLSA维度中均到达L3品级。以下表格展现了KubeEdge在Source、Build、Provenance、Common中的达标情况（Y暗示KubeEdge已达标，空格暗示SLSA在该品级下未要求）。

SLSA评估表格及达标情况

本章节将着重介绍KubeEdge若何达成SLSA L3品级在Build、Provenance维度的要求。Build/Provenance Requirements及KubeEdge响应的处理计划如下。

Build Requirements：

a) 通过脚本构建：所有的构建步调都是通过脚本主动化施行。

b) 通过构建办事停止构建：所有的构建步调由构建办事完成，不在开发者当地情况。构建办事如GitHub Actions、第三方云平台供给的构建办事等。

c) 做为源码构建：构建办事施行的构建定义文件和设置装备摆设文件来源于版本控造系统中的文本文件，而且是可验证的。

d) 构建情况临时性：构建办事确保构建步调在临时情况中运行，例如容器或VM，仅为此构建供给，而不是复用先前的构建。

e) 构建的隔离性：构建办事确保构建步调在隔离的情况中运行，不受其他构建实例(无论是先前的仍是并发的)的影响。

f) 无用户自定义参数：除了构建入口点和初始源设置装备摆设之外，构建输出不会遭到用户参数的影响。换句话说，构建完满是通过构建脚本定义的，而不是其他。

g) 封锁性：所有可传递的构建步调、源和依赖项都利用不成变引用预先完全声明，而且构建步调在没有收集拜候的情况下运行。

处理计划：

KubeEdge项目所有的构建流程均在GitHub上由脚本主动化施行，GitHub Actions做为构建办事（相关的定义文件和设置装备摆设文件保留在.github/workflows目次下），可保障构建过程的可回溯、可验证以及构建情况的临时性、隔离性、构建参数和依赖项不成窜改。

Provenance Requirements：

a) 可用性：Provenance通过用户可承受的格局供给。应该满足SLSA Provenance格局，但若是消费商和用户都同意，而且满足所有其他要求，能够利用另一种格局。

b) 可验证：Provenance的实在性和完好性能够由用户验证。那应该通过来无私钥的数字签名来实现，只要生成Provenance的办事才气拜候私钥。

c) 通过构建办事生成：Provenance中的数据必需从构建办事中获得。

d) 不成伪造：构建办事的用户不克不及伪造Provenance。

e) 第三方依赖的完好性：Provenance记录运行构建步调时可用的所有构建依赖项。包罗构建的机器、VM或容器的初始形态。

处理计划：

在KubeEdge版本发布的产品中，包罗二进造文件和容器镜像2种格局，通过集成SLSA官方的GitHub构建项目slsa-github-generator来实现SLSA L3品级。

在KubeEdge版本发布的流程（.github/workflows/release.yml）中，集成了slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml和slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml，可保障构建和发布产品（包罗二进造文件和容器镜像）的流程满足SLSA L3品级的要求。

更多关于slsa-github-generator的详细申明请见https://github.com/slsa-framework/slsa-github-generator 。

关于Provenance

Provenance是构建的元数据包罗构建过程、构建源和依赖关系，是软件构建和发布施行流程的一种证明，而且是能够被验证的，包罗构建的源码仓库、代码分收、设置装备摆设文件等信息。在SLSA L3级别，Provenance内容是实在的、防窜改的，而且不会被项目维护者更改。二进造发布产品的Provenance文件随发布软件包一路发布，名称为multiple.intoto.jsonl，容器镜像的Provenance文件随镜像文件一路上传到KubeEdge dockerhub公开仓库中。详细的Provenance格局申明，请参考https://github.com/slsa-framework/slsa-github-generator/blob/main/internal/builders/generic/README.md#provenance-format。

若何校验KubeEdge发布产品能否满足SLSA L3品级

详细步调描述请见https://github.com/kubeedge/kubeedge/pull/4285 。

校验示例如下：

$ COSIGN_EXPERIMENTAL=1 cosign verify-attestation --type slsaprovenance --policy policy.cue kubeedge/clouDCore:v1.13.0{ "_type": "https://in-toto.io/Statement/v0.1", "predicateType": "https://slsa.dev/provenance/v0.2", "subject": [{ "name": "index.docker.io/kubeedge/cloudcore", "digest": { "sha256": "825642e63ab5b924e2fa0661cd14d544d0be151c4bdba6f3f42796c977fbe211" } } ], "predicate": { "builder": { "id": "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@refs/tags/v1.4.0" }, "buildType": "https://github.com/slsa-framework/slsa-github-generator/container@v1", "invocation": { "configSource": { "uri": "git+https://github.com/kubeedge/kubeedge@refs/tags/v1.13.0",SLSA GitHub generator签名和验证原理

利用 OpenID Connect (OIDC) 向外部办事 (Sigstore) 证明工做流的身份。OpenID Connect (OIDC) 是身份供给商在收集上利用的尺度，用于为第三方证明用户的身份。 GitHub 如今在其工做流程中撑持 OIDC。每次运行工做流程时，运行者都能够从 GitHub 的 OIDC 供给商处创建一个独一的 JWT 令牌。令牌包罗工做流身份的可验证信息，包罗挪用者存储库、提交哈希、触发器以及当前（可重用）工做流途径和引用。

利用 OIDC，工做流向 Sigstore 的 Fulcio 根证书颁布机构证明其身份，后者充任外部验证办事。 Fulcio 签订了一份短期证书，证明运行器中生成的临时签名密钥并将其与工做负载身份相联系关系。签订出处的记录保留在 Sigstore 的通明日记 Rekor 中。用户能够利用签名证书做为信赖方来验证来源能否颠末身份验证且不成伪造；它必需是在受信赖的构建器中创建的。流程图如下所示。