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

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

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

Kubernetes在授權(quán)方面的挑戰(zhàn)

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

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

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

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

輸入開放政策代理

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

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

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

跨混合云保護Kubernetes

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

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

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