Styra DAS 與 MagTape OPA 集中式管理

– 8 分鐘閱讀

在 Kubernetes 環境中，Open Policy Agent (OPA) 已成為策略即程式碼 (Policy-as-Code) 的主流方案。然而，管理大量的 OPA 策略和日誌需要更進階的工具。本文將介紹 Styra DAS 和 MagTape 兩種 OPA 集中式管理方案，分析其特性及應用場景，並提供實務操作範例。Styra DAS 提供完整的策略生命週期管理、合規包和集中式日誌記錄，適合企業級佈署。MagTape 則以裝飾器模式擴充套件 OPA 功能，整合 Slack 通知機制，適合注重通知與自動化合規檢查的場景。兩種方案各有優勢，可根據實際需求選擇。

使用 Styra DAS 進行集中式 OPA 管理

安裝 Styra 系統代理

在 Kubernetes 環境中安裝 Styra OPA 資源是使用 Styra DAS（Declarative Authorization Service）進行集中式 OPA 管理的第一步。首先，我們需要執行一個自動化安裝指令碼，這個指令碼是根據從 Styra DAS 工作區獲得的安裝命令構建的。

# Styra 自動安裝指令碼
$ ./up-styra.sh
clusterrolebinding.rbac.authorization.k8s.io/kubelet-api-admin created
namespace/kube-system labeled
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 20408 0 20408 0 0 24350 0 --:--:-- --:--:-- --:--:-- 24440
namespace/styra-system created
secret/opa-server created
configmap/opa-config created
secret/das-slp-token created
clusterrolebinding.rbac.authorization.k8s.io/opa-viewer created
service/opa created
statefulset.apps/opa created
secret/styra-access created
configmap/datasources-agent-config created
clusterrole.rbac.authorization.k8s.io/read-all-global created
clusterrolebinding.rbac.authorization.k8s.io/datasources-agent-read-all created
deployment.apps/datasources-agent created
validatingwebhookconfiguration.admissionregistration.k8s.io/opa-validating-webhook created
mutatingwebhookconfiguration.admissionregistration.k8s.io/opa-mutating-webhook created

內容解密：

  1. ./up-styra.sh：這是一個自定義的安裝指令碼，用於自動化安裝 Styra OPA 資源。
  2. clusterrolebinding.rbac.authorization.k8s.io/kubelet-api-admin created：建立了一個 ClusterRoleBinding，用於授權 kubelet API 的管理許可權。
  3. namespace/styra-system created：建立了一個名為 styra-system 的名稱空間，用於隔離 Styra 相關資源。
  4. 各種資源（如 Secret、ConfigMap、Service、StatefulSet 等）的建立，確保了 OPA 和相關元件的正常執行。
  5. validatingwebhookconfiguration 和 mutatingwebhookconfiguration 的建立，用於組態 Kubernetes 的准入控制器，以實作策略執行。

安裝完成後，可以透過以下命令檢查 Styra 系統名稱空間中的 Pod 狀態：

# 取得 OPA Pods 狀態
$ kubectl -n styra-system get pod
NAME READY STATUS RESTARTS AGE
datasources-agent-7c556dfdf6-49p6w 1/1 Running 0 5m33s
opa-0 2/2 Running 0 5m33s
opa-1 2/2 Running 0 5m17s
opa-2 2/2 Running 0 5m

內容解密：

  1. kubectl -n styra-system get pod：查詢 styra-system 名稱空間中的 Pod 狀態。
  2. datasources-agent-7c556dfdf6-49p6w 和 opa-0、opa-1、opa-2：這些是執行中的 OPA 和資料源代理 Pod，表明 Styra DAS 已成功佈署。

策略管理

成功安裝並執行 OPA 代理後，我們可以開始建立和管理策略。Styra DAS 提供了一個集中式的平台，用於編寫、儲存和佈署策略。

編輯和發布策略

在 Styra DAS 工作區中，我們可以建立和發布策略規則，如下圖所示：

  graph LR;
    A[建立策略] --> B[發布策略];
    B --> C[OPA 代理下載策略包];
    C --> D[執行策略];

圖表翻譯： 此圖展示了在 Styra DAS 中建立和發布策略的流程。首先，在 Styra DAS 工作區建立策略，然後發布。OPA 代理會下載這些策略並在本地執行。

Styra DAS 提供了一個規則 IDE，用於驗證規則語法並預覽執行結果，類別似於 Rego Playground。

合規包（Compliance Packs）

Styra DAS 提供了一系列預定義的合規包（Compliance Packs），這些合規包包含了特定安全、治理和合規領域的最佳實踐策略。例如：

  • Kubernetes 最佳實踐（免費版本可用）
  • CIS Benchmarks（免費版本可用）
  • MITRE ATT&CK
  • PCI DSS v3.2
  • Pod Security Policies（免費版本可用）

這些合規包簡化了策略的建立和管理過程，讓使用者能夠快速應用業界最佳實踐。

策略測試

發布策略後，OPA 代理會下載並應用這些策略。我們可以透過嘗試建立一個測試 Pod 來驗證策略是否生效：

# 測試 deny-all 策略
$ kubectl -n test apply -f 1-test-pod.yaml
Error from server: error when creating "mutating/test/1-test-pod.yaml":
admission webhook "validating-webhook.openpolicyagent.org" denied the request: Enforced: Request object: "{\"apiVersion\": \"v1\", \"kind\": \"Pod\"...

內容解密：

  1. kubectl -n test apply -f 1-test-pod.yaml：嘗試在 test 名稱空間中建立一個 Pod。
  2. Error from server：由於 deny-all 策略的限制，建立 Pod 的請求被拒絕。
  3. admission webhook "validating-webhook.openpolicyagent.org" denied the request：表明准入 Webhook（由 OPA 組態）拒絕了該請求，因為它違反了已執行的策略。

集中式日誌記錄

Styra DAS 提供集中式日誌記錄功能，用於記錄 OPA 的決策日誌。這使得管理和稽核變得更加容易。

  graph LR;
    A[OPA 代理] -->|決策日誌|> B[Styra DAS];
    B --> C[集中式日誌記錄];

圖表翻譯： 此圖展示了 OPA 代理如何將決策日誌上傳到 Styra DAS，實作集中式日誌記錄。

解除安裝 Styra DAS

當需要解除安裝 Styra DAS 時，可以使用以下自動化指令碼：

# 解除安裝 Styra DAS
$ ./down-styra.sh
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 20412 0 20412 0 0 23633 0 --:--:-- --:--:-- --:--:-- 23762
namespace "styra-system" deleted
secret "opa-server" deleted
configmap "opa-config" deleted
secret "das-slp-token" deleted
clusterrolebinding.rbac.authorization.k8s.io "opa-viewer" deleted
service "opa" deleted
statefulset.apps "opa" deleted
secret "styra-access" deleted
configmap "datasources-agent-config" deleted
clusterrole.rbac.authorization.k8s.io "read-all-global" deleted
clusterrolebinding.rbac.authorization.k8s.io "datasources-agent-read-all" deleted
deployment.apps "datasources-agent" deleted
validatingwebhookconfiguration.admissionregistration.k8s.io "opa-validating-webhook" deleted
mutatingwebhookconfiguration.admissionregistration.k8s.io "opa-mutating-webhook" deleted
No resources found
namespace/kube-system unlabeled

內容解密：

  1. ./down-styra.sh：這是一個自定義的解除安裝指令碼，用於刪除由 Styra DAS 安裝的資源。
  2. 各種資源（如 Namespace、Secret、ConfigMap、Service 等）的刪除，確保了 Styra DAS 相關資源被徹底清除。
  3. validatingwebhookconfiguration 和 mutatingwebhookconfiguration 的刪除，移除了與 OPA 相關的准入控制器組態。

解除安裝後，可以在 Styra DAS 工作區中觀察到與本地 OPA 代理斷開連線的錯誤，如下圖所示：

  graph LR;
    A[Styra DAS 工作區] -->|斷開連線|> B[本地 OPA 代理];

圖表翻譯： 此圖表示解除安裝 Styra DAS 後，Styra DAS 工作區與本地 OPA 代理之間的連線斷開。

MagTape與Kubernetes的整合應用

前言

本章將探討MagTape，一個由T-Mobile開源的Policy-as-Code（PaC）專案，該專案根據Open Policy Agent（OPA）和Rego語言構建。MagTape透過擴充套件OPA的功能，為Kubernetes環境提供了額外的業務流程和通知機制，特別是在與Slack整合方面表現出色。

MagTape的設計理念與架構

MagTape採用裝飾器設計模式（Decorator design pattern），在不改變OPA核心實作的前提下，為其新增額外的功能。這種設計使得MagTape能夠在Kubernetes API伺服器和OPA服務之間充當代理角色，透過init容器組態實作與OPA服務的整合。

關鍵架構特點：

  1. 裝飾器模式應用：MagTape在保留OPA核心功能的基礎上，增加了業務工作流程和通知層，特別是透過webhook與Slack整合。
  2. 間接層組態：使用init容器實作與OPA服務的整合，增強了系統的可擴充套件性和靈活性。
  3. 擴充套件性設計：透過額外的功能層，MagTape能夠更好地滿足企業級需求，特別是在合規性和通知機制方面。

MagTape的安裝與組態

根據專案的開發情況，MagTape的主要貢獻發生在2020年，隨後在2021和2022年有一些持續的更新。儘管目前該專案的活躍度不高，且使用的OPA和kube-mgmt版本相對較舊，但它仍然為我們提供了一些有趣的思路和在Kubernetes中使用OPA的最佳實踐。

安裝步驟解析：

  1. 環境準備：首先需要準備Kubernetes叢集，並確保相關依賴服務可用。
  2. MagTape佈署：透過官方提供的安裝指令碼或Helm chart進行佈署。
  3. 組態細節：重點組態與OPA的整合引數，以及通知系統（如Slack webhook）的連線資訊。
# 示例：MagTape的基本組態檔案
apiVersion: v1
kind: ConfigMap
metadata:
  name: magtape-config
data:
  OPA_URL: "http://opa-service:8181"
  SLACK_WEBHOOK: "https://hooks.slack.com/services/XXXXXXX"

內容解密：

上述組態範例展示了MagTape的基本設定檔結構。其中：

  • OPA_URL指定了OPA服務的存取位址，用於MagTape與OPA之間的通訊。
  • SLACK_WEBHOOK則是設定與Slack通知系統的整合，用於將策略執行結果傳送到指定的Slack頻道。

MagTape的核心功能與優勢

  1. 業務工作流程增強：透過擴充套件OPA的功能，MagTape能夠支援更複雜的業務邏輯和工作流程。
  2. 通知機制：特別是與Slack的整合，使得策略執行結果能夠即時通知相關人員，提高了問題回應的速度。
  3. 合規性管理：透過自訂的策略和通知機制，MagTape有助於企業更好地管理Kubernetes環境中的合規性問題。

實際應用場景分析

在企業級Kubernetes環境中，MagTape可以被用來實作以下場景：

  • 自動化合規檢查：透過定義相關策略，自動檢查Kubernetes資源是否符合企業內部規範。
  • 即時通知與回應：當檢測到不符合規範的資源時，透過Slack等通知系統即時告知相關人員。
  • 持續改進與最佳化：透過對策略執行結果的持續監控和分析，不斷最佳化和改進企業的合規性管理流程。

儘管MagTape專案目前的活躍度不高，但其設計理念和實作方式仍然具有參考價值。未來可以期待在以下方面進行改進和擴充套件：

  • 支援最新版本的OPA和kube-mgmt，以獲得更好的效能和安全性。
  • 擴充套件通知系統，支援更多的第三方服務，如Email、Teams等。
  • 增強策略管理功能，提供更友好的策略編寫和管理介面。

補充內容：Mermaid圖表示例

以下是一個簡單的Mermaid圖表，用於展示MagTape的工作流程：

  graph LR
    A[Kubernetes API Server] -->|請求|> B[MagTape]
    B -->|轉發請求|> C[OPA Service]
    C -->|傳回結果|> B
    B -->|通知|> D[Slack]
    B -->|傳回結果|> A

圖表翻譯：

此圖示展示了MagTape在Kubernetes環境中的工作流程：

  1. Kubernetes API Server接收到請求後，將請求轉發給MagTape。
  2. MagTape將請求進一步轉發給OPA Service進行策略評估。
  3. OPA Service將評估結果傳回給MagTape。
  4. MagTape根據評估結果，透過Slack進行通知。
  5. 最終，MagTape將處理結果傳回給Kubernetes API Server。

透過這個圖表，我們可以清晰地看到MagTape如何在Kubernetes API Server和OPA Service之間充當代理角色，並實作額外的通知功能。

玄貓

玄貓

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