本文已超過一年。較舊的文章可能包含過時的內容。請確認頁面中的資訊自發布以來是否已變得不正確。

在火山邊緣跳舞:Kubernetes 安全流程 - 說明

伺服器上運行的軟體支撐著世界上日益增長的商業、通訊和實體基礎設施。幾乎所有這些系統都連接到網際網路;這意味著必須快速應用重要的安全更新。作為軟體開發人員和 IT 專業人員,我們常常發現自己在火山邊緣跳舞:我們可能會因為在修復之前被利用的安全漏洞而墜入岩漿引起的遺忘,或者我們可能會因為解決安全漏洞的流程不足而從山腰滑落。 

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

Kubernetes 擁有超過 1,200 位貢獻者和超過一百萬行程式碼,Kubernetes 的每次發布都是一項龐大的工程,由勇敢的志願發布管理員負責。這些常規發布是完全透明的,並且流程公開進行。但是,安全發布必須以不同的方式處理,以在向使用者提供修復程式之前,讓潛在的攻擊者蒙在鼓裡。

我們從其他開源專案中汲取靈感,以創建Kubernetes 安全發布流程。與定期排程的發布不同,安全發布必須以加速的排程交付,並且我們創建了產品安全團隊來處理此流程。

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

  • 在 24 小時內回覆報告漏洞的人員或團隊,並安排開發團隊負責修復
  • 在揭露後 7 天內向使用者揭露即將到來的修復程式
  • 在揭露後 14 天內向供應商提供預先通知
  • 在揭露後 21 天內發布修復程式

當我們持續強化 Kubernetes 時,安全發布流程將有助於確保 Kubernetes 仍然是網際網路規模運算的安全平台。如果您有興趣了解更多關於安全發布流程的資訊,請觀看 KubeCon Europe 2017 的演示文稿在 YouTube 上,並參考投影片。如果您有興趣了解更多關於 Kubernetes 中的身份驗證和授權,以及 Kubernetes 叢集安全模型的資訊,請考慮加入 Kubernetes SIG Auth。我們也希望在下一個 Kubernetes 社群活動:5 月 31 日至 6 月 1 日在舊金山舉行的 CoreOS Fest 2017 的安全相關演示文稿和座談會上見到您。

為了感謝 Kubernetes 社群,使用 k8s25code 或透過此特殊八五折連結註冊 CoreOS Fest 2017,即可享有 CoreOS Fest 的八五折特別折扣。 

  • Stack Overflow 上發布問題(或回答問題)
  • 加入 K8sPort 上的倡導者社群入口網站
  • 在 Twitter 上追蹤我們 @Kubernetesio 以獲取最新更新
  • Slack 上與社群聯繫
  • GitHub 上參與 Kubernetes 專案