隨著雲端原生技術和基礎設施即程式碼的普及,策略即程式碼(PaC)的重要性日益凸顯。PaC 將策略定義和執行過程式碼化,實作了策略的自動化管理和應用。這不僅提升了系統管理效率,也強化了安全性、合規性和最佳實踐的落地。在微服務架構和快速迭代的開發環境中,PaC 有助於降低人為錯誤風險,確保系統在快速變化的同時維持穩定性和可靠性。透過版本控制和自動化測試,PaC 更能提升策略的可追溯性和可驗證性,進而提升整體的 IT 治理水平。

如何聯絡我們與致謝分析

聯絡資訊整理

根據提供的內容,我們整理出了聯絡O’Reilly Media的管道:

  • 地址:1005 Gravenstein Highway North, Sebastopol, CA 95472
  • 電話:
    • 美國或加拿大:800-889-8969
    • 國際或本地:707-827-7019
    • 傳真:707-829-0104
  • 電子郵件:support@oreilly.com
  • 網站:https://www.oreilly.com/about/contact.html

書籍相關資源

  • 官方網頁:https://oreil.ly/policy-as-code
  • 可查詢:勘誤表、範例程式碼及其他補充資訊
  • 其他資源:
    • O’Reilly官網:https://oreilly.com
    • LinkedIn:https://linkedin.com/company/oreilly-media
    • YouTube:https://youtube.com/oreillymedia

致謝內容分析

主要貢獻者

  1. 技術審閱與專業支援
    • Anders Eknert:Open Policy Agent (OPA)與Rego的技術審閱
    • Jesse Loudon:技術審閱與Kubernetes相關支援
    • Rosemary Wang:初期技術審閱與指導
    • Stephan Renatus:OPA社群Slack頻道中的及時幫助

領域特定支援

  1. MagTape與OPA相關
    • Joe Searcy提供MagTape相關協助
    • 章節內容挑戰現狀,展現技術可能性
  2. Kubernetes與Kyverno相關
    • Jim Bugwadia:提供Kubernetes與Kyverno的深入見解
    • Chip Zoller:協同Bugwadia進行技術審閱與修正
  3. Terraform相關支援
    • Michael LaPane協助處理複雜的Terraform主題

軟體供應鏈相關支援

  1. 主要貢獻者
    • Oliver Eikenberry(Liatrio):軟體供應鏈知識分享
    • Robert Kelly(Liatrio):相關領域經驗提供
    • Dan Lorenc:公鑰基礎設施與簽名認證協助
    • Cassie Crossley:提供軟體供應鏈安全相關支援

其他重要協助

  1. 工具與技術支援
    • Sertaç Özercan:Gatekeeper Slack頻道中的幫助
    • Rita Zhang:Gatekeeper相關協助
    • Kapil Thangavelu:Cloud Custodian相關支援
    • Rich Burroughs:jsPolicy相關幫助
    • Christopher Phillips:SBOMs與Anchore工具協助

寫作過程反思

  1. 挑戰與犧牲

    • 作者在寫作過程中面臨健康與工作相關的問題
    • 家人給予支援與理解
    • 學習在安靜環境中工作的技巧
  2. 編輯團隊支援

    • Melissa Potter:內容開發編輯,提供寫作指導與排程協助
    • Liz Faerm:生產編輯,協助內容結構最佳化
    • Simina Calin:高階收購編輯,協助建立書籍策略與大綱
內容解密:

這段致謝內容詳細記錄了作者在寫作過程中獲得的各種幫助和支援。主要分為聯絡資訊、書籍相關資源、技術支援和編輯團隊協助四個主要部分。透過這些資訊,可以看出作者在寫作過程中廣泛徵求專業意見,並與相關領域的專家進行深入交流。這些合作不僅提升了書籍的專業水準,也體現了技術社群的協作精神。

未來改進方向分析

1. 技術社群協作模式

進一步研究和推廣這種開放的技術協作模式,讓更多作者和專業人士能夠參與到技術檔案的撰寫和審閱過程中。

2. 書籍資源擴充套件

考慮在官方網頁上提供更多補充資源,如教學影片或實作範例,幫助讀者更深入地理解書籍內容。

3. 編輯流程最佳化

持續改進編輯團隊的工作流程,確保在保持內容品質的同時,提高編輯效率和出版時效。

策略即程式碼:溫和的簡介

在過去60多年中,據估計已經寫了超過2.7萬億行程式碼。你寫過多少行程式碼?我不知道自己寫過多少行,但我寫程式碼已經快30年了。只是在過去八年中,我使用策略即程式碼(Policy as Code, PaC)來更好地控制變更,引導我完成複雜的系統和解決方案,並確保我寫的程式碼是我想要寫的、執行的和分發的內容。

無論是系統還是工件,PaC已經成為我們減少系統和解決方案中不想要和非決定性變更和行為的標準。PaC允許我們將制定的編成程式碼,遵循和實施。PaC的實用性繼承自程式碼標準和最佳實踐,以及實施它們的控制措施。

PaC如今出現在並改進了許多系統和解決方案,從雲端運算和Kubernetes到授權(AuthZ)、持續整合/持續交付(CI/CD)、DevOps、DevSecOps、GitOps和軟體供應鏈安全。在本文中,我將更仔細地檢視PaC,並提出想法、模式和範例,說明如何使用PaC來為您的解決方案啟用策略。目前,在本章中,我將介紹PaC的概念、PaC如何從您的標準中追蹤,以及PaC的特性,這些特性可用於幫助您選擇適合您需求的解決方案。在本章結束時,您將擁有一個流程和檢查清單,您可以在本文的其餘部分中使用它們來評估其他PaC解決方案是否適合您的需求。

什麼是策略?

你每天都遵循策略。策略幫助你在你所處的情況下做出決定。通常,這些策略是根據檔案化的規則和。作為組織的成員,你同意這些規則和。策略對你來說並不陌生。簡單來說,策略是一個計畫好的規則和系統,它引導使用者和自動化在有目的界限內執行。策略設定了既能啟發又能限制的護欄。

策略的目標

我認為,透過策略,我們試圖實作預期的結果或成果。在工作中,讓你遵循公司策略是管理階層實作預期結果或成果的一種方式,比如確保你正確地記錄和報告你的休假時間。

法規策略的影響

法規策略已經成為服務企業的IT系統的一個推動力。根據經濟合作與發展組織(OECD)的說法,“法規策略是透過使用法規、法律和其他工具來實作政府的目標,從而提供更好的經濟和社會成果,並因此改善公民和企業的生活。”

資料保護法規

通用資料保護法規(GDPR)是歐盟(EU)中最為人熟知的資料隱私法規策略之一。因此,GDPR應該被視為一個推動力,以及一般的法規策略。

IT策略的定義

由於本文中的策略將專注於資訊技術(IT)系統,我們需要一個更專注於IT的策略定義。根據Torin Sandall在2017年的Medium文章“What Is Policy? Part One: Enforcement”中的說法,“在軟體系統的背景下,策略是控制系統行為的規則。”

我認為,策略也控制了在這些系統中的角色行為。策略定義了規則,這些規則指定了系統的行為方式,以及它們如何被組態、使用和保護。

本文的主題

本文的一個主要主題是使用策略和策略工具來防止不想要的變更,並在我們的系統和工件中強制實施最佳實踐。我們採用一個更能涵蓋我們需求範圍的策略定義是合理的。

什麼是策略即程式碼?

正如前言中提到的,PaC是使用程式碼工件(策略)來管理和應用規則和條件。策略引擎是解釋策略工件以應用策略決策的程式,使用上述規則和條件。

策略引擎的作用

在策略工件中定義的規則和條件幫助我們實施組織標準和策略。這些實施——稱為控制措施——應用了安全、合規、治理和最佳實踐決策,這些決策旨在防止和對付我們所支援和使用的系統中的不想要的變更。

PaC的基本原理

在執行過程中,為了做出決策,PaC回答問題——關於需要控制的系統、工件、場景和情況的問題。回答的問題越多,實施的控制措施就越多。實施的控制措施越多,行為就越具有決定性,不想要的行為和意外就越少。

策略的結構

我們可以透過將策略分解為對我們有用的部分來輕鬆地建立策略模型。在高層次上,我們的策略模型由以下部分組成:

策略名稱

用於標記策略以供將來參考

策略目的

該策略存在的原因以及它試圖強制執行或解決的問題

策略情況

將使用該策略的背景(包括系統和環境)

策略規則

個別的控制措施或規定的行為;策略可以有多個規則

策略動作

如果違反策略規則,則採取的動作(不總是策略引擎的一部分)

策略的特性

接下來,我們將更仔細地檢視使策略如此有用的特性和它們使用的策略語言。

  graph LR
    A[策略名稱] --> B[策略目的]
    A --> C[策略情況]
    A --> D[策略規則]
    A --> E[策略動作]
    B --> F[策略引擎]
    C --> F
    D --> F
    E --> F
    F --> G[控制措施]
    G --> H[安全]
    G --> I[合規]
    G --> J[治理]
    G --> K[最佳實踐]

圖表翻譯: 此圖表展示了策略模型的組成部分及其之間的關係。策略名稱、目的、情況、規則和動作共同構成了策略模型。策略引擎使用這些部分來實施控制措施,進而實作安全、合規、治理和最佳實踐。

內容解密:

這個Mermaid圖表呈現了策略模型的關鍵元件。從策略名稱出發,連線到策略目的、情況、規則和動作,這些都是構成一個完整策略的必要部分。策略引擎利用這些資訊來做出決策並實施控制措施。控制措施進一步與安全、合規、治理和最佳實踐相關聯,顯示了策略在實際應用中的多導向作用。

策略語言

策略語言是用來編寫策略的語言。不同的策略引擎可能支援不同的策略語言。選擇合適的策略語言對於實作有效的策略至關重要。

# 示例策略語言:Rego
# 這是一個簡單的Rego策略範例,用於檢查輸入資料是否符合特定條件
package example

default allow = false

allow {
    input.name == "allowed_user"
}

內容解密:

這個Rego策略範例展示瞭如何定義一個簡單的允許規則。只有當輸入資料中的name欄位等於"allowed_user"時,allow才會被設定為true。這是策略語言的一個基本應用,用於控制存取或資料處理流程。

未來方向

隨著技術的不斷發展,PaC將在未來的系統管理和安全領域發揮越來越重要的作用。預計將會有更多的工具和平台支援PaC,使得策略的管理和實施更加高效和自動化。

參考資料

  • 經濟合作與發展組織(OECD)關於法規策略的報告
  • Torin Sandall的Medium文章:“What Is Policy? Part One: Enforcement”
  • Rego策略語言官方檔案

檢查清單

  • 確定您的組織需求和目標
  • 選擇合適的PaC工具和平台
  • 定義和實施策略
  • 持續監控和評估策略的有效性

透過遵循本文的指導,您將能夠有效地使用PaC來改進您的系統和解決方案。請繼續閱讀下一章,以深入瞭解PaC的實際應用。

策略即程式碼(Policy as Code)的基本特性與應用

策略特性

在策略即程式碼(PaC)的背景下,策略具有多項重要的特性,使其在IT系統中極具實用價值。首先,PaC中的策略是以程式碼形式撰寫、儲存、管理及解讀,這使得它們能夠與應用程式交付過程中使用的自動化工具和流程無縫整合,進而簡化管理和佈署流程。

另一個重要的方面是,無論底層實作方式如何,PaC策略在語法上具備一定的熟悉度。例如,某些PaC解決方案可能根據JavaScript語言,這對於具備深厚JavaScript背景的組織來說非常有利。策略語言或其組態包裝器的熟悉程度,直接影響到解決方案的直觀性和易用性。然而,這種熟悉度是主觀的,並取決於個人知識和經驗。不同的組織可能會根據自身需求,選擇宣告式、命令式或斷言式的策略語言。

JSON和YAML在PaC中的關鍵角色

JSON和YAML是現代IT系統中廣泛使用的兩種宣告式資料格式,尤其是在雲端運算和Kubernetes環境中,它們被用來定義和宣告組態。PaC工具大量採用這兩種資料格式來交付策略、處理輸入和提供輸出,這並非巧合。JSON和YAML格式具備宣告式、表達力強且具備自我描述的特性,即使底層策略語言不是根據這兩種格式,策略評估的物件通常也是JSON或YAML格式的資料。結構化資料更易於處理,這是PaC廣泛採用JSON和YAML的主要原因。

JSON與YAML的優勢

  • 宣告式與結構化:JSON和YAML具備宣告式和結構化的特點,這使得它們非常適合用於PaC的策略評估。
  • 轉換靈活性:JSON和YAML可以輕鬆地相互轉換,這為資料處理提供了極大的便利。
  • 擴充套件性:非結構化或較少結構化的資料可以被解析並轉換為JSON或YAML,以進一步處理。

守護軌道(Guardrails):防止不當變更

在過去的工作中,許多組織利用PaC來為雲端運算操作設定邊界,這些邊界就像高速公路上的護欄(guardrails)。當操作在護欄範圍內進行時,不會受到限制;但是一旦操作偏離了預定的路徑,違反了策略設定的規則和條件,相關操作就會被控制措施所限制。這些控制措施是由策略來執行和實施的。

護欄的工作原理

  • 允許自由操作:在護欄範圍內,操作可以自由進行,不會受到限制。
  • 防止不當變更:護欄能夠防止不當變更,例如在雲端運算中防止與公用IP相關的運算例項被建立。
  • 學習與改進:隨著時間的推移,護欄機制能夠引導使用者遵循正確的操作流程,從而減少限制並提高操作效率。

計劃(Plans):應對非預期事件

使用者不斷對系統和工件進行變更,幾乎無法預測他們接下來會做什麼。策略和PaC引擎結合,可以構建縱深防禦(Defense-in-Depth, DiD)策略,無論變更的來源是什麼,都能增加一層對策。

Kubernetes中的策略應用

在維護Kubernetes叢集時,即使是內部使用者,也可能無法完全控制他們佈署的程式碼或容器映像。因此,需要透過PaC引擎來實施相關策略,以防止容器破壞叢集的完整性。以下是一些可以實施的基準策略範例:

  • 安全設定:規範容器的安全設定,防止潛在的安全風險。
  • 網路設定:控制容器的網路連線,防止未經授權的存取。
  • 映像來源控制:限制容器映像的來源,確保只使用受信任的映像。

策略模型範例:禁止公用IP

考慮一個禁止建立具有公用IP的運算例項的策略模型,如圖1-1所示。

  graph LR
    A[開始建立運算例項] --> B{是否包含公用IP?}
    B -->|是| C[阻止並終止運算例項]
    B -->|否| D[允許建立運算例項]
    C --> E[通知管理員]
    D --> F[完成建立]

圖表翻譯: 此圖表展示了一個簡單的策略模型,用於控制運算例項的建立。當使用者嘗試建立運算例項時,系統會檢查該例項是否包含公用IP。如果包含,系統將阻止並終止該例項;如果不包含,則允許建立。該流程確保了系統資源的安全性和合規性。

策略活動圖

圖1-2所示,活動圖詳細展示了在禁止公用IP策略下,系統如何處理運算例項的建立請求。

  graph TD
    A[使用者請求建立運算例項] --> B{檢查運算例項組態}
    B -->|包含公用IP| C[阻止建立並通知]
    B -->|不包含公用IP| D[允許建立並完成組態]
    C --> E[記錄日誌並通知管理員]
    D --> F[完成建立流程]

圖表翻譯: 此圖表展示了在禁止公用IP策略約束下的運算例項建立流程。當使用者請求建立運算例項時,系統會檢查該例項的組態。如果組態中包含公用IP,系統將阻止建立並通知相關人員;如果不包含公用IP,則允許建立並完成組態流程。該流程透過自動化檢查和通知機制,確保了系統的安全管理。

策略即程式碼

隨著技術的不斷進步,PaC將繼續演進並在更多領域發揮作用。未來,我們可以預見以下幾個發展趨勢:

  • 更廣泛的工具整合:PaC將與更多IT工具和平台整合,提供更全面的管理能力。
  • 更強大的策略引擎:策略引擎將變得更為強大和靈活,能夠處理更複雜的策略邏輯。
  • 更高的自動化程度:透過與自動化工具的深度整合,PaC將進一步簡化IT操作,提高效率並減少人為錯誤。

未來策略發展方向

  1. 智慧化策略:未來策略可能會具備更強的智慧化特性,能夠根據環境變化自動調整。
  2. 動態策略:策略將變得更加動態,能夠根據實時資料和事件進行動態調整。
  3. 跨領域策略整合:不同領域的策略將進一步整合,形成更全面的IT管理框架。

策略實施的最佳實踐

在實施PaC時,以下是一些最佳實踐建議:

  • 逐步實施:從簡單的策略開始,逐步擴充套件到更複雜的場景。
  • 持續監控:對策略的執行情況進行持續監控,及時調整和最佳化。
  • 培訓與檔案:提供充分的培訓和檔案,確保團隊成員能夠正確理解和實施PaC。

程式碼範例:策略實施

以下是一個簡單的策略實施範例,使用JSON格式定義了一個禁止公用IP的策略:

{
  "policy": {
    "name": "ProhibitPublicIP",
    "description": "禁止建立具有公用IP的運算例項",
    "rules": [
      {
        "condition": "contains(publicIP)",
        "action": "deny"
      }
    ]
  }
}

內容解密:

此JSON範例定義了一個名為ProhibitPublicIP的策略,用於禁止建立具有公用IP的運算例項。策略中包含一個規則,當運算例項組態中包含公用IP時,系統將拒絕建立該例項。此範例展示瞭如何使用結構化資料格式來定義和實施策略。