當應用程式只被部署在一臺伺服器上時，要保障應用程式的安全是很簡單的。它只需要一個防火牆——就像孫悟空畫的圈，圈裡面的所有人都可以得到安全可靠的保護，但是圈外面的東東就沒那麼幸運了（妖魔鬼怪隨時把你帶走的節奏~）。防火牆就是孫大聖的金箍棒，它為你的網路（玉帝哥哥）和應用程式（其他人獸）畫出了邊界。
兮乎，一夢千年 ，山中方一日，世上已千年。這時代變化太快，新技術已經將基於邊界的安全推向風口浪尖，現在是時候重新考慮現代雲原生應用的安全性（誰去叫醒那石猴？）。
雲對安全的最大影響在於防火牆的工作方式。防火牆根據IP地址允許或拒絕使用者訪問——使用者可以是個人，如員工或其他應用程式。這方面的最大變化是像亞馬遜網路服務（AWS）這樣的雲提供商現在已經將訪問控制權攥在自己手裡。他們擁有成熟的身份和訪問管理（IAM）工具，這些工具深深融入了他們自己的雲平臺。舉個例子，AWS IAM可以透過允許應用程式從S3儲存桶中獲取資料或將API呼叫傳送到AWS CloudTrail以進行日誌記錄來控制對EC2實體上執行的應用程式的訪問。它還可以定義基於角色的訪問控制（RBAC），只允許授權使用者檢視或更改應用程式的程式碼。從這個意義上說，AWS IAM（不使用傳統防火牆術語）其實履行了許多防火牆的職責。
另外，雲供應商已經建立了共享安全模型——即他們和客戶一起負責雲安全。他們在最基本的層面上關註安全性，並採取強有力的預設措施來避免惡意軟體攻擊。此外，AWS Inspector和AWS Macie等工具會自動掃描雲中的所有資源，以檢查漏洞。雖然雲供應商盡全力維護安全可靠，但安全問題通常會由於客戶未能在雲中很好的保護自己的資源而受到損害，例如儲存未加密的機密檔案，把S3搞成開放式終端或疏忽大意隨意同步資料到雲端[1]。
雲服務是一種新的技術，所以它承擔了一些關鍵的安全責任。但它也帶來了一些維護安全的不同方法，而這些都需要我們慢慢習慣。
從依賴外圍防火牆的簡單日子來看，雲使IT團隊的安全性更加細化。然而，隨著容器的出現，這個博弈的複雜程度到了一個新的高度（一沙一世界）。
首先是一切剛開始時，容器打的口號是“ 是物非心，是心非物，我就是我，不一樣的煙火（containers do not contain）[2]”。Linux安全專業人員對容器之間脆弱的行程間隔離表示了強烈的不滿，並且由於多個容器共享相同的宿主作業系統，因此不容易將漏洞傳播到相鄰容器。
然後是微服務架構的引入，其中單一應用程式被分解成多個相互依賴的服務。儘管“分而治之”的方法對於運營效率很有吸引力，但在將微服務彼此連線起來的網路中，人們會發現，任何安全專業人士都會打哈哈（不要逼我，再逼我……我就開始寫簡歷了）。服務需要在多對多網路中相互通訊——即服務網格（service mesh）。儘管它們之間的連線非常緊密，但需要有一種方法來確保每個服務都包含延遲，失敗實體和安全威脅，以便即使一個服務被取消，其他服務也能執行其功能，直到受影響的服務恢復。顯而易見，請求的數量和複雜的路由樣式似乎都是為了支援烏託邦式的基礎設施而付出的沉重的代價。如果現代雲原生應用程式沒有新型安全方法，尤其是網路安全性，情況將會更加嚴重。
今天的容器化應用重新定義了邊界的含義。它需要多方面的努力來充分保護雲原生應用程式。下麵我們一起來擼一擼“關鍵策略”。
容器映象是造成漏洞的主要原因，因為公共或共享的映象經常被染指並且對於生產環境而言是不安全的。容器登錄檔的映象掃描功能可以輕鬆掃描下載的所有容器映象。他們執行對常見已知漏洞的檢查，並遵循CIS Docker安全性基準。
重要的是，在執行容器時，它們需要作為非特權的非root容器執行。這可以防止漏洞傳播到其他容器和主機。此外，還需要採取措施保持容映象盡可能小——這也減少了攻擊的潛在可能性。此外，確保容器生命週期短（並且不超過一週）可以使你的系統更具動態性，並且不易發生漏洞。
容器網路現在是一個複雜的服務網格，無法手動配置。相反，你需要一套能夠根據需要自動啟用授權服務之間通訊的策略。像Weave，Linkerd和Project Calico這樣的工具都採用了這種方法，併在容器編排的早期使用者中得到廣泛採用。這對防火牆有影響。相較於有一個外圍防火牆，如果它被攻破，雖然會使整個系統安全降低，但是你現在有微型防火牆，它可以保護每項服務。因此，即使其中一項服務遭到破壞，其他服務仍然安全。
時下可用的容器安全和監控解決方案的數量很多，並且每個解決方案都迎合了整個安全難題的一個部分。將它們集合在一起並提供全面的安全是可提供端到端監控的威脅檢測工具。重要的是，在攻擊過程中，它識別出可疑樣式並迅速突出顯示攻擊的源頭和範圍。這需要使用機器學習進行高階資料分析，但隱藏了複雜性，同時允許安全團隊利用先進的安全措施，而無需專門的資料科學團隊。
在容器時代，日誌在SecOps中扮演了更為重要的角色。隨著大量的容器，大量的網路請求和不斷變化的狀態，日誌幫助詳細監控所有事件。在故障排除過程中它們至關重要。 日誌需要集中儲存，並透過專用的日誌分析工具輕鬆訪問。像Elasticsearch這樣強大的開源解決方案可以讓您輕鬆開始對容器進行日誌分析。
隨著基礎設施的變化和攻擊變得越來越複雜，安全解決方案也需要與時俱進。雲透過內部管理訪問控制，承擔了傳統防火牆的某些角色。隨著容器和微服務的進一步改變，外圍防火牆的安全策略已經過時。談笑間，傳統防火牆灰飛煙滅，應用安全的新方法更勝一籌（一念起，萬水千山；一念滅，滄海桑田）。
容器映象的特定容器安全性、基於策略的網路安全性、執行時的威脅檢測以及集中的日誌分析是保護微服務應用程式的新方法。莫回頭（simple security固然美好），免得濕了前方要走的路。儘管微服務世界的安全邊界已經變得模糊，但新的微邊界可以提供以前不可能的安全級別。這個承諾值得因此而帶來的所有複雜性（一沙一世界，一花一天堂）。
-
https://cloud.netapp.com/blog/synchronizing-data-to-s3-cloud-sync
-
https://opensource.com/business/14/7/docker-security-selinux
原文連結：https://thenewstack.io/defining-perimeter-microservices-world/
本次培訓內容包括：Docker容器的原理與基本操作；容器網路與儲存解析；Kubernetes的架構與設計理念詳解；Kubernetes的資源物件使用說明；Kubernetes 中的開放介面CRI、CNI、CSI解析；Kubernetes監控、網路、日誌管理；容器應用的開發流程詳解等，點選識別下方二維碼加微信好友瞭解具體培訓內容。
長按二維碼向我轉賬
![]()
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
知識星球