政策程式碼成功關鍵因素

– 14 分鐘閱讀

政策即程式碼（PaC）在現代軟體開發和維運中扮演著越來越重要的角色，尤其在 Kubernetes 環境下。各種 PaC 解決方案，例如 Open Policy Agent (OPA)、Gatekeeper、Kyverno 和 Cloud Custodian (c7n)，都提供了不同的策略管理方法。這些方案的成功與否，很大程度上取決於其領域特定語言（DSL）的設計和整體的可用性。一個易於理解和使用的 DSL 可以降低學習門檻，吸引更多使用者，進而提升專案的動能。此外，良好的可用性設計，例如簡化的操作流程、直觀的使用者介面和豐富的功能，也能提升使用者經驗，促進專案的普及。在競爭激烈的 PaC 領域，各個專案不斷推陳出新，例如透過支援外部資料來源、引入控制器策略等方式來滿足使用者需求。同時，技術重用和生態系統的發展也至關重要，例如 Kyverno 整合了多種映像檔簽名技術，並參與制定了 Policy Report 標準，這些都有助於提升專案的影響力和採用率。

第十五章：回顧

成功匯入政策即程式碼（PaC）的關鍵因素

在開始使用 PaC 的近八年時間裡，我一直在尋找一種方法來解除控制定義與實作之間的緊密耦合。我意識到，僅僅依靠撰寫命令式程式碼來實作所需的雲端控制並不是一個可持續的模式。這促使我在 2016 年採用了 Cloud Custodian，作為我們 AWS 雲端遷移的一部分。

在探索的過程中，我也嘗試過 Chef InSpec 和 Puppet。雖然這兩種工具在其領域內都非常優秀，但它們的方法和語法並不符合我的需求。我並不是在否定這些解決方案，事實上，我曾經使用 Chef 來解決多個案例中的組態漂移問題。只是我認為它們並不是最佳的選擇，特別是在查詢雲端資源、建立偵測性和預防性控制，以實作即時或近即時的反應方面。而 c7n 的宣告式語法對我來說非常有吸引力。

兩年後，當我尋找類別似的解決方案來建立 Kubernetes 控制時，c7n 並不是一個選項。於是我選擇了 OPA，並開始採用 Rego。在學習 Rego 的過程中，我發現自己需要撰寫輔助函式庫來執行常見的任務，例如取得 Pods、容器及其相關的後設資料和設定。接著，我轉向了更宣告式的解決方案，例如 Gatekeeper 和最終的 Kyverno。

綜觀本文所涵蓋的 PaC 解決方案，我認為有幾個趨勢促進了其被廣泛採用。在本章中，我將討論成功匯入 PaC 解決方案的關鍵因素，並展望 PaC 的未來發展。

開放原始碼專案的共同特點

開放原始碼專案（OSS）與商業軟體有一些共同點，其中之一就是競爭性。支援相同或類別似使用案例的 OSS 必須競爭市場佔有率，而這種競爭是由採用率驅動的。OSS 的採用率在很大程度上取決於社群需求和解決方案的差異化。想要持續推動採用率和提高市場佔有率的解決方案，無論是 OSS 還是其他型別，都需要透過差異化來建立競爭優勢。

對於商業產品來說，「競爭優勢」通常指的是公司如何比競爭對手更有效率或更低成本地生產商品或提供服務。對於 OSS PaC 解決方案來說，情況也是如此，雖然「更好」是一個相對的概念，但它著重於透過更好的工具和技術，以及支援更多的使用案例來推動採用率和市場佔有率。

專案動能

成功的 PaC 專案必須擴充套件以支援越來越多的使用案例。這種擴充套件需要並促進了專案的動能。例如，我在 OPA 專案啟動近兩年後才發現它。當時我正在尋找一個適用於 Kubernetes 的合規性和治理解決方案。事實上，我認為對 Kubernetes 解決方案的需求以及 OPA 的及時出現對 OPA 專案來說是一個福音。最初的 Kubernetes 解決方案吸引了我，我投入了時間學習 Rego，並進一步瞭解 Kubernetes 的運作，特別是動態准入控制。

OPA 加入 CNCF（雲端原生運算基金會）有助於提升專案的動能。成為 CNCF 的一部分為專案帶來了可見度和合法性，這進一步促進了更多的參與，包括使用者和貢獻者。

在最初的 Kubernetes 解決方案之後，由於 Rego 語言的學習曲線較陡峭，OPA Gatekeeper 專案提供了一個更友好的使用者經驗。Gatekeeper 也引入了職責分離，使用者可以在不需要撰寫 Rego 程式碼的情況下建立約束條件。

Gatekeeper 和 OPA Classic 之間存在著一種共生關係。Gatekeeper 受益於 OPA 專案的動能及其在 CNCF 中的地位。隨著 Gatekeeper 的成熟，它反過來又將 Rego 語言和專案推廣給更多的使用者。這種動能增加了使用者數量、貢獻者數量以及已解決的使用案例。

特定領域語言（DSLs）

作為一名開發者，我從未迴避撰寫程式碼。我喜歡開發和編寫程式碼，無論我的工作狀態如何。雖然隨著我承擔越來越多的責任，我獲得的開發和編寫程式碼的機會越來越少，但撰寫這本文對我來說是一個巨大的機會，讓我可以重新戴上開發者的帽子。然而，在開發可用且可擴充套件的解決方案時，我學會了將我的熱情與可用性和使用者經驗相結合。在這個過程中，我經常轉向更宣告式的解決方案，特別是在 PaC 使用案例中。程式碼可以很優雅，但通常它對開發者來說比對使用者更優雅。外部功能、效能和適用性往往比內部優雅更重要。畢竟，只要滿足功能性和非功能性需求，誰會在乎你是使用單體架構還是微服務架構來開發你的解決方案呢？

當我想到宣告式解決方案時，首先想到的就是特定領域語言（DSLs）。根據 Martin Fowler 的說法，DSL 是一種「針對特定問題領域的電腦語言」。雖然我並不是 DSL 的忠實粉絲，但它們確實提高了我對各種解決方案（包括 PaC）的理解和採用程度。本文中介紹的幾個解決方案使用了 DSLs，為使用者提供了特定領域的詞彙和語法，從而簡化了整體採用過程。例如，我在本文中的大多數自動化解決方案都是使用 make 和 Makefiles 實作的。Makefiles 中的語法正是來自於 DSL 方法。結構化查詢語言（SQL）是另一個著名的 DSL。

其他 DSL 方法使用函式和方法串聯，如下所示，這是我在 2021 年的一篇部落格文章中使用 AWS CDK 與 Java 時寫的一個程式碼範例：

// Java fluent interface example
Bucket.Builder.create(this, "MyFirstBucket")
    .versioned(true)
    .bucketName("cdk-unique-bucket-name")
    .encryption(BucketEncryption.S3_MANAGED)
    .blockPublicAccess(BlockPublicAccess.BLOCK_ALL)
    .removalPolicy(RemovalPolicy.DESTROY)
    .build();

這種級聯式的點符號使得物件建立和組態更加容易，具有流暢的介面。這與 Java 中常用的傳統建構子和 getter/setter 方法形成鮮明對比。

DSLs 通常被分為內部 DSL 和外部 DSL。內部 DSL 使用主機通用語言作為基礎。前述的流暢介面範例就是一個內部 DSL 的例子。

成功匯入 PaC 的關鍵因素

  • 競爭優勢：透過差異化建立競爭優勢，以推動採用率和市場佔有率。
  • 專案動能：成功的 PaC 專案需要擴充套件以支援更多的使用案例，並促進專案動能。
  • 特定領域語言（DSLs）：使用 DSLs 可以簡化整體採用過程，提高用性和使用者經驗。

這些因素共同促進了 PaC 解決方案的成功匯入和廣泛採用。在未來，我們可以期待看到更多創新性的 PaC 解決方案，以及它們在各個領域中的應用。

PaC 的發展將繼續受到技術進步和市場需求的推動。我們可以預期看到更多根據宣告式語法的解決方案，以及更多利用 DSLs 的創新應用。此外，隨著雲端原生技術的不斷發展，PaC 解決方案將更加緊密地與 Kubernetes 和其他雲端原生平台整合，提供更強大的合規性和治理能力。

總之，成功匯入 PaC 需要結合技術創新、社群參與和市場需求。透過瞭解這些關鍵因素，我們可以更好地把握 PaC 的未來發展趨勢，並充分利用其潛力來推動業務成功。

PaC 成功匯入因素
  graph LR
    A[競爭優勢] --> B[專案動能]
    B --> C[特定領域語言]
    C --> D[成功匯入 PaC]

圖表翻譯： 此圖示呈現了成功匯入 PaC 的關鍵因素之間的關係。首先，建立競爭優勢是基礎，這有助於推動專案動能。而特定領域語言的使用進一步促進了整體採用過程，最終實作了 PaC 的成功匯入。

詳細內容

為了進一步闡述上述內容，以下是一些具體例項和詳細說明：

  1. Cloud Custodian：作為一個成功的 PaC 工具，Cloud Custodian 提供了一種宣告式的方法來管理和控制雲端資源。它允許使用者定義策略，以確保雲端資源符合特定的合規性和安全要求。

  2. OPA 和 Rego：OPA 提供了一種靈活且可擴充套件的方式來實施策略，特別是在 Kubernetes 環境中。Rego 語言使得使用者可以定義複雜的策略，並將其應用於各種資源。

  3. Gatekeeper：作為 OPA 的一個擴充套件，Gatekeeper 提供了一個更友好的使用者介面，並簡化了策略的管理。它允許使用者以宣告式的方式定義和管理約束條件，從而提高了整體的可管理性。

  4. Kyverno：Kyverno 是另一個根據宣告式的策略管理工具，它提供了豐富的功能來簡化 Kubernetes 環境中的策略實施。它支援多種策略型別，並允許使用者根據具體需求進行自定義。

透過這些工具和技術的使用，我們可以看到 PaC 在實際應用中的多樣性和靈活性。它們不僅提高了合規性和安全性，還簡化了管理和操作流程，從而為企業帶來了顯著的效益。

未來研究方向

未來，我們可以進一步研究以下幾個方向：

  1. 增強 PaC 的自動化能力：透過整合更多的自動化工具和技術，提高 PaC 的自動化水平，從而減少人工干預，提高效率。

  2. 擴充套件 PaC 的應用場景：探索 PaC 在更多領域中的應用，如 IoT、邊緣計算等，以滿足不同場景下的需求。

  3. 提高 PaC 的安全性：加強 PaC 的安全機制，防止潛在的安全威脅，確保策略執行的安全性和可靠性。

透過這些研究方向，我們可以進一步推動 PaC 的發展，使其在更多的領域中發揮作用，為企業和組織帶來更大的價值。

程式碼範例：使用 Kyverno 定義策略

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-image-registries
spec:
  validationFailureAction: enforce
  rules:
  - name: validate-registries
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "Unknown image registry"
      pattern:
        spec:
          containers:
          - image: "docker.io/* | quay.io/*"

內容解密：

  1. 此 Kyverno 策略用於限制 Pod 中使用的映像檔來源倉函式庫。
  2. validationFailureAction: enforce 表示如果驗證失敗，將強制拒絕該資源。
  3. match 部分指定了此策略適用於 Pod 資源。
  4. validate 部分定義了驗證規則，要求容器映像檔必須來自 docker.io 或 quay.io 倉函式庫。
  5. 這種宣告式的策略定義方式簡化了安全管理，提高了合規性檢查的效率。

透過這種方式，我們可以看到 Kyverno 如何簡化 Kubernetes 環境中的策略管理，從而提高整體的安全性和合規性。

政策即程式碼（Policy as Code）成功的關鍵因素：DSL 與可用性探討

政策即程式碼（Policy as Code, PaC）已成為現代軟體開發與維運中的重要實踐，特別是在 Kubernetes 環境中，各種 PaC 方案如 Open Policy Agent（OPA）、Gatekeeper、Kyverno 和 c7n 等不斷湧現。本文將探討 PaC 成功的關鍵因素，特別是領域特定語言（Domain-Specific Language, DSL）與可用性（Usability）如何促進專案的動能與採用率。

領域特定語言（DSL）在 PaC 中的角色

在 PaC 領域中，DSL 的選擇對專案的成功至關重要。根據 DSL 的實作方式，可以將其分為內部 DSL（Internal DSL）與外部 DSL（External DSL）。

內部 DSL 與外部 DSL

內部 DSL 是根據現有主機語言（Host Language）建構的，例如使用 Java 作為基礎語言，無需自定義解析器即可直接使用 Java 語法進行策略編寫。相對地，外部 DSL 具有自己的語法和詞彙，並需要自定義的解析器。

以 c7n 和 Kyverno 為例，儘管它們主要使用 YAML 編寫策略，但由於具備各自的解析器，仍被視為外部 DSL。此外，OPA 的 Rego 語言也是一種外部 DSL，因為它並未依賴於某種主機語言，而是獨立發展出自己的語法結構。

DSL 對 PaC 專案動能的影響

DSL 的選擇直接影響 PaC 專案的動能。適當的 DSL 能夠降低使用者的學習門檻，提高專案的吸引力。以 Kyverno 為例，它採用了 YAML 作為主要的策略編寫方式，並結合了 JMESPath 和 YAML Anchors 等語法糖，使得使用者無需學習新的程式語言（如 Rego 或 Go）即可編寫策略。這種設計顯著降低了 Kyverno 的使用門檻，促進了專案的動能。

同樣地，c7n 也採用了類別似的策略，使用者可以直接使用 YAML 編寫策略，無需具備 Python 程式設計能力。這種設計使得 c7n 和 Kyverno 能夠吸引更多非專業開發人員的使用者，從而擴大了專案的影響力。

可用性對 PaC 專案動能的影響

除了 DSL 的選擇之外，可用性也是影響 PaC 專案動能的重要因素。良好的可用性設計能夠提升使用者的體驗，降低使用門檻，從而促進專案的採用率。

Kyverno 如何提升可用性

Kyverno 在其發展過程中不斷最佳化可用性，例如引入了 Auto-Gen 規則，用於自動生成與 Pod 相關的工作負載（如 Deployment、DaemonSet、Job 等）的策略。這一功能顯著減少了使用者在策略管理上的負擔，提升了整體的使用體驗。

此外，Kyverno 還提供了時間限制策略（Time-bound Policies）和清理無用資源的 CleanUp 策略，以及用於驗證映像檔簽名的 VerifyImage 策略。這些功能的加入進一步增強了 Kyverno 的競爭力，使其在眾多 PaC 專案中脫穎而出。

競爭如何推動 PaC 專案創新

在 PaC 領域，各個專案之間的競爭促進了技術創新。例如，Gatekeeper 也開發了驗證映像檔簽名的功能，並支援使用外部資料來源來提供策略決策所需的資料。jsPolicy 則引入了控制器策略，能夠監聽叢集事件並根據策略做出相應的決策和行動。

這種良性競爭推動了各個 PaC 專案不斷創新，不斷滿足使用者需求，從而促進了整個領域的發展。

重用現有技術提升專案採用率

除了 DSL 和可用性之外，重用現有技術也是提升 PaC 專案採用率的重要策略。透過重用成熟的技術和工具，可以減少開發成本，加快專案的推進速度。例如，Kyverno 和 c7n 都利用了 Kubernetes 社群中已有的技術和生態系統，降低了使用者的學習成本，提高了專案的親和力。

隨著雲原生技術的不斷發展，PaC 領域將繼續演進。未來，我們可以期待更多根據 PaC 的創新方案出現，例如結合機器學習技術進行智慧化策略管理，或是進一步簡化 PaC 的編寫和使用流程等。這些創新將進一步推動 PaC 技術的發展和普及，為企業帶來更高的效率和更強的安全保障。

專案擴充性與生態系統發展

促進創新和採用的一個方法是透過技術重用來結合各方努力，這會帶來專案擴充性和生態系統的發展。在多個解決方案中重用和包含技術，可以建立在現有專案和生態系統的基礎上並為其做出貢獻。擴充性鼓勵整合，創造更豐富的生態系統，並推動採用。

可以說，Gatekeeper透過建立在OPA的基礎上實作了這一點。MagTape則透過代理OPA來處理API伺服器請求，同時在OPA和Kubernetes API伺服器之間新增業務邏輯處理，從而以不同的方式實作了這一點。

Kyverno專案不僅幫助長官了Kubernetes Policy Working Group Policy Report標準的制定，還建立了一個UI來審查Policy Reports。Kyverno還與多種映像簽名技術（如Sigstore/Cosign和Notary）進行了整合。最近，它增加了CEL策略表示式和語法。

jsPolicy專案採用JavaScript和可以編譯成JavaScript的語言作為其策略語言。這一差異化幫助它在希望堅持使用JavaScript的使用者中獲得了採用，因為他們已經在該語言上投入了大量的資源和時間。

雖然未包含在本文中，但Kubewarden專案是一個CNCF沙盒專案，其中策略是以WebAssembly（又稱Wasm）二進位制檔案的形式編寫，使用您喜歡的支援Wasm的程式語言。這些Wasm二進位制檔案充當插入程式，被新增到Kubewarden策略伺服器中，以評估Kubernetes資源。

正如我之前提到的，我認為大多數Kubernetes使用者更願意使用粗粒度DSL來定義策略，而不是編寫程式碼。因此，我對Kubewarden的價值主張持謹慎態度。然而，它對Wasm的重用引起了我的興趣。在進一步瞭解後，我發現該專案使用了其他專案中的技術和方法。例如，Kubewarden包含一個Audit Scanner功能，它「不斷檢查叢集中的資源」。這與Gatekeeper的稽核模式以及Kyverno的背景掃描類別似。Kubewarden還包含了我在第4章中介紹的Policy Reports標準，以及第8章中的Kyverno Policy Reporter工具。

在第2章中，我介紹了使用Wasm擴充套件OPA的想法。由於Kubewarden使用Wasm二進位制檔案，它隱含地使用了多種語言——Rust、Go、Rego等——以及可以針對Wasm二進位制檔案的編譯器。這種由技術重用和包含驅動的擴充性，將幫助Kubewarden專案滿足策略開發人員的需求；這應該會帶來動力並促進採用。一般來說，技術重用包括更多的使用者，解決更多的使用案例，從而帶來更多的專案擴充性、採用和動力。

企業解決方案

開源軟體（OSS）專案通常受益於提供根據或包含OSS產品的企業解決方案的商業公司。以下是一些提供使用或根據OSS PaC解決方案的商業產品的公司範例：

Nirmata

Nirmata是Kyverno的創造者和主要維護者，提供由Kyverno驅動的策略和治理解決方案。Nirmata Policy Manager（NPM）是為雲原生平台團隊設計的。它管理跨程式碼倉函式庫和Pipeline、Kubernetes叢集和雲組態的策略執行。它提供集中可觀察性和報告、DevSecOps協作工作流程（如修復和例外管理）以及策略防篡改等功能。

Styra

由OPA的創造者創立，Styra使企業能夠使用PaC在整個雲原生堆積疊中建立和管理現代授權，從應用程式到基礎設施。利用具有OSS（OPA）和商業軟體（Enterprise OPA Platform）的解決方案，Styra賦予IAM工程團隊、開發人員和DevOps團隊減少風險、降低人為錯誤和加速應用程式開發的能力。

Wiz

Wiz幫助組織快速消除其雲環境中最關鍵的風險。它在幾分鐘內連線，無需代理，並自動關聯整個安全堆積疊，以發現最迫切的問題。Wiz策略利用OPA建立統一的框架，跨雲原生堆積疊。無論是組態、合規還是IaC，Wiz使團隊能夠在雲中更快地移動。

Permit.io

Permit.io利用多種混合方法來制定獨特的PaC配方，支援多種策略引擎（例如OPA、AWS Cedar），透過混合策略模型（RBAC、ReBAC、ABAC）。Permit.io還提供了多種介面，您可以使用它們來編寫策略——無程式碼UI、高階API、Terraform（是的！IaC生成PaC）——當然，還可以直接編寫或混合「手動」程式碼。您還可以使用其開源專案OPAL，將策略圖從雲橋接到邊緣的Policy as Code——所有這些都秉持著使開發人員能夠標記授權完成並專注於其核心產品的理念。

玄貓

玄貓

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