在云原生時代，我們經常聽到“沒有安全，就沒有一切”，這意味著安全比任何事情都重要。
現代基礎設施和解決方案讓我們受益匪淺，但與此同時，由于有更多的應用服務，所以會有更多的事情需要擔心：比如如何控制對基礎設施的訪問？如何控制服務之間的訪問？每個人的訪問權限等。
在眾多需要回答的問題中，還包括策略方面的：比如一大堆的安全規則、標準和條件。比如：
誰可以訪問此資源？
允許來自哪個子網出口流量？
工作負載必須部署到哪些集群？
哪些協議不允許用于從互聯網訪問的服務器？
可以從哪些注冊表二進制文件下載？
容器可以使用哪些操作系統執行功能？
一天中的哪些時間可以訪問系統？
所有組織都有策略，因為它們明確了有關遵守法律要求、在技術約束下工作、避免重復錯誤等重要知識。
為什么選擇策略即代碼？
策略是基于滲透到組織文化中的成文或不成文的規則。因此，假如我們的組織有一條書面規則明確要求：
對于從Internet上公共子網訪問的服務器，使用不安全的“HTTP”協議公開端口不是一個好的做法。
那么我們應該如何執行它？
如果我們手動創建基礎設施，“四眼原則”可能會有所幫助。但前提是在做關鍵事情時，總是有第二個人在一起。
如果我們使用基礎設施即代碼，并使用 Terraform 等工具自動創建基礎設施，那么代碼審查可能會有所幫助。
但是，傳統的策略實施過程有幾個明顯的缺點：
不能保證此政策永遠不會被打破。人們無法始終了解所有策略，并且根據策略列表進行手動檢查是不切實際的。對于代碼審查，即使是高級工程師也不太可能每次都發現所有潛在問題。
現代組織是敏捷的，這意味著員工、服務和團隊都在持續增長，無法讓安全團隊使用傳統技術來保護所有資產。
由于人為錯誤，政策遲早會被違反。這不是“如果”的問題，而是“何時”的問題。這也正是大多數組織在主要版本發布之前進行定期安全檢查和合規性審查的原因--我們首先違反政策，然后創建事后修復。
這樣做不太科學。那么，管理和實施策略的正確方法是什么？
什么是策略即代碼 （PaC）？
隨著業務、團隊成熟度的發展，我們希望從手動定義策略，轉變為從企業層面上更易于管理和可重復的定義策略。
如何做到這一點？首先，我們可以從大規模管理系統的成功實驗中學習：
基礎結構即代碼 （IaC）：將定義環境和基礎結構的內容視為源代碼。
DevOps：人員、流程和自動化的結合，實現“持續的一切”，持續為最終用戶提供價值。
策略即代碼（PaC）誕生于這些想法。
策略即代碼使用代碼來定義和管理策略，這些策略是規則和條件。使用代碼和利用源代碼管理 （SCM） 工具定義、更新、共享和實施策略。通過將策略定義保留在源代碼控制中，無論何時進行更改，都可以對其進行測試、驗證，然后執行。PaC 的目標不是檢測違反策略的行為，而是防止它們犯錯誤。這利用了 DevOps 自動化功能，而不是依賴手動流程，使團隊能夠更快地行動，并減少由于人為錯誤而導致錯誤的可能性。
策略即代碼與基礎結構即代碼
“即代碼”運動并不是新鮮事務，它的目標是“連續的一切”。PaC 的概念可能聽起來類似于基礎結構即代碼 （IaC），但 IaC 側重于基礎結構和預配，而 PaC 改進了安全操作、合規性管理、數據管理等。
PaC 可以與 IaC 集成，以自動實施基礎結構策略。
現在我們已經解決了 PaC 與 IaC 的問題，讓我們看一下實現 PaC 的工具。
開放策略代理 （OPA） 簡介
開放策略代理（OPA，發音為“oh-pa”）是云原生計算基金會孵化項目。它是一個開源的通用策略引擎，旨在為將策略即代碼應用于任何領域提供通用框架。
OPA 提供了一種高級聲明性語言（Rego，發音為“ray-go”，專為策略構建），允許您將策略指定為代碼。因此，您可以在微服務、Kubernetes、CI/CD、API 網關等中定義、實施和實施策略。
簡而言之，OPA的工作方式是將決策與政策執行脫鉤。當需要做出策略決策時，使用結構化數據（例如 JSON）作為輸入來查詢 OPA，然后 OPA 返回決策：
先決條件
要開始使用，請從 GitHub 版本下載適用于您的平臺的 OPA 二進制文件：
在 macOS（64 位）上：
在 M1 Mac 上測試，也可以工作。
規范
讓我們從一個簡單的示例開始，為虛構的工資單微服務實現基于訪問的訪問控制 （ABAC）。
規則很簡單：您只能訪問您的工資信息或下屬的工資信息，而不能訪問其他任何人的工資信息。因此，如果是您自己的，或者是您下屬的，那么以訪問以下內容：bob john
- /getSalary/bob
- /getSalary/john
但是不能以用戶身份訪問：/getSalary/alicebob
輸入數據和Rego文件
假設我們有結構化輸入數據（文件）：input.json
讓我們創建一個Rego文件。在這里，注釋會讓你很好地理解這段代碼的作用：
文件：example.rego
運行
以下值應計算為：true
改變輸入中的路徑.json文件到"path": ["getSalary"， "john"]，它的值仍然為“true”，因為第二條規則允許經理查看下屬的工資。
但是，如果我們改變輸入的路徑.json文件到"path": ["getSalary"， "alice"]，結果就是false。
策略即代碼集成
上面的例子非常簡單，只對掌握 OPA 工作原理的基礎知識有用。但是 OPA 功能很強大，可以與當今許多主流工具和平臺集成，例如：
Kubernetes
Envoy
AWS CloudFormation
Docker
Terraform
Kafka
Ceph
等等。
為了快速演示 OPA 的功能，下面是在 AWS 上定義自動擴展組和服務器的 Terraform 代碼示例：
使用此 Rego 代碼，我們可以根據 Terraform 計劃計算分數，并根據策略返回決策。自動化該過程非常容易：
terraform plan -out tfplan以創建Terraform規劃
terraform show -json tfplan | jq > tfplan.json將計劃轉換為 JSON 格式
opa exec --decision terraform/analysis/authz --bundle policy/ tfplan.json以獲得結果。
