容器環境的粒度、部署速度和資料流量規模都要求採用新安全方法。
容器是一種簡單方便快速的跨計算環境軟體部署及執行方式。通過將應用的整個執行時環境（庫、可執行程式和配置檔案）容納進來，平台和基礎設施被抽象了出來，讓應用或多或少地可以在任何地點執行。所有主流雲提供商和現場資料中心以及混合雲環境都提供容器，而且，容器還能節省下很多開支。
開發人員可用容器建立微服務，也就是應用的可重用元件。因為可重用，微服務能幫開發人員免掉重新開發的時間。另外，微服務可跨不同平台部署。
因此，容器的採納率高毫不令人意外。但不幸的是，安全界仍在摸索容器的執行機制和最佳鎖定方法。邁克菲最近針對全球1500位it人員的調查顯示，雇員數超500人的公司企業中約有80%正在使用容器，但僅66%擁有容器安全策略。事實上，今年3月cyberedge對1200名it決策者的調查表明，容器如今與移動裝置一起成為了公司企業最大的安全挑戰。
有很多原因促成了安全成為容器世界中的一大挑戰。原因之一，容器的部署速度。原因之二，容器通常要求應用被分割成微服務，造成資料流量和訪問控制規則複雜度的增加。原因之三，容器通常執行在雲環境中，比如aws，適用新型的安全控制措施。
容器安全工具生態系統尚不成熟，類似虛擬機器和雲的早期時候。公司企業需構建專屬工具和基礎設施來讓容器安全發揮作用，需要很多資源來實現容器安全。目前並沒有太多已成型的解決方案可用，也沒有足夠的解決方案以覆蓋所有用例。
容器的生命週期很短且缺乏良性管理
容器時代，構建-測試-部署的傳統軟體開發過程變得無關緊要。事實上，開發人員經常從公開**庫中直接拖來現成的映象甩到雲端。
但其中有些隱性的信任級是可能不被許可的。容器映象是很便捷的現成**包，但提供者可能沒那個時間或興趣監測安全問題或公開版本注釋。
理想狀況下公司企業應有版本檢查的過程，但極少有企業真的這麼做。公司應該持續檢查自己所用容器是否是最新版本，所有的**是否已打上補丁並做了更新。但目前，這些責任都落到了開發人員個體身上，而且大多是人工檢查。這就出現了檢查上的漏洞，往往落入拖來容器執行起來就再也不管的境地。公司企業真的應該引入更加自動化的過程了。
然而，開發人員自己構建容器也沒好到哪兒去。開發速度意味著根本沒時間保證質量或進行安全測試。到有人注意到容器上線的時候，他們基本也就等同完事兒撤漂了。
到安全團隊可以入駐的時候，容器開發生命週期可能就完結了。這是個問題，需要另一套完全不同的安全思路。
舉個例子，雲安全提供商 skyhigh networks。這家公司部署最新的架構棧，有各種微服務，事實上，他們一天之中可以多次部署進生產環境。一般來講，公司企業可以進行安全測試或滲透測試，但這兩種測試不適用於開發運維環境。
必須找到自動化很多功能的方法，也就是說，得能夠發現所有被部署的容器，確保這些容器的所有成分都是安全的，容器所處環境也是安全的——有應用控制和應用白名單，且施以持續的監測。
邁克菲在4月rsa大會上發布的雲工作負載安全平台就是幹這個的。該平台保護aws、azure和vmware等公共雲和私有雲中的docker容器及其中的工作負載，是能夠將容器與被感染工作負載隔離的第一款雲工作負載解決方案。
該產品還可通過檢查非必要管理員許可權或未滿足的加密要求，以及核查aws儲存桶是否被設為公開可讀，來減小配置風險。從客戶反饋來看，該平台修復速度也有了提公升——加快了90%。
目前為止，幾乎所有的容器安全問題都是不當配置所致，容器的最大風險就在配置上。
服務漩渦
配置管理和補丁管理很難操作，攻擊者卻很方便利用這些漏洞，但至少，二者都是可以解決的問題。容器問題上另一塊不散的陰雲，在於應用被切分成大量內部互聯的微服務時所產生的複雜性。
傳統整體式應用的模型下，乙個應用也就乙個服務和兩個埠。安全人員知道黑客將會攻擊的地方，防護起來也頗為方便。
但微服務模式下，服務和埠數量暴漲，需要看好的門瞬間翻了幾十倍不止。而且，每道門口的實時情況也更不容易掌握了，很難分辨出來敲門的是好人還是壞人。
於是，安全重任落到了確保每一道門都關得夠緊上，也就是對每個微服務應用諸如最小許可權、嚴格訪問控制、隔離和審計等等安全原則。這些東西上世紀70年代就出現了，沒想到現在還需要這麼做。
真是說起來容易做起來難。公司企業持續將其整體的服務分解成越來越細小的微服務，應用的資料流因而變得越來越複雜，以致難以分辨每個微服務的狀態。
只要眾多微服務中混進了乙個硬編碼的訪問憑證，或者洩露了某個身份驗證令牌，那整個系統頓時對黑客不設防。這是個大問題，然而人們往往沒意識到該問題的嚴重性。
而且，隨著越來越多的關鍵系統遷移到軟體即服務的交付模式，這個問題持續發酵。公司企業將大量資料集中進自身應用中，讓這些非常敏感重要的資料在微服務間流轉，幾乎沒有人擁有對這些資料流的良好視野。equifax就是個很好的例子，uber也是。
容器漏洞
容器面臨的安全挑戰還有乙個：漏洞。容器執行在共享環境中，客戶不知道自己的鄰居都是誰，這種情況在公共雲環境下更為突出。事實上，過去幾年裡docker和kubernets容器管理系統中都發現了漏洞。
在公共雲上執行容器的公司剛開始意識到這個問題，直接詢問有沒有什麼工具能夠抵禦容器逃逸攻擊，能夠將容器相互隔離。
portworx 2017容器採用調查中，超過70%的受訪者在linux上執行容器。管理員可用於確保容器隔離的方法包括利用linux名字空間，以及用 security enhanced linux 作為強制訪問控制的補充。另外，還有名為 linux capabilities 的東西可以用來限制linux系統中程序的不同訪問許可權。
linux安全專家對這些概念相對熟悉，但部署容器的團隊未必掌握，剛剛從windows遷移到linux的公司企業就更不知道這些東西了。運營自己的容器環境的公司，無論是在公共還是私有雲上，至少都對自身安全設定有全權控制。但使用現成容器時，就只有信任雲提供商能夠搞對底層安全基礎設施了。
目前為止，能讓程序逃出容器的那些漏洞尚未造成重大資料洩露。但容器領域被少數幾個大平台把持的事實，意味著一旦攻擊者能夠快速利用，僅僅1個漏洞都能造成大面積的傷害。所以，容器漏洞問題真的應認真面對，多加準備了。
原文發布時間為：2018-05-18
為什麼使用微服務
1.單機服務 此時我們就多加了幾台web伺服器，從單機變成了乙個集群，甚至我們可以寫乙個指令碼，當web伺服器壓力過大時動態增加web伺服器。這下web伺服器的壓力不大了，我們就這樣安穩的過上了幾個月。然而有一天伺服器又出問題了 先是mysql伺服器cpu標高，然後是web伺服器宕機。此時我們會發現...
Java程式設計師須知 分布式微服務為什麼很難？
現在，我們不斷地讚美雲原生cloud native架構 容器化和微服務 然而現實是大多數公司仍然執行單體系統。為什麼？這不是因為我們非常不時尚，而是因為分布式是非常困難的。儘管如此，它仍然是建立超大規模的 真正彈性的和快速響應的系統的唯一途徑，因此我們必須圍繞它進行整合。在這篇文章中，我們將介紹分布...
為什麼要微服務（服務化）？
微服務架構 的話題非常之火，很多朋友都在小窗我，說怎麼做服務化？解答 怎麼做 之前，先得了解 為什麼做 畫外音 做技術千萬不能是這種思路，別人都在做，所以我們也要搞 並不是所有的業務都適合 服務化 網際網路高可用架構，到底為什麼要服務化？服務化之前，高可用架構是什麼樣的？在服務化之前，網際網路的典型...