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

CoreOS的首席技術(shù)官布蘭登·菲利普斯(Brandon Phillips)表示：“我們一直在火山邊緣徘徊，由于安全漏洞，我們可能會(huì )陷入其中。” “另一方面，我們可能會(huì )跌倒，因為我們沒(méi)有處理安全漏洞的流程，而且我們一直擔心火山另一側的不穩定。”

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

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

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

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

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

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

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

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