隨著越來越多的組織將容器化應用程序轉移到生產環境中，Kubernetes已經成為在私有云、公共云和混合云環境中管理這些應用程序的有效方法。事實上，根據云原生計算基金會的調查，至少84%的組織已經在業務中使用容器，78%的組織利用Kubernetes來部署容器。

 

Kubernetes的強大功能和吸引力在于，與大多數現代API不同，Kubernetes API是基于意圖的，這意味著使用它的組織只需要考慮讓Kubernetes做什么，而不是他們希望采用Kubernetes如何實現這個目標。這是一個具有可擴展性、彈性且因此流行的系統。總而言之，Kubernetes加快了應用交付速度。

 

然而，云原生環境中的變化在設計上是不變的，這意味著其運行是非常動態的。動態性和大規模成為一個公認的風險解決方案，而當今的現代環境確實帶來了新的安全性、操作性和合規性的挑戰。考慮以下問題：當工作負載僅存在幾微秒時，如何控制它的特權級別?當所有服務都是動態構建且只根據需要構建時，如何控制哪些服務可以訪問全球互聯網?混合云環境中的外圍在哪里?由于云原生應用程序是短暫且動態的，因此確保其安全的要求要復雜得多。

 

 

而且，Kubernetes在授權方面面臨了獨特的挑戰。在過去，“授權”這個簡單的術語提出了人們可以執行哪些操作或“誰可以執行什么操作”的概念。但是在容器化的應用程序中，該概念已經得到更大擴展，也包括了哪個軟件或哪些機器可以執行哪些操作(也稱為“什么可以做什么”)的概念。一些分析師開始使用“業務授權” 這個術語指代以帳戶為中心的規則，而“基礎設施授權”則用于其他所有內容。當給定的應用程序有一個由15名開發人員組成的團隊，但由具有數千個服務的數十個集群組成，并且它們之間有無數的連接時，很明顯，“能做什么”規則比以往任何時候都更加重要，并且開發人員需要用于在Kubernetes中創建、管理和擴展這些規則的工具。

 

因為Kubernetes API是基于YAML的，所以授權決策需要分析YAML的任意塊以做出決策。這些YAML塊應為每個工作負載定義配置。例如執行一項策略，確保所有圖像都來自受信任的存儲庫，需要掃描YAML以找到所有容器的列表，在該列表上進行迭代，提取特定的圖像名稱，然后對該圖像名稱進行字符串解析。例如，另一個策略可能是“防止服務以root身份運行”，這將需要掃描YAML以找到容器列表，在這個列表上進行迭代以檢查是否有特定于容器的安全設置，然后組合這些設置具有全局安全性參數。不幸的是，沒有任何傳統的“業務授權”訪問控制解決方案(例如基于角色或基于屬性的訪問控制、IAM策略等)具有足夠強大的功能來強制執行上述基本策略，甚至只需簡單更改Pod上的標簽。

 

即使在快速發展的容器世界中，只有一件事仍然保持不變：安全性的優先級經常排在后面。如今，很多組織的DevSecOps團隊致力于將安全性轉移到開發周期中，但是如果沒有合適的工具，往往會在更晚的時候發現并補救挑戰和合規性問題。實際上，為了真正滿足DevOps流程的上市時間目標，必須在開發流程中更早地實施安全和合規性策略。事實證明，在開發的早期階段消除風險之后，安全策略才能發揮最大作用，這意味著在交付流程結束時不太可能出現安全問題。

 

但是，并非所有開發人員都是安全專家，并且對于不堪重負的DevOps團隊來說，確保對所有YAML配置進行人工檢查是保證成功的途徑。但是組織不必為了提高效率而犧牲安全性。開發人員需要適當的安全工具，通過實施護欄來消除失誤和風險，從而加快開發速度，從而確保Kubernetes部署符合法規要求。組織需要采用一種改進總體流程的方法，該方法對開發人員、運營、安全團隊和業務本身都是有益的。好消息是，有一些可與現代管道自動化和“作為代碼”模型一起使用的解決方案可以減少錯誤和工作量。

 

 

開放策略代理(OPA)越來越多地成為Kubernetes首選的“誰可以做什么”和“什么可以做什么”工具。開放策略代理(OPA)是由Styra公司創建的開源策略引擎，它為業務和基礎設施授權提供了與域無關的獨立規則引擎。開發人員發現開放策略代理(OPA)非常適合Kubernetes，因為它的設計前提是有時組織需要基于任意JSON/YAML編寫和實施訪問控制策略(以及許多其他策略)。開放策略代理(OPA)作為一種政策規范工具，可以提高Kubernetes開發的速度和自動化程度，同時提高安全性并降低風險。

 

實際上，Kubernetes是開放策略代理(OPA)最受歡迎的用例之一。如果組織不想為Kubernetes編寫、支持和維護自定義代碼，則可以將開放策略代理(OPA)用作Kubernetes接納控制器，并充分利用其聲明性策略語言Rego。例如，組織可以采用所有Kubernetes訪問控制策略(通常存儲在Wiki和PDF中以及人們的頭腦中)，并將它們轉換為策略即代碼。這些策略可以直接在集群上執行，并且在Kubernetes上運行應用程序的開發人員在工作時無需經常引用內部Wiki和PDF策略。這樣可以減少錯誤，并在開發過程的早期消除不利部署，所有這些都可以提高生產率。

 

開放策略代理(OPA)可以幫助解決Kubernetes獨特挑戰的另一種方法是使用場景感知策略。這些策略決定了Kubernetes會根據有關存在的所有其他Kubernetes資源的信息來決定資源的決策。例如，組織可能要避免意外創建一個使用同一入口竊取另一個應用程序的全球互聯網流量的應用程序。在這種情況下，組織可以創建一個策略“禁止主機名沖突的入口”，以要求將任何新入口與現有入口進行比較。更重要的是，開放策略代理(OPA)確保Kubernetes的配置和部署符合內部策略和外部監管要求，這對開發人員、運營和安全團隊來說都是雙贏的措施。

 

 

通常情況下，當人們說到“ Kubernetes”時，他們實際上是指在Kubernetes容器管理系統上運行的應用程序。這也是使用開放策略代理(OPA)的一種流行方式：讓開放策略代理(OPA)決定是否在應用程序內部授權微服務或最終用戶操作。因為涉及Kubernetes環境，開放策略代理(OPA)提供了一個完整的工具包，用于測試、試運行、調整以及將聲明性策略集成到任意數量的應用程序和基礎設施組件中。

 

實際上，開發人員經常擴大對開放策略代理(OPA)的使用，以在其所有Kubernetes集群中實施策略并提高安全性，尤其是在混合云環境中。為此，許多用戶還利用了Styra DAS，這有助于在運行前驗證開放策略代理(OPA)安全策略，以查看其影響，將其分發到任意數量的Kubernetes集群中，然后連續監視策略以確保它們具有預期的效果。

 

無論組織在云計算和容器旅程中的哪個地方， Kubernetes現在都是在生產中部署容器的標準。Kubernetes環境帶來了組織必須解決的新的獨特挑戰，以確保其云計算環境中的安全性和合規性，但是確實存在解決方案限制對基礎思維的需求。為了大規模地解決這些挑戰，開放策略代理(OPA)已經成為事實上的標準，可以通過自動策略執行來幫助組織降低風險并加快應用交付。

 

版權聲明：本文為企業網D1Net編譯，轉載需注明出處為：企業網D1Net，如果不注明出處，企業網D1Net將保留追究其法律責任的權利。