隨著您的組織擁抱云，您可能會發現云原生堆棧的動態性和規模需要更加復雜的安全性和合規性。例如，隨著像Kubernetes這樣的容器編排平臺越來越受關注，開發人員和開發人員團隊對策略領域（如準入控制）以及更傳統的領域（如計算，存儲和網絡）負有新的責任。同時，每個應用程序，微服務或服務網格都需要一套自己的授權策略，開發人員對此很有幫助。

出于這些原因，我們開始尋找一種更簡單，更省時的方法來在云中創建、實施和管理策略。OPA（輸入開放策略代理）于4年前創建，它是一個與域無關的開源策略引擎，正在成為云原生策略的事實上的標準。事實上，OPA已經被Netflix，Pinterest和Goldman Sachs等公司用于生產，用于Kubernetes準入控制和微服務API授權等用例。OPA還支持許多您已經知道和喜歡的云原生工具，包括Atlassian套件和Chef Automate。

OPA為云原生組織提供了統一的策略語言，這樣，就可以在應用程序、API、基礎架構等中以通用的方式表達授權決策，而無需將定制的策略硬編碼到每種不同的語言和工具中。此外，由于OPA是為授權而專門設計的，因此它提供了越來越多的性能優化集合，因此策略作者可以將大部分時間用于編寫正確，可維護的策略，并將性能留給OPA。

OPA授權策略在堆棧中有很多很多用例-從在容器編排周圍放置防護欄到控制SSH訪問或提供基于上下文的服務網格授權。但是，有三種流行的用例為許多OPA用戶提供了良好的啟動平臺：應用程序授權，Kubernetes準入控制和微服務。

申請授權的OPA

授權策略無處不在，因為幾乎每個應用程序都需要授權策略。但是，開發人員通常會“滾動自己的”代碼，這不僅耗時，而且會導致難以維護的工具和策略拼湊而成。盡管授權對于每個應用程序都是至關重要的，但是花在創建策略上的時間意味著更少的時間集中在面向用戶的功能上。

OPA使用專用的聲明性策略語言來簡化授權策略的開發。例如，您可以創建和強制執行簡單的策略，例如“如果您是承包商，則不能閱讀PII”或“ Jane可以訪問此帳戶”。但這僅僅是開始。因為OPA具有上下文感知能力，所以您還可以制定考慮地球上任何事物的策略，例如，“在交易日的最后一小時請求進行股票交易，這將導致超過一百萬美元的交易，只能在以下時間執行：給定名稱空間中的特定服務。”

當然，許多組織已經有定制的授權。但是，如果您希望在云中分解應用程序并擴展微服務，同時又保持開發人員的效率，那么就需要分布式授權系統。對于許多人來說，OPA是缺少的拼圖。

用于Kubernetes接納控制的OPA

許多用戶還使用OPA為Kubernetes創建防護欄。Kubernetes本身已經成為主流和關鍵任務，并且組織正在尋找定義和實施安全護欄以幫助減輕安全和合規風險的方法。管理員可以使用OPA制定清晰的策略，以便開發人員可以加快管道生產并迅速將新服務推向市場，而不必擔心運營，安全或合規風險。

OPA可用于創建策略，以拒絕使用相同主機名的入口，或者要求所有容器映像都來自受信任的注冊表的策略，或者確保始終用加密位標記所有存儲，或者確保每個應用公開互聯網上使用批準的域名-僅舉幾個例子。

由于OPA直接與Kubernetes API服務器集成，因此它可以拒絕跨計算，網絡，存儲等策略禁止的任何資源。對于開發人員特別有利的是，您可以在開發周期的早期（例如在CI / CD管道中）公開這些策略，以便開發人員可以及早獲得反饋并在運行時修復問題。此外，您甚至可以帶外驗證策略，以確保它們達到預期的效果并且不會無意中引起麻煩。

微服務的OPA

最后，OPA在幫助組織控制其微服務和服務網格體系結構方面變得非常流行。借助OPA，您可以直接為微服務創建和實施授權策略（通常是作為補充工具），在服務網格內構建服務到服務策略，或者從安全角度出發，創建限制服務網格內橫向移動的策略。建筑。

為云原生架構構建統一策略

一般而言，使用OPA的總體目標是創建一種統一的方法來跨您的云原生堆棧創建策略-因此，您不必通過廣告、部落知識、百科和PDF的臨時混合，或一堆錯配的工具。

除了簡化開發和加快交付速度外，這對于安全性也是一個重大新聞，因為OPA減少了您需要檢查的工具數量，例如，您是否懷疑是否嘗試了未經授權的訪問。同樣，從操作和合規性角度來看，OPA使得在異構環境中提取和分析信息變得更加容易-幫助您快速發現問題并更快地解決問題。

開發人員正在尋找一種更簡單，更有效的方法來為其云原生環境創建和管理基于策略的控件。對于許多人來說，該解決方案就是OPA。如果您發現自己在多個地方，使用多種語言或在多個團隊中接觸授權策略，OPA可以像為他們一樣幫助您消除冗余并加快交付速度。
責任編輯：tzh