?容器是目前應(yīng)用系統(tǒng)運行的常用環(huán)境，特別是對于復(fù)雜的應(yīng)用系統(tǒng)，開發(fā)人員更喜歡使用基于容器的開發(fā)架構(gòu)，因為容器是輕量級的、可移植的，并且易于維護和擴展。由于這些特性，容器非常適用于現(xiàn)代開發(fā)模式，如DevOps、無服務(wù)器和微服務(wù)等。

開發(fā)人員可在容器中封裝了應(yīng)用程序的輕量級運行時環(huán)境。因此，當(dāng)在容器中開發(fā)微服務(wù)時，它繼承了容器化的優(yōu)點，如可移植性、可伸縮性和額外安全層等。同時，在單獨的容器中運行微服務(wù)，用戶可以獨立地部署它們，消除了語言、庫和框架之間的兼容性風(fēng)險。在服務(wù)監(jiān)測方面，容器化使微服務(wù)更容易定位和相互通信，因為它們都運行在位于同一平臺上的容器中，開發(fā)人員將更容易編排微服務(wù)。

微服務(wù)和容器應(yīng)用的安全挑戰(zhàn)

雖然基于容器的微服務(wù)開發(fā)應(yīng)用方法有諸多好處，包括易于擴展和管理，但它們也同樣存在一些的安全問題。在服務(wù)開發(fā)之前，企業(yè)應(yīng)該了解可能出現(xiàn)的網(wǎng)絡(luò)安全風(fēng)險以及如何消除這些風(fēng)險，將有助于創(chuàng)建可靠又安全的產(chǎn)品。

1. 可被利用的漏洞

一般來說，與微服務(wù)和容器相關(guān)的安全問題屬于應(yīng)用編排平臺的整體安全需求中。但是，并非所有的安全風(fēng)險都可以在業(yè)務(wù)流程中處理。比如說可能被利用的漏洞。

映像漏洞是基于微服務(wù)和容器的應(yīng)用程序內(nèi)最常見的安全威脅。它們通常來自不安全的庫或其他依賴項。當(dāng)容器基于不安全的映像時，就會將該漏洞威脅引入整個應(yīng)用環(huán)境；

應(yīng)用程序漏洞主要指應(yīng)用程序的源代碼缺陷。比如某個應(yīng)用程序中存在一個緩沖區(qū)溢出漏洞，攻擊者可能會利用它來執(zhí)行惡意代碼并接管容器；

網(wǎng)絡(luò)攻擊的漏洞。基于微服務(wù)的應(yīng)用程序比傳統(tǒng)應(yīng)用程序更復(fù)雜，因為它們由許多獨立部件組成。一個應(yīng)用程序可以包括部署在數(shù)千個容器中的數(shù)百個微服務(wù)，這使得基于微服務(wù)的應(yīng)用程序非常容易受到網(wǎng)絡(luò)攻擊，因為很難同時確保這么多組件的整體安全性。

2. 惡意軟件風(fēng)險

惡意軟件的危害在于，如果企業(yè)在啟動容器之前沒有檢測到它，惡意軟件將感染此容器內(nèi)的微服務(wù)以及整個環(huán)境。惡意軟件攻擊帶來的安全風(fēng)險主要包括:

黑客可以訪問一個容器并向其中注入惡意代碼，通過惡意代碼可以攻擊該容器、其他容器或主機操作系統(tǒng)中的微服務(wù)；

惡意攻擊者會危害企業(yè)的CI/CD環(huán)境，并將惡意軟件注入用于構(gòu)建容器映像的源代碼存儲庫；

攻擊者會破壞容器注冊表并替換包含惡意軟件的圖像；

攻擊者欺騙開發(fā)人員從外部來源下載惡意容器映像。

3. 與代碼訪問相關(guān)的風(fēng)險

訪問和修改代碼的人越多，安全風(fēng)險就越大，最常見的情況是:

• 訪問權(quán)限過大。許多開發(fā)公司選擇DevOps方法來使用微服務(wù)和容器構(gòu)建應(yīng)用程序，這可能導(dǎo)致訪問權(quán)限過于寬泛，增加了在分布式工作環(huán)境中惡意修改代碼的風(fēng)險。
• 機密管理薄弱。在安全實踐不佳或違反安全規(guī)則的情況下，很多人可以訪問容器。例如，開發(fā)人員可能將腳本中編碼的憑證放入容器中，或者將憑證存儲在配置不安全的密鑰管理系統(tǒng)中。

4. 容器間的通信不受限制

通常情況下，容器不能訪問外部任何資源，這被稱為非特權(quán)模式。工程師應(yīng)該只允許保障應(yīng)用系統(tǒng)正常工作所必需的容器間通信。每當(dāng)容器的通信權(quán)限超過嚴格要求時，它可能會導(dǎo)致額外的安全風(fēng)險。由于缺乏經(jīng)驗或管理不當(dāng)而導(dǎo)致的錯誤配置，會讓容器獲得過多的特權(quán)。

5. 不安全的數(shù)據(jù)管理

微服務(wù)體系的分布式框架使得數(shù)據(jù)安全管理更具挑戰(zhàn)性，因為很難控制對單個服務(wù)的訪問和安全授權(quán)。因此，工程師必須更加關(guān)注如何確保每個服務(wù)內(nèi)數(shù)據(jù)的機密性、隱私性和完整性。另一個問題是，微服務(wù)中的數(shù)據(jù)不斷地移動、更改，并在不同的服務(wù)中用于不同的目的，這為攻擊者創(chuàng)建了更多的數(shù)據(jù)竊取攻擊點。

6. 錯誤配置工具

在開發(fā)和維護微服務(wù)架構(gòu)時，DevOps團隊需要使用大量工具，包括開源和第三方工具。雖然這類工具幫助工程師實現(xiàn)DevOps管道所需的效率，但它們很難保證所需要的安全性。

如果不能準確評估開源工具的安全功能，企業(yè)就有可能在微服務(wù)和容器中創(chuàng)建漏洞。即使一個工具本身是安全，如果沒有正確設(shè)置，也會出現(xiàn)很多安全問題。

微服務(wù)和容器安全防護最佳實踐

如何選擇適當(dāng)?shù)陌踩胧﹣響?yīng)對上面提到的風(fēng)險可能是一個挑戰(zhàn)。究其原因，容器和微服務(wù)都是因為它們應(yīng)用的簡潔性和快捷性而對開發(fā)人員具有如此大的吸引力。如果安全措施使開發(fā)流程變得緩慢和復(fù)雜，那么就很可能會被開發(fā)人員所抵觸或故意忽視。為了幫助企業(yè)在安全的情況下高效利用容器和微服務(wù)進行應(yīng)用系統(tǒng)開發(fā)，本文收集整理了10種有用的最佳實踐。

1. 創(chuàng)建不可變?nèi)萜?/strong>

開發(fā)人員往往保留通過shell訪問映像的途徑，以便修復(fù)生產(chǎn)環(huán)境中的映像。然而，攻擊者常利用這條途徑來注入惡意代碼。要避免這種情況，可以創(chuàng)建不可變?nèi)萜鳌２豢勺內(nèi)萜鳠o法被改動。如果用戶需要更新應(yīng)用程序代碼、打補丁或更改配置，可以重新構(gòu)建映像并重新部署容器。如果用戶需要撤回更改，只需重新部署舊映像。需要注意的是，容器的不可變特性會影響到數(shù)據(jù)持久性。開發(fā)人員應(yīng)該將數(shù)據(jù)存儲在容器外面，這樣容器被替換時，所有數(shù)據(jù)仍可供新版本使用。

2. 將自動安全測試集成到CI/CD過程中

有各種工具可以在CI/CD過程中自動測試容器。比如說，HP Fortify和IBM AppScan提供動態(tài)和靜態(tài)應(yīng)用程序安全測試。還可以使用JFrog Xray和Black Duck等掃描器實時檢查容器中已知的漏洞。一旦這類工具發(fā)現(xiàn)了漏洞，就會將檢測到有問題的部分標注出來，以便檢查和修復(fù)。

3. 避免使用特權(quán)容器

如果容器在特權(quán)模式下運行，它就可以訪問主機上的所有組件。如果這種容器被破壞，攻擊者可以全面訪問服務(wù)器。因此，應(yīng)該考慮盡量避免使用特權(quán)容器。比如在Kubernetes中，可以使用策略控制器（Policy Controller）禁止特權(quán)容器。

如果出于某種原因需要使用特權(quán)容器，谷歌云架構(gòu)中心提供了幾個替代方案：

• 通過Kubernetes的securityContext選項為容器提供特定的功能
• 在sidecar容器或init容器中修改應(yīng)用程序設(shè)置
• 使用專用注釋修改Kubernetes中的sysctls接口

4. 建立可信映像庫

開源社區(qū)會為開發(fā)人員提供許多具有容器的開源軟件包。但是出于安全目的，開發(fā)者需要知道容器的來源、更新時間以及它們是否含有漏洞和惡意代碼。最好建立可信映像庫，只從這個可信源運行映像。如果想使用其他來源的映像，建議首先使用掃描工具掃描映像。此外，在將容器部署到生產(chǎn)環(huán)境之前，開發(fā)人員應(yīng)檢查腳本中的應(yīng)用程序簽名。如果在多個云環(huán)境中運行容器，需要建立多個安全映像存儲庫。

5. 使用注冊中心管理映像

Docker Hub、Amazon EC2 Container Registry和Quay Container Registry等注冊中心可以幫助開發(fā)人員存儲和管理已創(chuàng)建的映像。可以使用這些注冊中心執(zhí)行以下操作：

• 提供基于角色的訪問控制
• 指定容器的可信源
• 創(chuàng)建和更新已知漏洞列表
• 標注易受攻擊的映像

基于角色的訪問控制非常重要，因為需要控制誰可以改變?nèi)萜鳌Ｗ詈脤⒃L問權(quán)限分開到不同的管理帳戶：一個負責(zé)系統(tǒng)管理，另一個負責(zé)操作和編排容器。要記住的另一點是，應(yīng)該確保注冊中心驗證每個容器的簽名，只接受來自可信源的容器。此外，需要充分利用幫助不斷檢查映像內(nèi)容查找已知漏洞，并報告安全問題的功能。

6. 加固主機操作系統(tǒng)

保障微服務(wù)和容器的應(yīng)用安全，有必要確保主機操作系統(tǒng)的安全。

首先，建議企業(yè)使用針對特定容器的主機操作系統(tǒng)（明確旨在只運行容器的簡版主機操作系統(tǒng)），因為它們沒有不必要的功能，因而攻擊面比通用主機系統(tǒng)小很多。

其次，CIS Docker Benchmark提供了加固系統(tǒng)的核對列表，主要的建議如下：

• 建立用戶身份驗證
• 設(shè)置訪問角色
• 指定二進制文件訪問權(quán)限
• 收集詳細的審計日志

為了避免數(shù)據(jù)泄露，應(yīng)該限制容器對底層操作系統(tǒng)資源的訪問，并將容器彼此隔離。一個好的做法是在內(nèi)核模式下運行容器引擎，同時在用戶模式下運行容器。比如說，Linux提供了Linux命名空間、seccomp、cgroups和SELinux等技術(shù)，從而安全地構(gòu)建和運行容器。

7. 用縱深防御方法保護微服務(wù)

縱深防御可以結(jié)合多種安全機制和控制措施，比如殺毒軟件、防火墻和補丁管理，以保護網(wǎng)絡(luò)和數(shù)據(jù)的機密性、完整性和可用性。

縱深防御方法的三大層是：

• 物理控制——用于物理限制用戶訪問IT系統(tǒng)，比如安保系統(tǒng)和閉路電視系統(tǒng)
• 技術(shù)控制——旨在保護系統(tǒng)和資源的軟硬件
• 管理控制——通過各種策略和程序，以確保組織關(guān)鍵基礎(chǔ)設(shè)施的網(wǎng)絡(luò)安全性

縱深防御方法是確保微服務(wù)安全的最重要原則之一，因為它創(chuàng)建了多層安全以防止攻擊。它包括下列安全措施：過濾傳輸?shù)臄?shù)據(jù)流、驗證和授權(quán)對微服務(wù)的訪問以及使用加密技術(shù)等。要確保內(nèi)部環(huán)境不受任何外部連接的影響，因為這是安全防護的基礎(chǔ)。

8. 嚴格控制API訪問

API是微服務(wù)應(yīng)用程序的關(guān)鍵，很多軟件都會有多個獨立的API服務(wù)。因此，確保安全身份驗證和授權(quán)的API訪問控制對于微服務(wù)安全至關(guān)重要。當(dāng)API服務(wù)訪問敏感數(shù)據(jù)時，應(yīng)該需要提供驗證令牌，令牌要經(jīng)過數(shù)字簽名或得到權(quán)威來源的驗證。開發(fā)人員和管理員可以使用OAuth/OAuth2服務(wù)器來獲取令牌，以便通過API訪問應(yīng)用程序。出于安全考慮，還應(yīng)該使用傳輸層安全（TLS）加密來保護所有客戶機/服務(wù)器通信。

9. 原生化容器檢測工具

持續(xù)性監(jiān)測容器的運行很有必要，因為它可以幫助用戶：

• 深入了解容器度量指標和日志
• 了解集群、主機以及容器內(nèi)部正在發(fā)生的情況
• 做出更明智的安全運營決策

然而要確保有效的監(jiān)視，最好使用容器原生監(jiān)視工具。比如在使用Docker時，開發(fā)人員通常使用Docker Security Scanner或其他專門設(shè)計的工具來檢測任何潛在威脅。監(jiān)視工具會先收集事件，然后對照設(shè)置好的安全策略加以對比分析和檢查。

10. 使用服務(wù)編排管理器

服務(wù)編排是個復(fù)雜的過程，可使微服務(wù)和容器的部署、管理、擴展和連接實現(xiàn)自動化。編排器負責(zé)從注冊中心提取映像，將這些映像部署到容器，并管理容器運行。編排器提供的抽象讓用戶可以指定運行某個映像所必需的容器數(shù)量，以及需要為它們分配哪些主機資源。

如果使用編排管理器，不僅可以自動部署微服務(wù)，還可以確保一定級別的安全。比如說，編排器便于管理容器集群、隔離工作負載、限制對元數(shù)據(jù)的訪問以及收集日志。許多編排管理器還有內(nèi)置的機密數(shù)據(jù)管理工具，允許開發(fā)人員安全地存儲和共享機密數(shù)據(jù)，比如API和SSL證書、加密密鑰、身份令牌和密碼。

參考鏈接：

https://www.apriorit.com/dev-blog/558-microservice-container-security-best-practices