歡迎光臨
每天分享高質量文章

Linux 容器安全的 10 個層面 | Linux 中國

應用這些策略來保護容器解決方案的各個層面和容器生命週期的各個階段的安全。
— Daniel Oh


致謝
編譯自 | https://opensource.com/article/17/10/10-layers-container-security 
 作者 | Daniel Oh
 譯者 | qhwdw ? ? ? ? ? 共計翻譯:91 篇 貢獻時間:131 天

應用這些策略來保護容器解決方案的各個層面和容器生命週期的各個階段的安全。

容器提供了打包應用程式的一種簡單方法,它實現了從開發到測試到投入生產系統的無縫傳遞。它也有助於確保跨不同環境的連貫性,包括物理伺服器、虛擬機器、以及公有雲或私有雲。這些好處使得一些組織為了更方便地部署和管理為他們提升業務價值的應用程式,而快速地採用了容器技術。

企業需要高度安全,在容器中執行核心服務的任何人都會問,“容器安全嗎?”以及“我們能信任執行在容器中的應用程式嗎?”

對容器進行安全保護就像是對執行中的行程進行安全保護一樣。在你部署和執行你的容器之前,你需要去考慮整個解決方案各個層面的安全。你也需要去考慮貫穿了應用程式和容器整個生命週期的安全。

請嘗試從這十個關鍵的因素去確保容器解決方案棧不同層面、以及容器生命週期的不同階段的安全。

1. 容器宿主機作業系統和多租戶環境

由於容器將應用程式和它的依賴作為一個單元來處理,使得開發者構建和升級應用程式變得更加容易,並且,容器可以啟用多租戶技術將許多應用程式和服務部署到一臺共享主機上。在一臺單獨的主機上以容器方式部署多個應用程式、按需啟動和關閉單個容器都是很容易的。為完全實現這種打包和部署技術的優勢,運營團隊需要執行容器的合適環境。運營者需要一個安全的作業系統,它能夠在邊界上保護容器安全、從容器中保護主機核心,以及保護容器彼此之間的安全。

容器是隔離而資源受限的 Linux 行程,允許你在一個共享的宿主機核心上執行沙盒化的應用程式。保護容器的方法與保護你的 Linux 中執行的任何行程的方法是一樣的。降低許可權是非常重要的,也是保護容器安全的最佳實踐。最好使用盡可能小的許可權去建立容器。容器應該以一個普通使用者的許可權來執行,而不是 root 許可權的使用者。在 Linux 中可以使用多個層面的安全加固手段,Linux 名稱空間、安全強化 Linux(SELinux[1])、cgroups[2] 、capabilities(LCTT 譯註:Linux 內核的一個安全特性,它打破了傳統的普通使用者與 root 使用者的概念,在行程級提供更好的安全控制)、以及安全計算樣式( seccomp[3] ),這五種 Linux 的安全特性可以用於保護容器的安全。

2. 容器內容(使用可信來源)

在談到安全時,首先要考慮你的容器裡面有什麼?例如 ,有些時候,應用程式和基礎設施是由很多可用元件所構成的。它們中的一些是開源的軟體包,比如,Linux 作業系統、Apache Web 伺服器、Red Hat JBoss 企業應用平臺、PostgreSQL,以及 Node.js。這些軟體包的容器化版本已經可以使用了,因此,你沒有必要自己去構建它們。但是,對於你從一些外部來源下載的任何程式碼,你需要知道這些軟體包的原始來源,是誰構建的它,以及這些包裡面是否包含惡意程式碼。

3. 容器註冊(安全訪問容器映象)

你的團隊的容器構建於下載的公共容器映象,因此,訪問和升級這些下載的容器映象以及內部構建映象,與管理和下載其它型別的二進位制檔案的方式是相同的,這一點至關重要。許多私有的註冊庫支援容器映象的儲存。選擇一個私有的註冊庫,可以幫你將儲存在它的註冊中的容器映象實現策略自動化。

4. 安全性與構建過程

在一個容器化環境中,軟體構建過程是軟體生命週期的一個階段,它將所需的執行時庫和應用程式程式碼整合到一起。管理這個構建過程對於保護軟體棧安全來說是很關鍵的。遵守“一次構建,到處部署”的原則,可以確保構建過程的結果正是生產系統中需要的。保持容器的恆定不變也很重要 — 換句話說就是,不要對正在執行的容器打補丁,而是,重新構建和部署它們。

不論是因為你處於一個高強度監管的行業中,還是隻希望簡單地最佳化你的團隊的成果,設計你的容器映象管理以及構建過程,可以使用容器層的優勢來實現控制分離,因此,你應該去這麼做:

◈ 運營團隊管理基礎映象
◈ 架構師管理中介軟體、執行時、資料庫,以及其它解決方案
◈ 開發者專註於應用程式層面,並且只寫程式碼

最後,標記好你的定製構建容器,這樣可以確保在構建和部署時不會搞混亂。

5. 控制好在同一個叢集內部署應用

如果是在構建過程中出現的任何問題,或者在映象被部署之後發現的任何漏洞,那麼,請在基於策略的、自動化工具上新增另外的安全層。

我們來看一下,一個應用程式的構建使用了三個容器映象層:核心、中介軟體,以及應用程式。如果在核心映象中發現了問題,那麼只能重新構建映象。一旦構建完成,映象就會被髮布到容器平臺註冊庫中。這個平臺可以自動檢測到發生變化的映象。對於基於這個映象的其它構建將被觸發一個預定義的動作,平臺將自己重新構建應用映象,合併該修複的庫。

一旦構建完成,映象將被髮布到容器平臺的內部註冊庫中。在它的內部註冊庫中,會立即檢測到映象發生變化,應用程式在這裡將會被觸發一個預定義的動作,自動部署更新映象,確保執行在生產系統中的程式碼總是使用更新後的最新的映象。所有的這些功能協同工作,將安全功能整合到你的持續整合和持續部署(CI/CD)過程和管道中。

6. 容器編配:保護容器平臺安全

當然了,應用程式很少會以單一容器分發。甚至,簡單的應用程式一般情況下都會有一個前端、一個後端、以及一個資料庫。而在容器中以微服務樣式部署的應用程式,意味著應用程式將部署在多個容器中,有時它們在同一臺宿主機上,有時它們是分佈在多個宿主機或者節點上,如下麵的圖所示:

在大規模的容器部署時,你應該考慮:

◈ 哪個容器應該被部署在哪個宿主機上?
◈ 那個宿主機應該有什麼樣的效能?
◈ 哪個容器需要訪問其它容器?它們之間如何發現彼此?
◈ 你如何控制和管理對共享資源的訪問,像網路和儲存?
◈ 如何監視容器健康狀況?
◈ 如何去自動擴充套件效能以滿足應用程式的需要?
◈ 如何在滿足安全需求的同時啟用開發者的自助服務?

考慮到開發者和運營者的能力,提供基於角色的訪問控制是容器平臺的關鍵要素。例如,編配管理伺服器是中心訪問點,應該接受最高階別的安全檢查。API 是規模化的自動容器平臺管理的關鍵,可以用於為 pod、服務,以及複製控制器驗證和配置資料;在入站請求上執行專案驗證;以及呼叫其它主要系統元件上的觸發器。

7. 網路隔離

在容器中部署現代微服務應用,經常意味著跨多個節點在多個容器上部署。考慮到網路防禦,你需要一種在一個叢集中的應用之間的相互隔離的方法。一個典型的公有雲容器服務,像 Google 容器引擎(GKE)、Azure 容器服務,或者 Amazon Web 服務(AWS)容器服務,是單租戶服務。他們讓你在你初始化建立的虛擬機器叢集上執行你的容器。對於多租戶容器的安全,你需要容器平臺為你啟用一個單一叢集,並且分割流量以隔離不同的使用者、團隊、應用、以及在這個叢集中的環境。

使用網路名稱空間,容器內的每個集合(即大家熟知的 “pod”)都會得到它自己的 IP 和系結的埠範圍,以此來從一個節點上隔離每個 pod 網路。除使用下麵所述的方式之外,預設情況下,來自不同名稱空間(專案)的 pod 並不能傳送或者接收其它 pod 上的包和不同專案的服務。你可以使用這些特性在同一個叢集內隔離開發者環境、測試環境,以及生產環境。但是,這樣會導致 IP 地址和埠數量的激增,使得網路管理更加複雜。另外,容器是被設計為反覆使用的,你應該在處理這種複雜性的工具上進行投入。在容器平臺上比較受歡迎的工具是使用 軟體定義網路[4] (SDN) 提供一個定義的網路叢集,它允許跨不同叢集的容器進行通訊。

8. 儲存

容器即可被用於無狀態應用,也可被用於有狀態應用。保護外加的儲存是保護有狀態服務的一個關鍵要素。容器平臺對多種受歡迎的儲存提供了外掛,包括網路檔案系統(NFS)、AWS 彈性塊儲存(EBS)、GCE 持久磁碟、GlusterFS、iSCSI、 RADOS(Ceph)、Cinder 等等。

一個持久捲(PV)可以透過資源提供者支援的任何方式裝載到一個主機上。提供者有不同的效能,而每個 PV 的訪問樣式被設定為特定的捲支援的特定樣式。例如,NFS 能夠支援多路客戶端同時讀/寫,但是,一個特定的 NFS 的 PV 可以在伺服器上被髮布為只讀樣式。每個 PV 有它自己的一組反應特定 PV 效能的訪問樣式的描述,比如,ReadWriteOnce、ReadOnlyMany、以及 ReadWriteMany。

9. API 管理、終端安全、以及單點登入(SSO)

保護你的應用安全,包括管理應用、以及 API 的認證和授權。

Web SSO 能力是現代應用程式的一個關鍵部分。在構建它們的應用時,容器平臺帶來了開發者可以使用的多種容器化服務。

API 是微服務構成的應用程式的關鍵所在。這些應用程式有多個獨立的 API 服務,這導致了終端服務數量的激增,它就需要額外的管理工具。推薦使用 API 管理工具。所有的 API 平臺應該提供多種 API 認證和安全所需要的標準選項,這些選項既可以單獨使用,也可以組合使用,以用於釋出證書或者控制訪問。

這些選項包括標準的 API key、應用 ID 和金鑰對,以及 OAuth 2.0。

10. 在一個聯合叢集中的角色和訪問管理

在 2016 年 7 月份,Kubernetes 1.3 引入了 Kubernetes 聯合叢集[5]。這是一個令人興奮的新特性之一,它是在 Kubernetes 上游、當前的 Kubernetes 1.6 beta 中取用的。聯合是用於部署和訪問跨多叢集執行在公有雲或企業資料中心的應用程式服務的。多個叢集能夠用於去實現應用程式的高可用性,應用程式可以跨多個可用區域,或者去啟用部署公共管理,或者跨不同的供應商進行遷移,比如,AWS、Google Cloud、以及 Azure。

當管理聯合叢集時,你必須確保你的編配工具能夠提供你所需要的跨不同部署平臺的實體的安全性。一般來說,認證和授權是很關鍵的 —— 不論你的應用程式執行在什麼地方,將資料安全可靠地傳遞給它們,以及管理跨叢集的多租戶應用程式。Kubernetes 擴充套件了聯合叢集,包括對聯合的秘密資料、聯合的名稱空間、以及 Ingress objects 的支援。

選擇一個容器平臺

當然,它並不僅關乎安全。你需要提供一個你的開發者團隊和運營團隊有相關經驗的容器平臺。他們需要一個安全的、企業級的基於容器的應用平臺,它能夠同時滿足開發者和運營者的需要,而且還能夠提高操作效率和基礎設施利用率。

想從 Daniel 在 歐盟開源峰會[6] 上的 容器安全的十個層面[7] 的演講中學習更多知識嗎?這個峰會已於 10 月 23 – 26 日在 Prague 舉行。

關於作者

Daniel Oh;Microservives;Agile;Devops;Java Ee;Container;Openshift;Jboss;Evangelism


via: https://opensource.com/article/17/10/10-layers-container-security

作者:Daniel Oh[9] 譯者:qhwdw 校對:wxy

本文由 LCTT 原創編譯,Linux中國 榮譽推出

贊(0)

分享創造快樂