柏林—如何在開源Kubernetes容器編排和管理系統(tǒng)中處理安全漏洞披露?在柏林舉行的Kubecon / CloudNative歐盟會議上，這是一個僅在會議室舉行的會議上詳細(xì)回答的問題。盡管會議的標(biāo)題有些古怪，但“帶有安全釋放過程的火山唇上的瘋狂舞蹈”在標(biāo)題后面有特殊含義。

CoreOS的首席技術(shù)官布蘭登·菲利普斯(Brandon Phillips)表示：“我們一直在火山邊緣徘徊，由于安全漏洞，我們可能會陷入其中。” “另一方面，我們可能會跌倒，因?yàn)槲覀儧]有處理安全漏洞的流程，而且我們一直擔(dān)心火山另一側(cè)的不穩(wěn)定。”

但是，Kubernetes項(xiàng)目在最近幾個月采取了多個步驟來改進(jìn)其安全公開流程。與飛利浦共同出席會議的Google軟件工程師Jessie Frazelle指出，錯誤是不可避免的，將來有可能在Kubernetes中發(fā)現(xiàn)更多錯誤。菲利普斯開玩笑說，已經(jīng)發(fā)明了最安全的計算系統(tǒng)，它只是一個基本的計算器，沒有與其他任何東西連接。他補(bǔ)充說，一旦計算能力連接到外部世界，通常就會有相關(guān)的風(fēng)險。

Frazelle指出用戶希望軟件沒有錯誤，但是當(dāng)有錯誤時，他們想知道何時有可用的修補(bǔ)程序，以便他們可以更新其應(yīng)用程序。當(dāng)涉及到安全研究人員時，他們希望在提交錯誤后從供應(yīng)商和項(xiàng)目中進(jìn)行更新，并且還希望有明確的披露時間表。

對于某些類型的高嚴(yán)重性安全漏洞，通常最好在進(jìn)行修復(fù)后才對安全信息進(jìn)行禁運(yùn)。Frazelle評論說，可能發(fā)生的最糟糕的情況是，漏洞在修復(fù)之前就已公開，并且該漏洞擁有自己的昵稱和徽標(biāo)。

她說：“每個軟件錯誤都需要一個有趣的名字，除了我的任何錯誤之外。”

Kubernetes從中學(xué)到了許多處理其他公開源代碼工作的安全披露的最佳實(shí)踐。Phillips說，Linux內(nèi)核開發(fā)人員的政策是不與安全研究人員就披露時間表進(jìn)行協(xié)商。最好的做法通常是盡快修復(fù)一個錯誤，然后在修復(fù)后讓用戶知道。

其他開源項(xiàng)目已實(shí)施的另一種最佳實(shí)踐是某種形式的漏洞預(yù)警系統(tǒng)。使用這種方法，即使沒有在早期預(yù)警中提供有關(guān)bug的完整詳細(xì)信息，仍會提前通知用戶，以便他們在補(bǔ)丁可用后會為更新做好更充分的準(zhǔn)備。Phillips和Frazelle都還強(qiáng)調(diào)，用戶只需進(jìn)行簡單的Google搜索即可輕松找到該項(xiàng)目的安全披露文檔。還需要一個專門的安全響應(yīng)團(tuán)隊和某種形式的協(xié)調(diào)郵件列表。

從流程的角度來看，Phillips說，Kubernetes的工作方式目前是，安全修復(fù)響應(yīng)團(tuán)隊通常會在24小時內(nèi)響應(yīng)安全漏洞報告。修復(fù)安全漏洞可能需要一到七天的時間。修復(fù)完成后，會向Kubernetes用戶郵件列表發(fā)送“即將修復(fù)”通知。最終，完整的補(bǔ)丁程序公開信息和對發(fā)行版的可用性將在發(fā)出安全錯誤報告后的14天內(nèi)完成。

雖然Kubernetes確實(shí)有安全披露流程和政策，但Frazelle和Philips表示仍有改進(jìn)的空間，需要個人和供應(yīng)商的更多參與。