本文將從Cloud Foundry中warden container的幾個方面探討warden container的安全性。
1. warden container互訪
1.1. 互訪原理·
在Cloud Foundry內部，用戶應用的運行環境通過warden container來進行隔離。
其中，網絡方面，container之間的互訪如下圖：
假設container1主動訪問container3：
1. container1從自身的虛擬網卡virtual eth0_0發起請求，由於自身內核路由表中的指向，請求發至virtual eth0_1（以下簡稱爲網關）；
2. virtual eth0_1接受到請求，講請求轉發至host主機的物理網卡eth0；
3. host物理網卡eth0接收到請求，從而交給內核網絡棧處理；
4. 請求在內核網絡棧中的處理流程中，首先進行源地址轉換（SNAT），使用host主機的eth0的ip地址替換請求數據包的源ip地址，即講10.254.0.2替換爲10.10.18.83，隨後在進行route路由轉發；
5. 經過SNAT轉換之後，請求發往內核路由部分，根據路由表中規則，請求將會轉發至virtual eth2_1網關；
6. 請求回到host宿主機，開始發往virtual eth2_1網關；
7. Virtual eth2_1網關接收到請求，根據規則轉發至container3的虛擬網卡virtual eth2_0。
總體而言，所有從container內部發起的請求，只要經過host宿主機，在其內核網絡棧中均會進行SNAT，隨後進行route路由處理。這樣的話，container之間的互訪也就有了可能性。
1.2. 潛在安全問題
Cloud Foundry是個多租戶的PaaS雲平臺，不同租戶的應用極有可能被部署在同一個DEA上的不同container內部。以上的分析表明，同個DEA上的不同container完全有可能進行互訪，因此假設租戶A的應用在containerA中，通過某些途徑（如ip猜測，端口輪詢等方式），可以獲取到租戶B的應用在containerB中監聽的端口，那麼租戶A具備了攻擊租戶B應用的條件，從而存在安全隱患。
1.3. 解決方案設計
方案一：
假設設計的目標是讓所有的container之間都不具備互訪的能力，則配置host宿主機的網絡內核棧規則是一個可行的方案。
從1.1中的分析中可以得出結論，關於container發起的請求，在到達其他container之前都會經過host宿主機的eth0物理網卡。其中，在host宿主機內核網絡棧中，進行規則處理，最後進行轉發。
從container中發起的請求，會經過host宿主機的eth0物理網卡，因此可以在eth0將請求交給內核網絡棧後，內核網絡棧可以在進行SNAT處理之前先校驗數據報的源ip地址以及目的ip地址。若源ip地址和目的ip地址均爲DEA內部container的ip地址，則將數據報直接丟棄。
方案一中的設計，雖然可以滿足container之間不能互訪的要求，但是配置所有container之間不能互訪的做法顯得靈活性不足。
假設租戶A有多個應用分別運行在同一個DEA上的不同container內部，該場景使用方案一的話，租戶A自己的應用也將不能互訪，這大大降低了租戶對運行環境要求的靈活性，也削弱了租戶A應用的功能。
以下介紹方案二的設計。
方案二：
引入應用安全組的概念，允許用戶配置container的外出防火牆規則，主要爲用戶提供創建和隔離應用組的安全網絡zone的概念。
應用安全組的實現，使得租戶A的應用container與其他租戶的應用container保持網絡不能互訪，而對於同一個租戶自己的多個應用，租戶有權限根據需求進行配置，使得有需要的container之間可以進行互訪，而沒有需要的container之間不能互訪。
2. Container與Cloud Foundry組件級別的互訪
目前Cloud Foundry中DEA上運行的container可以訪問任何Cloud Foundry的組件，相反Cloud Foundry任何組件都可以訪問container，這顯然是不利於整個平臺的安全防護的。
2.1. 互訪原理
2.1.1. Container訪問Cloud Foundry組件
假設container發起請求，連接Cloud Foundry除DEA外的其他組件，則該請求會在進行SNAT處理之後，有eth0進行轉發，只要host宿主機與其他組件的機器保持網絡暢通，則container完全可以與Cloud Foundry的其他組件進行通信。其中，container默認合法的訪問組件只有gorouter以及service組件，若完成應用間通信的話，container與其他DEA之間的通信也將被認爲合法，而和其他組件的通信均可以認爲是非法的，具體流程圖如下：
2.1.2. Cloud Foundry組件訪問container
該部分內容與2.1.1中大致相同。由於外界訪問container的請求都會被做DNAT處理，因此所有能夠訪問container所在宿主機的Cloud Foundry組件都可以訪問host主機，則均可以訪問container。目前允許訪問DEA內部container的Cloud Foundry內部組件，只有gorouter，service，以及其他DEA（假設允許應用之間允許互相通信），而Cloud Foundry其他的組件訪問container均被認爲是非法的。
2.2. 潛在安全問題
2.2.1. Container非法訪問Cloud Foundry組件的安全
Cloud Foundry託管用戶應用的運行，假設用戶上傳惡意應用，而惡意應用與Cloud Foundry其他的組件可以保持網絡的暢通，則惡意應用完全有可能具有能力對Cloud Foundry的其他組件進行攻擊，從而影響到整個平臺的安全性。
2.2.2. Cloud Foundry組件非法訪問container的安全
原則上，由於Cloud Foundry組件是平臺級別的，對container的訪問理論上不會造成很大的影響。然而當Cloud Foundry平臺級別的組件受到惡意攻擊並被攻破，而DEA的container沒有受到攻擊的時候，假設Cloud Foundry組件還可以訪問container，則惡意攻擊還將蔓延至用戶部署的應用上，而限制Cloud Foundry組件非法訪問container的策略，可以在Cloud Foundry平臺被攻擊的情況下，大大提高用戶應用的安全性。
2.3. 解決方案設計
對於Cloud Foundry內container內部訪問Cloud Foundry其他組件的情況，可以配置DEA所在的host宿主機防火牆規則來實現。
當container內部的請求發送至host宿主機的物理網卡eth0，在做SNAT地址轉換之前，由宿主機內核網絡棧對請求進行處理，如果目的ip地址不是gorouter，service或者dea的話，該數據報將會被丟棄。
爲實現以上的策略，DEA在啓動之前需要獲知所有Cloud Foundry內部組件的角色與IP地址映射關係，從而通過這些映射關係配置防火牆策略。
3. Container與Service組件的互訪
3.1. 互訪原理
Cloud Foundry中Service的存在大大完善了應用的功能性。然而，目前Cloud Foundry內部的應用對於Service的訪問，只需應用持有數個元素，即可以訪問service instance，這些元素主要有5個，即service instance的ip、port、username、password和instance name。
關於service instance訪問請求的流程，與container訪問Cloud Foundry其他組件的原理一致，如下圖：
3.2. 潛在安全問題
假設一個租戶的應用非法持有了某service intance的這5個元素，那麼此應用將會完全有能力訪問該service instance。原先的Cloud Foundry對於這種情況，沒有合適的應對措施，也就相當於默認service instance的這種安全隱患。
以上的敘述可見，關於container訪問service的安全隱患，主要體現在防範的侷限性方面。因爲所有的安全策略制定都依賴於service instance的credentials信息，也就是5元素上。在目前工業界中，依靠這部分的安全保護，已經顯得不足。而且Cloud Foundry是一個面向多租戶的PaaS，數據的安全性格外敏感，必須從多個維度來保護用戶數據的安全性。
3.3. 解決方案設計
方案一：
通過配置container所在的host宿主機防火牆規則，來實現合法應用對service instance的合法訪問，並且阻止非法應用對service instance的非法訪問。
具體實現如下：
1. 在應用和service instance綁定完畢之後，DEA會將service instance的credentials信息當作參數放入應用啓動請求中；
2. DEA可以在啓動應用之前，先提取container的ip地址，以及service instance的ip地址信息，從而在host宿主機上配置防火牆策略，實現，container對service instance的合法訪問，而沒有綁定過service instance的container則在非法持有正確的credentials之後，也無法訪問service instance。
3. 當停止應用的時候，DEA首先解析container的ip地址以及service instance的信息，隨後刪除防火牆記錄。
方案二：
通過配置service instance所在的Service Server所在節點，來實現合法應用對service instance的訪問，並且阻止非法應用對service instance的非法訪問。
具體實現如下：
1. 在應用和service instance進行綁定的時候，由Cloud Controller告知service server所在節點，綁定service instance的應用所屬的IP:PORT映射對；
2. Service Server所在節點，接收到Cloud Controller發送來的請求後，制定自身的防火牆策略，從而保證只允許綁定service instance的應用所對應的IP:PORT映射對才能訪問該節點。
3.
當應用停止的時候，Cloud Controller發送請求給Service Server所在節點，由Service Server所在節點刪除防火牆記錄。
以上便是對Cloud Foundry中warden container的部分安全性探討。
未完待續。
關於作者：
孫宏亮，DAOCLOUD軟件工程師。兩年來在雲計算方面主要研究PaaS領域的相關知識與技術。堅信輕量級虛擬化容器的技術，會給PaaS領域帶來深度影響，甚至決定未來PaaS技術的走向。
轉載請註明出處。
本文更多出於我本人的理解，肯定在一些地方存在不足和錯誤。希望本文能夠對接觸warden安全性的人有些幫助，如果你對這方面感興趣，並有更好的想法和建議，也請聯繫我。
