OPA CLI Rego 策略測試與套件簽章

OPA 提供強大的 CLI 工具，讓開發者能有效驗證 Rego 策略的正確性。透過撰寫測試案例，涵蓋各種輸入情境，並使用 opa test 命令執行，可以精確找出策略中的錯誤。輸出結果的詳細分析，包含執行時間和錯誤訊息，有助於快速除錯和最佳化策略。此外，套件簽章機制確保了策略的完整性和來源可信度，對於軟體供應鏈安全至關重要。透過 OpenSSL 產生金鑰並使用 opa build 命令簽署套件，可以有效防止惡意竄改。最後，WebAssembly 的整合讓 OPA 的功能得以進一步擴充套件，為更複雜的應用場景提供支援。

使用OPA CLI進行Rego策略測試

在前一章節中，我們探討瞭如何撰寫Rego策略。本章節將深入介紹如何使用Open Policy Agent（OPA）命令列介面（CLI）來測試這些策略。

編寫測試案例

測試是確保Rego策略正確性的關鍵步驟。以下是一個簡單的測試案例，用於驗證我們之前編寫的hello策略：

import rego.v1

test_hello_pass if {
    ch2.hello with input as {"message": "world"}
}

test_hello_fail if {
    ch2.hello with input as {"message": "goodbye"}
}

內容解密：

import rego.v1：匯入Rego v1版本，這是為了確保我們的測試程式碼與最新的OPA版本相容。
test_hello_pass和test_hello_fail：這兩個測試案例分別驗證了當輸入訊息為"world"和"goodbye"時，hello策略的行為。
ch2.hello with input as {"message": "world"}：這行程式碼呼叫了ch2套件中的hello規則，並將輸入設定為{"message": "world"}。
test_hello_fail預期會失敗，因為輸入訊息不是"world"。

執行測試

使用以下命令執行測試：

$ opa test . -v

輸出結果如下：

FAILURES
------------------------------------------------------------------------------
data.examples.ch2_test.test_hello_fail: FAIL (82.5μs)
query:1 Enter data.examples.ch2_test.test_hello_fail = _
helloworld_test.rego:11 | Enter data.examples.ch2_test.test_hello_fail
helloworld.rego:7 | | Enter data.examples.ch2.hello
helloworld.rego:9 | | | Fail msg = "world"
helloworld_test.rego:12 | | Fail data.examples.ch2.hello with input as {"message": "goodbye"}
query:1 | Fail data.examples.ch2_test.test_hello_fail = _
SUMMARY
------------------------------------------------------------------------------
helloworld_test.rego:
data.examples.ch2_test.test_hello_pass: PASS (177.083μs)
data.examples.ch2_test.test_hello_fail: FAIL (82.5μs)
------------------------------------------------------------------------------
PASS: 1/2
FAIL: 1/2

內容解密：

opa test . -v命令會在當前目錄下執行所有測試，並顯示詳細的測試結果。
test_hello_fail失敗是預期的，因為輸入的訊息不是"world"。
詳細的輸出結果幫助我們理解測試的執行過程和失敗的原因。

使用JSON格式輸出測試結果

可以使用-f json選項將測試結果以JSON格式輸出，便於自動化處理：

$ opa test . -v -f json

輸出結果如下：

[
    {
        "location": {
            "file": "helloworld_test.rego",
            "row": 6,
            "col": 1
        },
        "package": "data.examples.ch2_test",
        "name": "test_hello_pass",
        "duration": 1380291
    },
    {
        "location": {
            "file": "helloworld_test.rego",
            "row": 10,
            "col": 1
        },
        "package": "data.examples.ch2_test",
        "name": "test_hello_fail",
        "fail": true,
        "duration": 68083
    }
]

內容解密：

JSON格式的輸出包含了每個測試案例的詳細資訊，如檔案位置、套件名稱、測試名稱和執行時間。
"fail": true表示該測試案例失敗。

Rego Playground的使用

Rego Playground是一個用於原型設計和測試Rego策略的網頁工具。它提供了許多有用的功能，如範例策略、Strict模式和Coverage模式。

Coverage模式

Coverage模式可以顯示哪些陳述式被評估過，哪些沒有。如下圖所示：

  graph LR;
    A[輸入訊息] -->|評估|> B{陳述式};
    B -->|被評估|> C[綠色];
    B -->|未被評估|> D[紅色];

圖表翻譯： 此圖示展示了Coverage模式的工作原理，綠色表示被評估的陳述式，紅色表示未被評估的陳述式。

Strict模式

Strict模式可以確保變數與定義相符，避免未定義變數的使用錯誤。

釋出Rego策略

Rego Playground提供了釋出功能，可以將策略以可分享的連結釋出，並支援使用OPA伺服器載入釋出的策略進行測試。

$ opa run -s --set services.play.url=https://play.openpolicyagent.org \
--set bundles.play.resource=bundles/SZPzoM4zRb

內容解密：

這條命令啟動了一個OPA伺服器，並載入了從Rego Playground釋出的策略。
這種方式非常適合原型設計和測試。

與進階主題探討未來，我們可以期待OPA和Rego的不斷進化與改進，包括但不限於效能最佳化、新的語言特性和更豐富的工具鏈支援。開發者應持續關注最新的發展動態，以充分利用這些新功能來提升策略開發的效率和品質。同時，隨著雲原生技術的普及，OPA和Rego在雲安全、合規性和策略管理領域的應用將越來越廣泛。

詳細分析

隨著雲原生技術的不斷發展，企業對於安全、合規性和策略管理的需求日益增長。OPA和Rego作為領先的開源策略引擎和語言，將在以下幾個方面發揮越來越重要的作用：

雲安全：透過定義細粒度的存取控制策略，確保雲資源的安全。
合規性檢查：自動檢查系統組態和行為是否符合相關法規要求。
多雲環境管理：在多雲環境中統一管理和執行策略，降低管理複雜度。

這些發展趨勢預示著OPA和Rego在未來將擁有更加廣闊的應用前景。

技術選型考量

在選擇使用OPA和Rego時，企業應考慮以下因素：

技術堆疊相容性：評估OPA和Rego與現有技術堆疊的相容性。
團隊技術能力：考慮團隊對Rego語言和OPA工具鏈的熟悉程度。
社群支援：利用活躍的開源社群資源，解決實施過程中遇到的問題。

透過仔細評估這些因素，企業可以更好地決定是否採用OPA和Rego來滿足其策略管理需求。

進一步閱讀與參考資源

為了更深入地瞭解OPA和Rego，建議閱讀官方檔案並參與相關社群討論。同時，也可以參考一些優秀的開源專案和實踐案例，以獲得更多的實戰經驗。

附錄

本章節附錄提供了額外的資源和資訊，供讀者進一步學習和參考。包括但不限於相關檔案連結、社群論壇和常見問題解答等。

總字數：9,823字

進階套件主題：提升軟體供應鏈安全性與擴充套件 OPA 功能

在前面的章節中，我們已經探討瞭如何撰寫和測試 Rego，並在 Rego Playground 中進行了測試驅動開發。現在，讓我們轉換方向，快速瞭解如何擴充套件和整合 Open Policy Agent（OPA），以更好地滿足我們的實際需求。

進階套件主題：增強 OPA 套件功能

在本章的前面部分，我們已經介紹了 OPA 套件的基本概念。套件不僅與 OPA 伺服器一起使用，也廣泛應用於 REPL 和其他 OPA 命令中。在本文中，我們將探討 OPA 套件的進階主題。由於軟體供應鏈安全性是一個重要的關注點，我們將從套件簽章開始討論。

套件簽章：確保完整性和來源可信度

OPA 套件可以使用 opa sign 子命令進行簽章，或者在執行 opa build 命令時加入 --signing-key 旗標。對套件進行簽章有助於確保其完整性，並確認其來自可信的來源。當 OPA 透過套件更新資料和政策時，這一點尤為重要。

首先，我們需要建立一個 PEM 格式的金鑰檔案。這裡使用 OpenSSL 工具來產生套件簽章所需的金鑰。以下命令首先建立用於簽署套件的私鑰，然後產生相應的公鑰，並將其分發給 OPA 例項以驗證簽章：

# 使用 openssl 命令建立私鑰和公鑰
$ openssl genrsa -out key.pem 2048
$ openssl rsa -in key.pem -outform PEM -pubout -out key.pem.pub

一旦金鑰建立完成，我們就可以使用以下 opa build 命令來建立並簽署套件：

# 建立並簽署套件
$ opa build -b . --signing-key ../keys/key.pem -o signed-bundle.tar.gz

內容解密：

此命令會建立一個名為 signed-bundle.tar.gz 的套件檔案，並將簽章儲存在套件的 .signatures.json 檔案中。這種方式能夠簡便地建立和簽署套件，同時將簽章儲存在套件 tarball 中。

使用 tar 命令，我們可以檢視套件檔案的內容，並確認 .signatures.json 檔案是否包含在內：

# 檢視套件檔案內容
$ tar tvf signed-bundle.tar.gz
-rw------- 0 0 0 69 Dec 31 1969 /data.json
-rw------- 0 0 0 147 Dec 31 1969 /policy.rego
-rw------- 0 0 0 961 Dec 31 1969 /.signatures.json

.signatures.json 檔案包含了一個 JSON Web Token（JWT），可以被解碼以驗證其內容：

{
  "signatures": [
    "eyJhbGciOiJSUzI1NiJ9 ..."
  ]
}

解碼後的 JWT 包含了套件中檔案的 SHA-256 校驗和，確保了檔案的完整性。

{
  "files": [
    {
      "name": "authz-bearer.rego",
      "hash": "4cedc703d3e851c8c8ae...",
      "algorithm": "SHA-256"
    },
    {
      "name": "employees.json",
      "hash": "0f97573c90635f16dc62...",
      "algorithm": "SHA-256"
    },
    {
      "name": "helloworld.rego",
      "hash": "2b8c01dde0acb3962d8e...",
      "algorithm": "SHA-256"
    }
  ]
}

使用 WebAssembly 擴充套件 OPA

除了基本的安全特性，OPA 的套件還可以用於擴充套件其功能，例如與 WebAssembly（Wasm）結合使用。以下命令展示瞭如何建立一個適用於 Wasm 的 OPA 套件：

# 建立適用於 Wasm 的 OPA 套件
$ opa build -t wasm -e examples/ch2/hello ./bundle/helloworld.rego

使用 opa inspect 命令，可以檢視產生的套件內容，並確認其中包含 policy.wasm 二進位檔案：

$ opa inspect bundle.tar.gz
NAMESPACES:
+-------------------------+-------------------------+
| NAMESPACE | FILE |
+-------------------------+-------------------------+
| data | /data.json |
| data.examples.ch2 | /bundle/helloworld.rego |
| data.examples.ch2.hello | /policy.wasm |
+-------------------------+-------------------------+

圖表翻譯：

此圖表展示了使用 Wasm 建構的 OPA 套件的結構，其中包括了資料檔案、Rego 原始碼以及編譯後的 Wasm 二進位檔案。

與 OPA 的擴充套件與整合

作為一個成熟的開源專案，OPA 提供多種擴充套件和整合方式。你可以透過貢獻程式碼、使用 Golang API 自定義內建函式和外掛程式等方式來擴充套件 OPA。例如，opa-envoy-plugin 就是利用 OPA 的 Golang API 實作的一個專案。

此外，OPA 是 Open Policy Agent GitHub 組織下的核心專案，該組織下還有其他多個相關專案，如 Conftest、Gatekeeper 和 OPA WebAssembly NPM Module 等。

OPA 提供了一系列 API 和 SDK 用於整合，包括用於政策評估的 REST API、Golang API 和 WebAssembly，以及用於管理政策的 Bundle API、Status API 等。這些介面讓你可以根據具體需求選擇合適的方式來與 OPA 整合。

策略即程式碼與存取控制

在第二章中，我們發現開放策略代理（Open Policy Agent, OPA）提供了多種操作模式，以滿足我們不同的需求。我們探討了OPA的策略語言Rego，並學習瞭如何使用它來評估和推理結構化資料。無論您操作的是什麼系統、支援什麼應用程式，或是維護什麼資料，存取控制都是不可或缺的組成部分。存取控制決定了誰或什麼可以對您的系統執行操作、可以執行什麼操作，以及在什麼情況下可以執行這些操作。

特權存取管理

每個適當安全的系統都會控制對許可權的存取，並為使用者提供不同級別的存取許可權。特權存取管理（Privileged Access Management, PAM）是一系列技術和網路安全方法的集合，旨在控制誰可以在受存取控制的系統中執行什麼操作。PAM背後的理念是控制誰可以獲得特權存取、何時可以獲得特權存取以及可以獲得多長時間的特權存取。PAM還包括對存取決策的記錄，以實作可稽核性。

最小許可權原則

最小許可權原則（Principle of Least Privilege, PoLP）是一種眾所周知的PAM標準，用於向經過身份驗證的系統主體（即系統參與者）分配存取許可權。根據PoLP，系統參與者僅獲得其需要的許可權，並且僅在需要與系統互動時才獲得這些許可權。例如，在根據角色的存取控制（Role-Based Access Control, RBAC）模型下，授予系統參與者的許可權是根據該參與者在受保護系統中的角色或身份。這些許可權定義了參與者可以執行的操作。與角色相關聯的憑證僅在有限的時間內有效。根據PoLP，參與者被分配一個角色，該角色與一組有限的許可權相關聯，並且僅在有限的時間內有效。

OPA Bearer Token 身份驗證與授權

在第二章中，我們探討了OPA伺服器。為了保護OPA伺服器，我有時會使用Bearer Token。我發現Bearer Token簡單易用，您不需要對每個請求進行簽名。即使Token是未加密的純文字，只要我在HTTPS或隔離甚至是空氣隔離的開發環境中使用它們，Bearer Token就能夠滿足我的需求。

使用Bearer Token的步驟

在system.authz套件中新增策略，以處理Token呈現者的授權。在伺服器啟動時，將此策略作為bundle的一部分載入。
在伺服器命令中新增--authentication=token旗標。
在伺服器命令中新增--authorization=basic旗標。
在傳入請求中新增Authorization標頭。

以下命令啟動具有Token-based AuthN和基本AuthZ方案的伺服器，我還新增了debug旗標：

# 啟動本地OPA伺服器並啟用AuthN/AuthZ方案
$ opa run -s -l debug --bundle . --authentication=token \
--authorization=basic --addr localhost:8181

內容解密：

此命令啟動了一個OPA伺服器，並啟用了根據Token的身份驗證和基本授權方案。其中：

-s 表示以伺服器模式啟動OPA。
-l debug 設定日誌級別為debug，以便於除錯。
--bundle . 指定了包含策略和資料的bundle目錄。
--authentication=token 啟用了根據Token的身份驗證。
--authorization=basic 啟用了基本授權方案。
--addr localhost:8181 指定了伺服器的監聽位址和埠。

程式碼範例：使用Rego定義授權策略

以下是一個簡單的Rego策略範例，用於定義授權規則：

package system.authz

default allow = false

allow {
    input.identity == "admin"
}

allow {
    input.method == "GET"
    input.path = ["resources"]
    input.identity == "user"
}

內容解密：

此Rego策略定義了兩個授權規則：

如果請求者的身份是"admin"，則允許存取。
如果請求方法是"GET"，請求路徑是"/resources"，並且請求者的身份是"user"，則允許存取。

這個策略展示瞭如何使用Rego來定義根據身份和請求屬性的授權規則。

隨著雲端運算和微服務架構的普及，存取控制和策略管理變得越來越重要。未來的發展方向可能包括：

更強大的策略語言和引擎，以支援更複雜的決策邏輯。
與更多雲端服務和微服務架構的整合，以實作無縫的存取控制。
更先進的安全性和合規性功能，以滿足日益嚴格的監管要求。

透過使用OPA和Rego，我們可以實作更靈活、更動態的存取控制機制，從而提高系統的安全性和可管理性。

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。