本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

在火山口邊緣跳舞：Kubernetes 安全流程 - 詳解

作者：Brandon Philips (CoreOS), Jess Frazelle (Google) |

執行在伺服器上的軟體支撐著世界上不斷增長的商業、通訊和物理基礎設施。幾乎所有這些系統都連線到網際網路；這意味著必須迅速應用重要的安全更新。作為軟體開發人員和 IT 專業人員，我們常常發現自己身處火山邊緣：我們可能因為安全漏洞在修復之前被利用而陷入岩漿般的遺忘，或者我們可能因為處理安全漏洞的流程不足而滑下山坡。

Kubernetes 社群相信，我們可以透過建立在 Kubernetes 基礎上的平臺，幫助團隊在這個火山上恢復立足點。而這個基礎的基石，需要一個快速確認、修補和向不斷增長的 Kubernetes 使用者社群釋出安全更新的流程。

擁有超過 1200 名貢獻者和超過一百萬行程式碼，每一次 Kubernetes 釋出都是一項巨大的工程，由勇敢的志願者釋出經理負責。這些常規釋出是完全透明的，過程公開進行。然而，安全釋出必須以不同的方式處理，以在修復方案提供給使用者之前，讓潛在攻擊者矇在鼓裡。

我們借鑑了其他開源專案，建立了Kubernetes 安全釋出流程。與定期釋出不同，安全釋出必須以加速的時間表交付，我們為此成立了產品安全團隊來處理這一流程。

該團隊迅速選出一名負責人來協調工作，並管理與漏洞披露者和 Kubernetes 社群的溝通。安全釋出流程還記錄了使用通用漏洞評分系統 (CVSS) 3.0 版計算器衡量漏洞嚴重程度的方法。這一計算有助於在節假日或開發人員頻寬有限的情況下，為釋出節奏決策提供資訊。透過使嚴重性標準透明化，我們能夠更好地設定預期並在事件期間達到關鍵時間線，我們努力實現以下目標：

  • 在 24 小時內回應報告漏洞的人員或團隊，並組建負責修復的開發團隊
  • 在披露後 7 天內向使用者披露即將釋出的修復方案
  • 在披露後 14 天內向供應商提前通知
  • 在披露後 21 天內釋出修復方案

隨著我們不斷強化 Kubernetes，安全釋出流程將有助於確保 Kubernetes 仍然是一個安全的網際網路規模計算平臺。如果您有興趣瞭解更多關於安全釋出流程的資訊，請觀看 KubeCon Europe 2017 YouTube 上的演示，並查閱幻燈片。如果您有興趣瞭解 Kubernetes 中的身份驗證和授權，以及 Kubernetes 叢集安全模型，請考慮加入 Kubernetes SIG Auth。我們還希望在下一次 Kubernetes 社群活動中看到您參加安全相關的演講和小組討論：2017 年 5 月 31 日和 6 月 1 日在舊金山舉行的 CoreOS Fest 2017。

作為對 Kubernetes 社群的感謝，使用程式碼 k8s25code 或透過此特殊八五折連結註冊 CoreOS Fest 2017，可享受 CoreOS Fest 的特別八五折優惠。