摘要:將成安全評估如漏洞掃描加入持續集成中,使其成為構建流程的一部分。持續集成應確保只使用審查通過的代碼來構建鏡像。我們推薦這篇文章中提到的安全實踐,將的靈活配置能力加入到持續集成中,自動將安全性無縫融合到整個流程中。
編者按:本文是由 Aqua Security 的Amir Jerbi 和Michael Cherny 所寫,基于他們從本地和云端上收集到的實際數據,描述了Kubernetes 部署的最佳安全實踐。
Kubernetes提供了許多可以極大地提高應用程序安全性的選項。配置它們要求你熟悉 Kubernetes 以及其部署的安全要求。
我們在這里強調的最佳實踐與容器生命周期相匹配:構建、分發和運行,并專門為Kubernetes量身打造。我們在運行在Google云平臺的kubernetes上使用了這些安全實踐。
以下是我們部署安全的Kubernetes應用的建議:
◆ 確保鏡像沒有漏洞運行有漏洞的容器使你的環境會遭受損害的風險。許多攻擊可以簡單地通過將軟件升級為沒有漏洞的版本來避免。
實現Continuous Security Vulnerability Scanning (持續安全漏洞掃描)——容器可能包括含有已知漏洞(CVE)的過時包。新的漏洞每天都會發布,所以這不是一個“一次性”的工作,對鏡像持續進行安全評估是至關重要的。
定期對環境進行安全更新,一旦發現運行中容器的漏洞,你應該及時更新鏡像并重新部署容器。盡量避免直接更新(例如, ‘apt-update’ )到正在運行的容器,因為這樣打破了鏡像與容器的對應關系。
使用Kubernetes滾動升級功能升級容器非常簡單,該功能允許通過升級鏡像到最新版本來逐步更新正在運行的容器。
◆ 確保在你的環境中只使用授權鏡像如果無法保證只運行符合組織策略的鏡像,那么組織會面臨運行脆弱甚至惡意容器的危險。從未知的來源下載和運行鏡像是危險的,它相當于在生產服務器上運行未知服務商的軟件,所以千萬別這樣做!
使用私有鏡像存儲你的合法鏡像,這樣能大量減少可能進入到你的環境的鏡像數量。將成安全評估(如漏洞掃描)加入持續集成(CI)中,使其成為構建流程的一部分。
持續集成應確保只使用審查通過的代碼來構建鏡像。當鏡像構建成功后,要對它進行安全漏洞掃描,然后只有當沒有發現問題時,鏡像才能被推送私有鏡像倉庫。在安全評估中失敗的鏡像不應該被推送到鏡像倉庫中。
Kubernetes鏡像授權插件的工作已經完成(預計隨kubernetes 1.4發布)。該插件允許阻止未授權鏡像的分發。具體請查看此PR (https://github.com/kubernetes...)。
◆ 限制對Kubernetes 節點的直接訪問應該限制SSH登陸Kubernetes節點,減少對主機資源未授權的訪問。應該要求用戶使用“ kubectl exec ”命令,此命令能夠在不訪問主機的情況下直接訪問容器環境。
你可以使用kubernetes授權插件來進一步控制用戶對資源的訪問。它允許設置對指定命名空間、容器和操作的細粒度訪問控制規則。
◆ 創建資源間的管理界限限制用戶權限的范圍可以減少錯誤或惡意活動的影響。Kubernetes 命名空間允許將資源劃分為邏輯命名組。在一個命名空間中創建的資源對其他命名空間是隱藏的。
默認情況下,用戶在Kubernetes 集群中創建的每個資源運行在名稱為“default”的默認空間內。你也可以創建額外的命名空間并附加資源和用戶給它們。你可以使用Kubernetes 授權插件來創建策略,以便將不同用戶的訪問請求隔離到不同的命名空間中。
例如:以下策略將允許 ‘alice’ 從命名空間 ‘fronto’ 讀取pods。
◆ 定義資源配額運行沒有資源限制的容器會將你的系統置于DoS或被其他租戶干擾的風險中。為了防止和最小化這些風險,你應該定義資源配額。
默認情況下,Kubernetes 集群中的所有資源沒有對CPU 和內存的使用限制。你可以創建資源配額策略,并附加到Kubernetes命名空間中來限制Pod對CPU和內存的使用。
下面的例子將限制命名空間中Pod 的數量為4個,CPU使用在1和2之間,內存使用在1GB 和 2GB 之間。
compute-resources.yaml:
分配資源配額到命名空間:
◆ 實現網絡分段在相同的Kubernetes集群上運行不同的應用程序會導致惡意程序攻擊其他應用程序的風險。所以網絡分割對確保容器只與那些被允許的容器進行通信很重要。
Kubernetes 部署的挑戰之一是創建Pod,服務和容器之間的網絡分段。原因在于容器網絡標識符(IP地址)動態的“天性”,以及容器可以在同一節點或節點間進行通信的事實。
谷歌云平臺的用戶受益于自動防火墻規則,能夠防止跨集群通信。類似的實現可以使用網絡防火墻或SDN解決方案部署。這方面的工作由Kubernetes 網絡特別興趣小組(Special Interest Group)完成,這將大大提高 pod到pod 的通信策略。
新的網絡策略API應該解決 Pod之間創建防火墻規則的需求,限制容器化可以進行的網絡訪問。
下面展示了只允許前端(frontend)Pod訪問后端(backend)Pod的網絡策略:
點擊這里(http://blog.kubernetes.io/201...)閱讀更多網絡策略的內容。
◆ 將安全環境應用到你的Pods和容器中當設計你的容器和 pods時,確保為你的pods,容器和存儲卷配置安全環境。安全環境是定義在yaml文件中的一項屬性。它控制分配給 pod/容器/存儲卷的安全參數。一些重要的參數是:
以下是一個具有安全環境參數的pod 定義示例:
◆ 記錄所有的事情Kubernetes提供基于集群的日志,允許將容器活動日志記錄到一個日志中心。當集群被創建時,每個容器的標準輸出和標準錯誤都可以通過運行在每個節點上的Fluentd 服務記錄到Stackdriver或Elasticsearch中,然后使用Kibana進行查看。
◆ 總結Kubernetes 對創建安全部署提供多種選擇,沒有適合所有情況的萬能解決方案,所以熟悉這些安全選項、了解它們如何提高應用程序安全性是很重要的。
我們推薦這篇文章中提到的安全實踐,將Kubernetes的靈活配置能力加入到持續集成中,自動將安全性無縫融合到整個流程中。
時速云每兩周將于微信群進行技術分享,感興趣的小伙伴可以添加微信號(tenxcloud6)時速云小助手,然后我們會拉您進群
本文由時速云翻譯,如若轉載,需注明轉載自“時速云”
原文鏈接: http://blog.kubernetes.io/201...
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/26716.html
摘要:將成安全評估如漏洞掃描加入持續集成中,使其成為構建流程的一部分。持續集成應確保只使用審查通過的代碼來構建鏡像。我們推薦這篇文章中提到的安全實踐,將的靈活配置能力加入到持續集成中,自動將安全性無縫融合到整個流程中。 編者按:本文是由 Aqua Security 的Amir Jerbi 和Michael Cherny 所寫,基于他們從本地和云端上收集到的實際數據,描述了Kubernetes...
摘要:今天的文章由來自的和撰寫,在不同用戶案例中搜集到的數據基礎上,描述了的安全最佳實踐。在谷歌上,我們的用來部署我們的服務。實施連續安全缺陷掃描容器可能包含過時的已知缺陷的程序包。谷歌云平臺的用戶能夠從自動防火墻規則中受益,避免跨集群交流。 今天的文章由來自 Aqua Security 的 Amir Jerbl 和 Micheal Chemy 撰寫,在不同用戶案例中搜集到的數據基礎上,描述...
摘要:今年年初,由于控制臺中的配置錯誤,特斯拉被一個惡意挖掘加密貨幣的軟件所感染。為了幫助您完成這項工作,本文將為您介紹項安全最佳實踐。授權失敗可能意味著攻擊者試圖濫用被盜憑據。 上個月,全球最受歡迎的容器編排引擎Kubernetes,被爆出首個嚴重的安全漏洞,使得整個Kubernetes生態發生震蕩。該漏洞(CVE-2018-1002105)使攻擊者能夠通過Kubernetes API服務...
摘要:安全的云元數據訪問該建議指出,敏感的元數據有時可能被盜或被濫用,但未能概述何時或如何的條件。雖然上篇文章指出具有元數據隱藏的功能,但值得注意的是,在最開始泄露憑據的服務,正是元數據。我還認為云提供商不應該將憑證嵌入到可通過訪問的元數據中。 在上篇文章里,我們分享了CNCF為廣大Kubernetes用戶建議的9項Kubernetes安全最佳實踐,分享了用戶使用Kubernetes管理集群...
摘要:的元數據隱藏功能會更改集群部署機制以避免此暴露,我們建議使用它直到有永久解決方案。授權失敗可能意味著攻擊者試圖濫用被盜的憑據。年中國論壇提案征集現已開放論壇讓用戶開發人員從業人員匯聚一堂,面對面進行交流合作。 作者:StackRox產品經理Connor Gilbert 上個月,Kubernetes(世界上最受歡迎的容器編排器)生態系統因發現Kubernetes的第一個主要安全漏洞而動搖...
閱讀 3538·2021-11-22 15:22
閱讀 3328·2019-08-30 15:54
閱讀 2724·2019-08-30 15:53
閱讀 783·2019-08-29 11:22
閱讀 3529·2019-08-29 11:14
閱讀 2073·2019-08-26 13:46
閱讀 2209·2019-08-26 13:24
閱讀 2276·2019-08-26 12:22