什么是策略即代碼？開放策略代理簡介

譯文 精選 2023-02-03 17:37:08

云計算 OPA 提供了一種高級聲明性語言（Rego，專為策略構建），允許您將策略指定為代碼。因此，您可以在微服務、Kubernetes、CI/CD、API 網關等中定義、實施和實施策略。

在云原生時代，我們經常聽到“沒有安全，就沒有一切”，這意味著安全比任何事情都重要。

現代基礎設施和解決方案讓我們受益匪淺，但與此同時，由于有更多的應用服務，所以會有更多的事情需要擔心：比如如何控制對基礎設施的訪問？如何控制服務之間的訪問？每個人的訪問權限等。

在眾多需要回答的問題中，還包括策略方面的：比如一大堆的安全規(guī)則、標準和條件。比如：

誰可以訪問此資源？

允許來自哪個子網出口流量？

工作負載必須部署到哪些集群？

哪些協議不允許用于從互聯網訪問的服務器？

可以從哪些注冊表二進制文件下載？

容器可以使用哪些操作系統(tǒng)執(zhí)行功能？

一天中的哪些時間可以訪問系統(tǒng)？

所有組織都有策略，因為它們明確了有關遵守法律要求、在技術約束下工作、避免重復錯誤等重要知識。

為什么選擇策略即代碼？

策略是基于滲透到組織文化中的成文或不成文的規(guī)則。因此，假如我們的組織有一條書面規(guī)則明確要求：

對于從Internet上公共子網訪問的服務器，使用不安全的“HTTP”協議公開端口不是一個好的做法。

那么我們應該如何執(zhí)行它？

如果我們手動創(chuàng)建基礎設施，“四眼原則”可能會有所幫助。但前提是在做關鍵事情時，總是有第二個人在一起。

如果我們使用基礎設施即代碼，并使用 Terraform 等工具自動創(chuàng)建基礎設施，那么代碼審查可能會有所幫助。

但是，傳統(tǒng)的策略實施過程有幾個明顯的缺點：

不能保證此政策永遠不會被打破。人們無法始終了解所有策略，并且根據策略列表進行手動檢查是不切實際的。對于代碼審查，即使是高級工程師也不太可能每次都發(fā)現所有潛在問題。

現代組織是敏捷的，這意味著員工、服務和團隊都在持續(xù)增長，無法讓安全團隊使用傳統(tǒng)技術來保護所有資產。

由于人為錯誤，政策遲早會被違反。這不是“如果”的問題，而是“何時”的問題。這也正是大多數組織在主要版本發(fā)布之前進行定期安全檢查和合規(guī)性審查的原因--我們首先違反政策，然后創(chuàng)建事后修復。

這樣做不太科學。那么，管理和實施策略的正確方法是什么？

什么是策略即代碼 （PaC）？

隨著業(yè)務、團隊成熟度的發(fā)展，我們希望從手動定義策略，轉變?yōu)閺钠髽I(yè)層面上更易于管理和可重復的定義策略。

如何做到這一點？首先，我們可以從大規(guī)模管理系統(tǒng)的成功實驗中學習：

基礎結構即代碼 （IaC）：將定義環(huán)境和基礎結構的內容視為源代碼。

DevOps：人員、流程和自動化的結合，實現“持續(xù)的一切”，持續(xù)為最終用戶提供價值。

策略即代碼（PaC）誕生于這些想法。

策略即代碼使用代碼來定義和管理策略，這些策略是規(guī)則和條件。使用代碼和利用源代碼管理 （SCM） 工具定義、更新、共享和實施策略。通過將策略定義保留在源代碼控制中，無論何時進行更改，都可以對其進行測試、驗證，然后執(zhí)行。PaC 的目標不是檢測違反策略的行為，而是防止它們犯錯誤。這利用了 DevOps 自動化功能，而不是依賴手動流程，使團隊能夠更快地行動，并減少由于人為錯誤而導致錯誤的可能性。

策略即代碼與基礎結構即代碼

“即代碼”運動并不是新鮮事務，它的目標是“連續(xù)的一切”。PaC 的概念可能聽起來類似于基礎結構即代碼 （IaC），但 IaC 側重于基礎結構和預配，而 PaC 改進了安全操作、合規(guī)性管理、數據管理等。

PaC 可以與 IaC 集成，以自動實施基礎結構策略。

現在我們已經解決了 PaC 與 IaC 的問題，讓我們看一下實現 PaC 的工具。

開放策略代理 （OPA） 簡介

開放策略代理（OPA，發(fā)音為“oh-pa”）是云原生計算基金會孵化項目。它是一個開源的通用策略引擎，旨在為將策略即代碼應用于任何領域提供通用框架。

OPA 提供了一種高級聲明性語言（Rego，發(fā)音為“ray-go”，專為策略構建），允許您將策略指定為代碼。因此，您可以在微服務、Kubernetes、CI/CD、API 網關等中定義、實施和實施策略。

簡而言之，OPA的工作方式是將決策與政策執(zhí)行脫鉤。當需要做出策略決策時，使用結構化數據（例如 JSON）作為輸入來查詢 OPA，然后 OPA 返回決策：

先決條件

要開始使用，請從 GitHub 版本下載適用于您的平臺的 OPA 二進制文件：

在 macOS（64 位）上：

在 M1 Mac 上測試，也可以工作。

規(guī)范

讓我們從一個簡單的示例開始，為虛構的工資單微服務實現基于訪問的訪問控制 （ABAC）。

規(guī)則很簡單：您只能訪問您的工資信息或下屬的工資信息，而不能訪問其他任何人的工資信息。因此，如果是您自己的，或者是您下屬的，那么以訪問以下內容：bob john

• /getSalary/bob
• /getSalary/john

但是不能以用戶身份訪問：/getSalary/alicebob

輸入數據和Rego文件

假設我們有結構化輸入數據（文件）：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 代碼，我們可以根據 Terraform 計劃計算分數，并根據策略返回決策。自動化該過程非常容易：

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以獲得結果。

標題名稱：什么是策略即代碼？開放策略代理簡介
文章URL：http://www.5511xx.com/article/cohjopp.html