設計 Azure 原則即程式碼工作流程

  • 發行項

透過雲端治理進行旅程時，您會想要從使用 Azure 入口網站或各種 SDK 手動管理每個原則指派，轉換為在企業規模更容易管理且可重複使用的程序。 要在雲端大規模管理系統，主要有兩種方法：

  • 基礎結構即程式碼：將定義環境的內容 (包括 Azure Resource Manager 範本 (ARM 範本)、Azure 原則定義和 Azure 藍圖) 視為原始程式碼的做法。
  • DevOps：為我們的使用者持續傳遞價值的人員、程序和產品組合。

Azure 原則即程式碼是這些想法的組合。 基本上，請將原則定義保存在原始檔控制中，並在每次進行變更後測試並驗證該變更。 不過，基礎結構即程式碼或 DevOps 的相關原則並不在此範圍內。

驗證步驟也應該是其他持續整合或持續部署 (CI/CD) 工作流程 (例如部署應用程式環境或虛擬基礎結構) 的一部分。 讓 Azure 原則驗證成為建置和部署程序的初期部分，應用程式和作業小組將得以在嘗試部署於生產環境之前及早探索其變更是否如預期般運作。

定義和基礎資訊

在了解 Azure 原則即程式碼工作流程的詳細資料之前，請務必了解一些基本概念，例如如何撰寫原則定義和計畫定義，以及如何在指派這些定義時利用豁免：

檔案名稱與原則或計畫定義和其他原則資源的特定部分相對應：

File format 檔案內容
policy.json 整個原則定義
policyset.json 整個計畫定義
policy.parameters.json 原則定義的 properties.parameters 部分
policyset.parameters.json 計畫定義的 properties.parameters 部分
policy.rules.json 原則定義的 properties.policyRule 部分
policyset.definitions.json 計畫定義的 properties.policyDefinitions 部分
exemptionName.json 以特定資源或範圍為目標的原則豁免

如需這些檔案格式的範例，請參閱 Azure 原則 GitHub 存放庫

工作流程概觀

Azure 原則即程式碼的一般建議工作流程如下圖所示：

Diagram showing Azure Policy as Code workflow boxes from Create to Test to Deploy.

原始檔控制

可以使用不同的方式 (例如透過 PowerShell、CLI 或 Azure Resource Graph (ARG) 查詢) 將現有的原則和計畫定義匯出。 儲存這些定義的原始檔控制管理環境可以是許多選項之一，包括 GitHub 或 Azure DevOps。

建立及更新原則定義

原則定義會使用 JSON 建立，並儲存在原始檔控制中。 每個原則都有其本身的一組檔案 (例如參數、規則和環境參數)，而這些檔案應儲存在相同的資料夾中。 下列結構是將原則定義保存在原始檔控制中的建議方式。

.
|
|- policies/  ________________________ # Root folder for policy resources
|  |- policy1/  ______________________ # Subfolder for a policy
|     |- policy.json _________________ # Policy definition
|     |- policy.parameters.json ______ # Policy definition of parameters
|     |- policy.rules.json ___________ # Policy rule
|     |- assign.<name1>.json _________ # Assignment 1 for this policy definition
|     |- assign.<name2>.json _________ # Assignment 2 for this policy definition
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
      |- exemptions.<name2>/__________ # Subfolder for exemptions on assignment 2
        | - exemptionName.json________ # Exemption for this particular assignment
|
|  |- policy2/  ______________________ # Subfolder for a policy
|     |- policy.json _________________ # Policy definition
|     |- policy.parameters.json ______ # Policy definition of parameters
|     |- policy.rules.json ___________ # Policy rule
|     |- assign.<name1>.json _________ # Assignment 1 for this policy definition
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
|

新增原則或更新現有的原則時，工作流程應該會自動更新 Azure 中的原則定義。 新的或更新的原則定義會在後續步驟中進行測試。

建立及更新方案定義

計畫定義也會使用應該儲存在與原則定義相同資料夾中的 JSON 檔案來建立。 計畫定義需要已存在的原則定義，因此必須等到原則的來源已在原始檔控制中更新，繼而在 Azure 中更新之後，才能建立或更新。 下列結構是將方案定義保存在原始檔控制中的建議方式：

.
|
|- initiatives/ ______________________ # Root folder for initiatives
|  |- init1/ _________________________ # Subfolder for an initiative
|     |- policyset.json ______________ # Initiative definition
|     |- policyset.definitions.json __ # Initiative list of policies
|     |- policyset.parameters.json ___ # Initiative definition of parameters
|     |- assign.<name1>.json _________ # Assignment 1 for this policy initiative
|     |- assign.<name2>.json _________ # Assignment 2 for this policy initiative
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
      |- exemptions.<name2>/__________ # Subfolder for exemptions on assignment 2
        | - exemptionName.json________ # Exemption for this particular assignment
|
|  |- init2/ _________________________ # Subfolder for an initiative
|     |- policyset.json ______________ # Initiative definition
|     |- policyset.definitions.json __ # Initiative list of policies
|     |- policyset.parameters.json ___ # Initiative definition of parameters
|     |- assign.<name1>.json _________ # Assignment 1 for this policy initiative
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
|

如同原則定義，在新增計畫或更新現有的計畫後，工作流程應該會自動更新 Azure 中的計畫定義。 新的或更新的方案定義會在後續步驟中進行測試。

注意

建議您使用集中式部署機制，例如 GitHub 工作流程或 Azure Pipelines 來部署原則。 這有助於確保只會將經過檢閱的原則資源部署到環境，並使用漸進式和集中式的部署機制。 原則資源的寫入權限可限制於部署中使用的身分識別。

測試及驗證更新的定義

在自動流程已取得您新建立或更新的原則或方案定義，並對 Azure 中的物件進行更新後，就可以測試所做的變更。 原則或其所屬的方案應指派給生產之前最初步的環境所含的資源。 此環境通常為 Dev。

注意

在此步驟中，我們要對 Azure 環境內的原則定義進行整合測試，這與在定義建立期間應該進行的驗證原則定義的功能分開。

指派的 enforcementMode 應使用 [停用]，如此就不會封鎖資源的建立和更新，但仍會對現有的資源進行審核以符合更新的原則定義。 即便使用 enforcementMode，仍建議將指派範圍設為專門用來驗證原則的資源群組或訂用帳戶。

注意

雖然強制模式很有幫助，但仍應在各種情況下徹底測試原則定義。 原則定義應使用 PUT 和 PATCH REST API 呼叫、符合規範和不符合規範的資源以及邊緣案例 (例如資源中遺漏的屬性) 進行測試。

部署指派之後，請使用 Azure 原則 SDK、Azure Pipelines 安全性與合規性評量工作或 AAzure Resource Graph (ARG) 查詢 (請參閱範例) 為新的指派取得合規性資料。 用來測試原則和指派的環境應同時具備合規性狀態不同的資源。 如同適當的程式碼單元測試，您應測試資源是否符合預期，且沒有誤判為真或誤判為否的情況。 如果您只針對預期的部分進行測試和驗證，原則可能會有非預期和未辨識的影響。 如需詳細資訊，請參閱評估新 Azure 原則定義的影響。

啟用補救工作

如果指派的驗證符合預期，下一步就是驗證補救。 使用 deployIfNotExists 或 modify 的原則，可能會觸發相關聯的補救工作，以更正不符合規範狀態的資源，讓資源符合規範。

補救資源的第一個步驟，是為原則指派授與原則定義中定義的角色指派。 此角色指派可讓原則指派受控識別有足夠的權限可進行所需的變更，使資源符合規範。

原則指派具有適當的權限後，請使用原則 SDK，對已知不符合規範的一組資源觸發補救工作。 繼續操作之前，應先對這些補救工作完成三項測試：

  • 驗證補救工作已順利完成
  • 執行原則評估，以確認原則合規性結果已如預期更新
  • 直接對資源執行環境單元測試，以驗證其屬性已變更

直接測試更新的原則評估結果和環境，可確認補救工作已變更預期的部分，且原則定義所顯示的合規性變更符合預期。

更新為強制指派

所有驗證閘道皆已完成後，請更新指派以使用 [啟用] 的 enforcementMode。 建議您應先在生產之前的同一個最初期的環境中進行這項變更。 驗證在資源建立和資源更新期間套用了所需的效果。 該環境經驗證可如預期運作之後，即應該將變更的範圍設定為包含下一個環境，依此類推，直到原則部署至生產資源為止。

程序整合評估

Azure 原則即程式碼的一般工作流程可在環境中大規模開發及部署原則和方案。 不過，任何在 Azure 中部署或建立資源的工作流程 (例如部署應用程式，或執行 ARM 範本以建立基礎結構)，均應將原則評估納入為部署程序的一部分。

在這些情況下，將應用程式或基礎結構部署至測試訂用帳戶或資源群組之後，即應對該範圍執行原則評估，以檢查所有現有原則和方案的有效性。 雖然其 enforcementMode 在這類環境中可能設定為停用，但及早了解應用程式或基礎結構部署是否違反原則定義，仍很有幫助。 因此，此原則評估應納入為這些工作流程中的步驟之一，使建立的資源不符合規範的部署失敗。

檢閱

本文說明 Azure 原則即程式碼的一般工作流程，以及應將原則評估納入其他部署工作流程中的階段。 任何環境只要支援指令碼式步驟和以觸發程序為基礎的自動化，都可以使用此工作流程。

下一步