隨著越來越多的組織將容器化應用程序轉移到生產環(huán)境中，Kubernetes已經成為在私有云、公共云和混合云環(huán)境中管理這些應用程序的有效方法。事實上，根據(jù)云原生計算基金會的調查，至少84%的組織已經在業(yè)務中使用容器，78%的組織利用Kubernetes來部署容器。
Kubernetes的強大功能和吸引力在于，與大多數(shù)現(xiàn)代API不同，Kubernetes API是基于意圖的，這意味著使用它的組織只需要考慮讓Kubernetes做什么，而不是他們希望采用Kubernetes如何實現(xiàn)這個目標。這是一個具有可擴展性、彈性且因此流行的系統(tǒng)。總而言之，Kubernetes加快了應用交付速度。
然而，云原生環(huán)境中的變化在設計上是不變的，這意味著其運行是非常動態(tài)的。動態(tài)性和大規(guī)模成為一個公認的風險解決方案，而當今的現(xiàn)代環(huán)境確實帶來了新的安全性、操作性和合規(guī)性的挑戰(zhàn)?？紤]以下問題：當工作負載僅存在幾微秒時，如何控制它的特權級別?當所有服務都是動態(tài)構建且只根據(jù)需要構建時，如何控制哪些服務可以訪問全球互聯(lián)網?混合云環(huán)境中的外圍在哪里?由于云原生應用程序是短暫且動態(tài)的，因此確保其安全的要求要復雜得多。
Kubernetes在授權方面的挑戰(zhàn)
而且，Kubernetes在授權方面面臨了獨特的挑戰(zhàn)。在過去，“授權”這個簡單的術語提出了人們可以執(zhí)行哪些操作或“誰可以執(zhí)行什么操作”的概念。但是在容器化的應用程序中，該概念已經得到更大擴展，也包括了哪個軟件或哪些機器可以執(zhí)行哪些操作(也稱為“什么可以做什么”)的概念。一些分析師開始使用“業(yè)務授權” 這個術語指代以帳戶為中心的規(guī)則，而“基礎設施授權”則用于其他所有內容。當給定的應用程序有一個由15名開發(fā)人員組成的團隊，但由具有數(shù)千個服務的數(shù)十個集群組成，并且它們之間有無數(shù)的連接時，很明顯，“能做什么”規(guī)則比以往任何時候都更加重要，并且開發(fā)人員需要用于在Kubernetes中創(chuàng)建、管理和擴展這些規(guī)則的工具。
因為Kubernetes API是基于YAML的，所以授權決策需要分析YAML的任意塊以做出決策。這些YAML塊應為每個工作負載定義配置。例如執(zhí)行一項策略，確保所有圖像都來自受信任的存儲庫，需要掃描YAML以找到所有容器的列表，在該列表上進行迭代，提取特定的圖像名稱，然后對該圖像名稱進行字符串解析。例如，另一個策略可能是“防止服務以root身份運行”，這將需要掃描YAML以找到容器列表，在這個列表上進行迭代以檢查是否有特定于容器的安全設置，然后組合這些設置具有全局安全性參數(shù)。不幸的是，沒有任何傳統(tǒng)的“業(yè)務授權”訪問控制解決方案(例如基于角色或基于屬性的訪問控制、IAM策略等)具有足夠強大的功能來強制執(zhí)行上述基本策略，甚至只需簡單更改Pod上的標簽。
即使在快速發(fā)展的容器世界中，只有一件事仍然保持不變：安全性的優(yōu)先級經常排在后面。如今，很多組織的DevSecOps團隊致力于將安全性轉移到開發(fā)周期中，但是如果沒有合適的工具，往往會在更晚的時候發(fā)現(xiàn)并補救挑戰(zhàn)和合規(guī)性問題。實際上，為了真正滿足DevOps流程的上市時間目標，必須在開發(fā)流程中更早地實施安全和合規(guī)性策略。事實證明，在開發(fā)的早期階段消除風險之后，安全策略才能發(fā)揮最大作用，這意味著在交付流程結束時不太可能出現(xiàn)安全問題。
但是，并非所有開發(fā)人員都是安全專家，并且對于不堪重負的DevOps團隊來說，確保對所有YAML配置進行人工檢查是保證成功的途徑。但是組織不必為了提高效率而犧牲安全性。開發(fā)人員需要適當?shù)陌踩ぞ撸ㄟ^實施護欄來消除失誤和風險，從而加快開發(fā)速度，從而確保Kubernetes部署符合法規(guī)要求。組織需要采用一種改進總體流程的方法，該方法對開發(fā)人員、運營、安全團隊和業(yè)務本身都是有益的。好消息是，有一些可與現(xiàn)代管道自動化和“作為代碼”模型一起使用的解決方案可以減少錯誤和工作量。
輸入開放政策代理
開放策略代理(OPA)越來越多地成為Kubernetes首選的“誰可以做什么”和“什么可以做什么”工具。開放策略代理(OPA)是由Styra公司創(chuàng)建的開源策略引擎，它為業(yè)務和基礎設施授權提供了與域無關的獨立規(guī)則引擎。開發(fā)人員發(fā)現(xiàn)開放策略代理(OPA)非常適合Kubernetes，因為它的設計前提是有時組織需要基于任意JSON/YAML編寫和實施訪問控制策略(以及許多其他策略)。開放策略代理(OPA)作為一種政策規(guī)范工具，可以提高Kubernetes開發(fā)的速度和自動化程度，同時提高安全性并降低風險。
實際上，Kubernetes是開放策略代理(OPA)最受歡迎的用例之一。如果組織不想為Kubernetes編寫、支持和維護自定義代碼，則可以將開放策略代理(OPA)用作Kubernetes接納控制器，并充分利用其聲明性策略語言Rego。例如，組織可以采用所有Kubernetes訪問控制策略(通常存儲在Wiki和PDF中以及人們的頭腦中)，并將它們轉換為策略即代碼。這些策略可以直接在集群上執(zhí)行，并且在Kubernetes上運行應用程序的開發(fā)人員在工作時無需經常引用內部Wiki和PDF策略。這樣可以減少錯誤，并在開發(fā)過程的早期消除不利部署，所有這些都可以提高生產率。
開放策略代理(OPA)可以幫助解決Kubernetes獨特挑戰(zhàn)的另一種方法是使用場景感知策略。這些策略決定了Kubernetes會根據(jù)有關存在的所有其他Kubernetes資源的信息來決定資源的決策。例如，組織可能要避免意外創(chuàng)建一個使用同一入口竊取另一個應用程序的全球互聯(lián)網流量的應用程序。在這種情況下，組織可以創(chuàng)建一個策略“禁止主機名沖突的入口”，以要求將任何新入口與現(xiàn)有入口進行比較。更重要的是，開放策略代理(OPA)確保Kubernetes的配置和部署符合內部策略和外部監(jiān)管要求，這對開發(fā)人員、運營和安全團隊來說都是雙贏的措施。
跨混合云保護Kubernetes
通常情況下，當人們說到“ Kubernetes”時，他們實際上是指在Kubernetes容器管理系統(tǒng)上運行的應用程序。這也是使用開放策略代理(OPA)的一種流行方式：讓開放策略代理(OPA)決定是否在應用程序內部授權微服務或最終用戶操作。因為涉及Kubernetes環(huán)境，開放策略代理(OPA)提供了一個完整的工具包，用于測試、試運行、調整以及將聲明性策略集成到任意數(shù)量的應用程序和基礎設施組件中。
實際上，開發(fā)人員經常擴大對開放策略代理(OPA)的使用，以在其所有Kubernetes集群中實施策略并提高安全性，尤其是在混合云環(huán)境中。為此，許多用戶還利用了Styra DAS，這有助于在運行前驗證開放策略代理(OPA)安全策略，以查看其影響，將其分發(fā)到任意數(shù)量的Kubernetes集群中，然后連續(xù)監(jiān)視策略以確保它們具有預期的效果。
無論組織在云計算和容器旅程中的哪個地方， Kubernetes現(xiàn)在都是在生產中部署容器的標準。Kubernetes環(huán)境帶來了組織必須解決的新的獨特挑戰(zhàn)，以確保其云計算環(huán)境中的安全性和合規(guī)性，但是確實存在解決方案限制對基礎思維的需求。為了大規(guī)模地解決這些挑戰(zhàn)，開放策略代理(OPA)已經成為事實上的標準，可以通過自動策略執(zhí)行來幫助組織降低風險并加快應用交付。
版權聲明：本文為企業(yè)網D1Net編譯，轉載需注明出處為：企業(yè)網D1Net，如果不注明出處，企業(yè)網D1Net將保留追究其法律責任的權利。
京公網安備 11010502049343號