關注留言點讚，帶你了解最流行的軟體開發知識與最新科技行業趨勢。
了解策略即代碼的好處，並開始測試您的雲原生環境策略。
在雲原生時代，我們經常聽到「安全是零任務」，這意味著它甚至比任何第一要務都重要。
現代基礎設施和方法給我們帶來了巨大的好處，但與此同時，由於有更多的活動部件，因此需要擔心的事情也更多：如何控制對您的基礎設施的訪問？如何控制服務之間的訪問？誰可以訪問什麼？等等。
有許多問題需要回答，包括策略：一堆安全規則、標準和條件。例子：
誰可以訪問此資源？
允許來自哪個子網的出口流量？
工作負載必須部署到哪些集群？
哪些協議不允許從 Internet 訪問伺服器？
可以從哪些註冊表二進位文件下載？
容器可以執行哪些作業系統功能？
一天中的哪些時間可以訪問系統？
所有組織都有政策，因為它們編碼了有關遵守法律要求、在技術限制內工作、避免重複錯誤等的重要知識。
由於政策在今天如此重要，讓我們更深入地探討如何在雲原生時代最好地處理它們。
為什麼政策即代碼？
政策基於滲透到組織文化中的成文或不成文的規則。因此，例如，我們的組織中可能有一條書面規則明確表示：
我們如何執行它？
如果我們手動創建基礎設施，四眼原則可能會有所幫助。但首先，在做一些重要的事情時，總是要有第二個人在一起。
如果我們將基礎設施作為代碼並使用 Terraform 等工具自動創建我們的基礎設施，代碼審查可能會有所幫助。
然而，傳統的策略執行過程有一些明顯的缺點：
你不能保證這個政策永遠不會被打破。人們不可能在任何時候都知道所有的策略，並且手動檢查策略列表是不切實際的。對於代碼審查，即使是高級工程師也不太可能每次都發現所有潛在問題。
儘管我們擁有世界上最好的團隊，可以無一例外地執行政策，但如果可能的話，很難擴大規模。現代組織更有可能是敏捷的，這意味著許多員工、服務和團隊會繼續成長。沒有辦法使用傳統技術為安全團隊配備人員來保護所有這些資產。
由於人為錯誤，政策遲早會（並且將會）被破壞。這不是「如果」的問題，而是「何時」的問題。這正是大多數組織（如果不是全部）在主要版本發布之前定期進行安全檢查和合規性審查的原因。我們首先違反政策，然後創建事後修復。
什麼是策略即代碼 (PaC)？
隨著業務、團隊和成熟度的提高，我們希望從手動策略定義轉變為在企業範圍內更易於管理和可重複的策略。
我們該怎麼做？首先，我們可以從大規模管理系統的成功實驗中學習：
基礎架構即代碼 (IaC)：將定義您的環境和基礎架構的內容視為原始碼。
DevOps：人、流程和自動化的結合，以實現「連續的一切」，持續為最終用戶提供價值。
Policy-as-Code (PaC) 就是從這些想法中誕生的。
策略即代碼使用代碼來定義和管理策略，即規則和條件。使用代碼和利用原始碼管理 (SCM) 工具定義、更新、共享和執行策略。通過在原始碼控制中保留策略定義，無論何時進行更改，都可以對其進行測試、驗證，然後執行。PaC 的目標不是檢測策略違規，而是防止它們。這利用了 DevOps 自動化功能而不是依賴手動流程，使團隊能夠更快地行動並減少由於人為錯誤而導致錯誤的可能性。
「as code」運動不再新鮮；它的目標是「連續的一切」。PaC 的概念聽起來可能類似於基礎設施即代碼 (IaC)，但 IaC 側重於基礎設施和供應，而 PaC 則改進了安全操作、合規性管理、數據管理等。
PaC 可以與 IaC 集成以自動執行基礎設施策略。
現在我們已經解決了 PaC 與 IaC 的問題，讓我們看看實現 PaC 的工具。
開放策略代理（OPA）簡介
Open Policy Agent（OPA，發音為「oh-pa」）是雲原生計算基金會的一個孵化項目。它是一個開源的通用策略引擎，旨在提供一個通用框架，用於將策略即代碼應用於任何領域。
OPA 提供了一種高級聲明性語言（Rego，發音為「ray-go」，專為策略而構建），允許您將策略指定為代碼。因此，您可以在微服務、Kubernetes、CI/CD 管道、API 網關等中定義、實施和強制執行策略。
簡而言之，OPA 的工作方式是將決策制定與政策執行脫鉤。當需要做出策略決策時，您使用結構化數據（例如 JSON）作為輸入查詢 OPA，然後 OPA 返回決策：
好的，少說話，多工作：給我看代碼。
簡單演示：Open Policy Agent 示例
先決條件
首先，從 GitHub releases 下載適用於您的平台的 OPA 二進位文件：
在 macOS（64 位）上：
curl -L -o opa https://openpolicyagent.org/downloads/v0.46.1/opa_darwin_amd64
chmod 755 ./opa
在 M1 mac 上測試，同樣有效。
規格
讓我們從一個簡單的示例開始，為虛構的薪資微服務實現基於訪問的訪問控制 (ABAC)。
規則很簡單：您只能訪問自己或下屬的工資信息，不能訪問其他任何人的信息。因此，如果您是bob，並且john是您的下屬，那麼您可以訪問以下內容：
/getSalary/john
但是/getSalary/alice作為用戶訪問bob是不可能的。
輸入數據和 Rego 文件
假設我們有結構化輸入數據（input.json文件）：
{ "user": "bob",
"method": "GET",
"path": ["getSalary", "bob"],
"managers": {
"bob": ["john"]
}
}
讓我們創建一個 Rego 文件。在這裡我們不會過多地關注 Rego 的語法，但是注釋會讓您很好地理解這段代碼的作用：
檔案example.rego：
package example
default allow = false # default: not allow
allow = true { # allow if:
input.method == "GET" # method is GET
input.path = ["getSalary", person]
}
allow = true { # allow if:
input.method == "GET" # method is GET
input.path = ["getSalary", person]
managers := input.managers[input.user][_]
contains(managers, person) # input user is the person's manager
}
跑步
以下應評估為true：
./opa eval -i input.json -d example.rego "data.example"
將文件path中的更改為，它仍然計算為，因為第二條規則允許經理檢查其下屬的薪水。input.json"path": ["getSalary", "john"]true
但是，如果我們path將input.json文件中的 更改為"path": ["getSalary", "alice"]，它將計算為false.
開始了。現在我們有了一個簡單的微服務 ABAC 工作解決方案！
策略即代碼集成
上面的示例非常簡單，僅對掌握 OPA 工作原理的基礎知識有用。但 OPA 更強大，可以與當今許多主流工具和平台集成，例如：
- Kubernetes
- Envoy
- AWS CloudFormation
- Docker
- Terraform
- Kafka
- Ceph
為了快速演示 OPA 的功能，這裡有一個 Terraform 代碼示例，它定義了一個自動擴展組和 AWS 上的一個伺服器：
使用此 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得到結果。