Red Hat Ansible Automation Platform (AAP) 近期引入了一項名為 Policy Enforcement 的強大功能，通常被稱為 Policy as Code。這項新功能旨在使企業能夠大規模地定義、管理並強制執行其 IT 自動化工作的治理、風險與合規性 (GRC) 要求。透過將策略直接整合到自動化工作流程中，組織可以確保其 Ansible 自動化內容在執行前、執行中和執行後，皆能符合內部政策與外部法規的嚴格標準。

核心概念：以程式碼定義與強制執行策略
傳統上，IT 策略通常被記錄在靜態文件中，依賴手動審查和流程來執行。這種方式不僅效率低下，更容易因人為疏忽而產生錯誤與風險。Ansible Automation Platform 的 Policy as Code 功能，其核心理念便是將這些抽象的策略轉化為可由機器讀取和自動執行的程式碼，實現自動化治理。

此功能的核心技術整合了業界廣泛採用的開源專案 Open Policy Agent (OPA)。OPA 是一個通用的策略引擎，它使用一種名為 Rego 的宣告式語言來編寫策略。其運作模式如下：

• 觸發評估：在自動化任務執行的特定階段（例如，作業啟動前）。
• 傳遞上下文：Ansible Automation Platform 會將相關的上下文資訊（如：使用者身份、主機清單、作業模板、傳入的變數等）打包成一個 JSON 物件。
• OPA 引擎判斷：此 JSON 物件會被傳送給 OPA 進行評估。OPA 引擎會根據預先定義好的 Rego 策略，對該請求進行判斷。
• 返回決策：評估結果可能是允許 (Allow)、拒絕 (Deny)，或是發出警告 (Warn)，AAP 接著會根據此決策執行相應的操作。

對 OPA 與 Rego 語法有興趣的讀者，可以參考官方文件獲得更詳細的資訊：Open Policy Agent Documentation
https://www.openpolicyagent.org/docs

實際應用場景：
Policy as Code 的應用範圍極廣，能有效解決企業在自動化管理上的諸多痛點，例如：

• 控制額外變數 (Extra Variables)：限制特定變數的格式、數值範圍，或禁止使用某些高風險變數。
• 強化存取控制：根據使用者角色或團隊，嚴格限制其對特定主機或清單的存取權限。
• 強制執行命名慣例：確保作業模板、專案或主機清單的命名符合公司規範，以利於管理與審計。
• 規範操作時間窗口：限制高風險的自動化作業只能在指定的維護時間內執行。
• 合規性檢查：確保執行的 Playbook 包含必要的標籤 (Tags)，或禁止執行被標記為「不安全」的模組。

筆者出於對此功能的興趣，自行建置了一套環境進行測試。以下將分享安裝 Red Hat AAP 並啟用 Policy as Code 功能的過程與注意事項。

1. 版本與功能狀態
首先，Policy as Code 功能需要安裝 AAP 2.5 或更新版本。在撰寫本文時，此功能仍處於技術預覽 (Tech Preview) 階段。
https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.5/html/release_notes/patch_releases#policy_as_code

根據官方文件，啟用此功能需要透過 feature flags 來明確開啟。
https://access.redhat.com/articles/7109282?extIdCarryOver=true&intcmp=RHCTG0250000449879&sc_cid=701f2000001Css0AAC

2. 安裝方式與環境準備
為了能將所有 AAP 元件部署在單一 VM 上，我選擇了 Containerized Installation (容器化安裝)。
安裝指南https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.5/html/containerized_installation/aap-containerized-installation#system-requirements

在安裝過程中，有幾點需要特別注意：

• 前置條件：除了作業系統 (Red Hat Enterprise Linux) 外，需要預先安裝並設定好 PostgreSQL 資料庫。
• 磁碟空間：官方文件雖提及 /var/tmp 及 /tmp 的空間需求，但我的經驗是 /home 目錄的空間也至關重要。我曾因 /home 空間不足（小於 6GB）而安裝失敗，其錯誤訊息可能會誤導方向，如下所示：
  ...unpacking failed (error: exit status 1; output: open /var/lib/awx/venv/awx/lib/python3.11/site-packages/sqlparse/filters/aligned_indent.py: no space left on device) dir: open /tmp/ansible.irbrnfvfimages/controller-rhel8.tar/manifest.json: not a directory"}
  這個錯誤看似是 /var 分區空間不足，但根本原因卻是執行安裝腳本時 /home 目錄被寫滿。請務必確保相關掛載點的空間充足。
• DNS 解析：在測試環境中，若無配置 DNS，可透過 /etc/hosts 檔案來完成所有主機名稱對 IP 的解析。
• 執行使用者：建議使用非 root 使用者來執行安裝程序，並確保該使用者已正確配置 sudoers 權限，避免在安裝過程中出現權限問題。https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.5/html/containerized_installation/aap-containerized-installation#preparing-the-managed-nodes-for-containerized-installation。

其他細節請參照https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.5/html/containerized_installation/aap-containerized-installation#preparing-the-rhel-host-for-containerized-installation

3. 執行安裝
安裝腳本需要一個 inventory-growth (all in one) 檔案來定義主機與相關變數。以下是一個精簡的範例，請根據您的環境進行修改：

[automationgateway]
controller.jeff.io
[automationcontroller]
controller.jeff.io
[database]
controller.jeff.io
[all:vars]
ansible_connection=local
backup_dir=/app/ansible-automation-platform-containerized-setup-bundle-2.5-17-x86_64/
postgresql_admin_username=請填user
postgresql_admin_password=請填密碼
bundle_install=true
bundle_dir=/app/ansible-automation-platform-containerized-setup-bundle-2.5-17-x86_64/bundle
redis_mode=standalone
gateway_admin_password=請填密碼
gateway_pg_host=controller.jeff.io
gateway_pg_password=請填密碼
controller_admin_password=請填密碼
controller_pg_host=controller.jeff.io
controller_pg_password=請填密碼
controller_percent_memory_capacity=0.5

接著，使用以下指令執行安裝 Playbook。請注意，我們透過 -e 參數直接傳遞 feature_flags 變數來啟用此功能：
ansible-playbook -i inventory-growth -e "{'feature_flags': {'FEATURE_POLICY_AS_CODE_ENABLED': True}}" ansible.containerized_installer.install

4. 功能驗證與觀察
   一些網路文章(如:https://github.com/ansible/example-opa-policy-for-aap/blob/main/docs/Enabling%20Policy%20as%20Code%20feature.md)提到可以透過 API 來檢查 feature_flags 的狀態。但在我的環境中，查詢 API 端點的結果並未直接顯示 FEATURE_POLICY_AS_CODE_ENABLED：
   
   儘管 API 回應中未列出，但實測證明 Policy as Code 功能確實已經成功啟用。我推測或許此功能會成為預設啟用項，不再需要透過 feature flags 手動開啟。因此，最好的驗證方式是直接在 AAP UI 中設定並測試一條簡單的 OPA 策略。
   AAP的GUI功能表亦可看到
   
   下一回，再來介紹OPA的安裝及整合部分