CNCF社群首個！KubeEdge達到軟體供應鏈SLSA L3等級

華為雲開發者聯盟發表於2023-02-15
摘要：在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/ 。

CNCF社群首個！KubeEdge達到軟體供應鏈SLSA L3等級

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 中。使用者可以使用簽名證書作為信任方來驗證來源是否經過身份驗證且不可偽造；它必須是在受信任的構建器中建立的。流程圖如下所示。

CNCF社群首個！KubeEdge達到軟體供應鏈SLSA L3等級

值得一提的是，SLSA GitHub generator獲得sigstore社群2022年度徽章Best User Adopter。

CNCF社群首個！KubeEdge達到軟體供應鏈SLSA L3等級

總結

SLSA在KubeEdge專案軟體供應鏈安全中發揮著重要作用。基於sigstore社群提供的能力，從原始碼到釋出產物，對軟體供應鏈端到端的整個流程進行簽名和校驗，確保KubeEdge軟體供應鏈安全。

相關參考

[1]   KubeEdge官網部落格：https://kubeedge.io/zh/blog/reach-slsa-l3/

[2]    KubeEdge專案第三方安全審計：https://github.com/kubeedge/community/blob/master/sig-security/sig-security-audit/KubeEdge-security-audit-2022.pdf

[3]   SLSA官網：https://slsa.dev/

[4]   Sigstore官網：https://www.sigstore.dev/

[5]   SLSA Generator官網：https://github.com/slsa-framework/slsa-github-generator

[6]   SLSA3通用整合指導：https://slsa.dev/blog/2022/08/slsa-github-workflows-generic-ga

[7]   透過防篡改構建提高軟體供應鏈安全性：https://security.googleblog.com/2022/04/improving-software-supply-chain.html

[8]  Sigstore 11月綜述：https://blog.sigstore.dev/sigstore-november-roundup-8a852cec10fc/

 

點選關注，第一時間瞭解華為雲新鮮技術~

相關文章