| 導讀 | Gartner將容器安全列爲其本年度十大安全顧慮之一，或許是時候進一步審視並找出切實的容器安全實現方案了。 |
保護Docker和容器基礎設施安全需要打組合拳，綜合運用策略、工具和審慎的應用檢查。
Gartner將容器安全列爲其本年度十大安全顧慮之一，或許是時候進一步審視並找出切實的容器安全實現方案了。雖然容器已面世十年，但其輕量且可重用的代碼、靈活的功能和更低的開發成本，令容器的流行程度有增無減。但沒有什麼工具是萬能的。我們不妨再仔細考察一下保護開發環境所需的各種工具、容器自身所用工具和出於監視/審計/合規目的的工具吧。
從以下幾個基本步驟開始：
1. 熟悉雲提供商交付的工具
第一步就是熟悉雲提供商的內置安全措施，比如 Azure Security Center、谷歌Kubernetes Engine、谷歌 Cloud Security Command Center和亞馬遜Inspector。其中有些是通用安全工具而非容器專用，比如 Azure Security Center。
2. 熟悉原生Docker相關安全功能
包括運用策略防止資源濫用、設置訪問控制組和確保清除不必要的root權限。
3. 考慮GitHub開源項目
某些情況下，Bench Security之類檢查代碼中最佳安全實踐的項目，以及類似seccomp的其他Linux原生工具，是節省開支的不錯選擇。
總有很多軟件有待學習和理解，但應重點查看幾個常用功能，包括爲用戶及最終生成的應用所設的身份及身份驗證措施，以及控制這些訪問權限的機制。另外，還需要能夠檢查並審計日誌文件，要能瀏覽並過濾日誌文件以提供有益安全態勢的可操作信息。最後，還要有用於保護API密鑰和SSL憑證之類祕密的底層基礎設施。這些祕密必須以加密形式存儲。
是不是有點頭暈目眩了?這還纔剛剛開始呢。想要保護公司環境中的容器，下面三個領域是你不得不仔細考慮的。
4. 保護開發環境
由於容器對開發人員而言非常有用，所以推進到DevSecOps非常有必要，但要記得在創建容器時即添加安全措施，而不是在項目匆忙上馬留下諸多漏洞之後。保證應用安全從來都是最佳實踐。在選擇正確的安全工具之前，你需要回答以下幾個重要問題：
(1) 能夠自動化哪些工作流以保持應用安全?
有些工具有助於實現該操作，尤其是在編排方面。然而，很多編排工具專注於容器管理和擴展問題，未必考慮到安全細節。找到功能和防護之間的恰當平衡或許沒那麼容易。
(2) 應用和用戶訪問控制的粒度該設成多細?
這裏有必要了解這些控制的實現機制及其侷限。比如說，哪些代碼段和容器具備root/內核訪問權限，是否需要這麼高的權限來完成任務。
(3) 應該使用運行時應用自防護(RASP)技術嗎?
必須的。就像專注應用的RASP常規工具，有些工具專注於容器運行時應用保護，要麼有靜態掃描，要麼利用開發環境持續集成。因爲容器代碼不停在變，持續集成的形式相當有用;而且擁有持續代碼審計也可以在不得不修復或更新時節省大量時間。一款好RASP容器工具應能標記異常行爲，緩解潛在威脅，並能夠隔離特定事件以供後續進一步取證分析。Linux就該這麼學
5. 防護託管着容器的底層主機
大多數情況下，這意味着運行精簡版LInux，只留下必要的服務以減小潛在***界面。有些工具就是設計來強化主機自身的。另一個辦法是採用上面提到過的Docker控制組，以及隔離名字空間以反映你的安全策略和防止容器間相互感染。有些商店使用來自雲提供商的虛擬專用連接來實現該隔離操作。該過程包含應用訪問級別和其他機制來隔離工作負載，以及限制每臺主機上運行的容器數量。出於這個原因，有些商店甚至一臺主機只運行一個容器。
6. 保護容器內容安全
這裏討論的是鏡像的軟件供應鏈。這是構建容器的基石，所以一項重要的基本功能就是要能夠保證鏡像源完整性防護，也就是當員工或提供原始容器鏡像的開源項目對鏡像做了修改時，你得清楚到底改動了哪些東西。
鑑於很多容器都在互聯網上共享的事實，能夠掃描容器鏡像以確保不受感染是一項很有用的功能。那麼，你的掃描頻率如何，能不能自動化掃描呢?能從可信源獲取鏡像固然很好，但每個人都會犯錯，意外引入安全問題是不可避免的。
不過，對有些商店，你卻不用擔心容器裏有哪些漏洞。這聽起來令人驚訝，但確實有意義——只除了一點：除非你能保證容器邊界足夠安全，或者你應用程序的實際代碼不觸及容器代碼有漏洞的部分。你對自家安全工具的自信程度，可能是決定漏洞容忍度的最終因素。