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