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

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

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

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

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

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

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

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

輸入開(kāi)放政策代理

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

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

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

跨混合云保護(hù)Kubernetes

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

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

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