本篇文章將進入實作環節，帶您一步步完成 AAP 與 Open Policy Agent (OPA) 的整合設定，並透過幾個具體的範例，深入解析 OPA 政策 (Policy) 如何即時驗證並控管自動化任務的執行。
一、基礎配置：建立 AAP 與 OPA 的溝通橋樑
首先，我們需要在 AAP 中設定 OPA 服務的端點 (Endpoint)，讓 AAP 知道該將執行請求送到哪裡進行驗證。
設定 Policy Enforcement 端點

1. 登入您的 AAP 環境，從左側導覽列進入 Settings。
2. 在 Automation execution 區塊中，點選 Policy。
   
3. 新增一個 Policy Enforcement 設定。在這個範例中，我們將使用一個由 OPA 官方提供的簡易 rego 規則伺服器。這是一個非常基礎且不安全的設定，主要用於功能演示與測試。
   
   pe.jeff.io是OPA server

二、初試啼聲：一個最簡單的「拒絕」策略
設定完成後，我們需要驗證 AAP 是否能成功與 OPA 溝通。最好的方法就是使用一個絕對會阻擋任務的規則，來確認政策執行功能已正確啟動。
將 Policy 綁定至 Job Template

1. 選擇一個您想用來測試的 Job Template (作業模板)，例如AAP裝好就有的範例的示範作業模板Demo Job Template。
2. 編輯該 Job Template，捲動到頁面下方的 Policy enforcement 政策部分下新增：
   
3. 儲存 Job Template 的變更。
   

執行與結果驗證
現在，直接啟動 (Launch) 這個 Job Template。
您會發現任務幾乎是瞬間就結束了，並且狀態顯示為紅色的 Error。這完全符合我們的預期！因為該端點背後的 OPA 規則 (allowed_false.rego) 非常簡單，其唯一的目的就是回傳「不允許」。

這個簡單的測試證明了：

1. AAP 在執行 Job 之前，確實向 OPA 發送了驗證請求。
2. AAP 正確地接收並解析了 OPA 的 allowed: false 回應。
3. AAP 根據回應成功地阻止了任務的執行。

三、進階應用：驗證 Job Template 的 Extra Variables
接下來，讓我們來挑戰一個更實用的場景：驗證使用者在執行 Job Template 時傳入的 Extra variables 是否符合規範。
我們將使用另一個 OPA 規則範例：extra_vars_validation。

情境一：預期失敗的測試

1. 回到 Job Template 的 Policy enforcement 設定，修改為aap_policy_examples/extra_vars_validation：
   
2. 在 Extra variables 區塊，加入一個不符合規則的鍵值對：
   
   
3. 儲存並再次啟動 Job Template。
   任務理所當然地失敗了。這次，OPA 的回應提供了更豐富的資訊，精確地告訴我們哪裡出了問題：
   
   回應清楚地指出：extra_var_key 的值不被允許，並貼心地提示了所有合法的值。

四、深入解析 Rego Policy (extra_vars_validation.rego)
https://github.com/ansible/example-opa-policy-for-aap/blob/main/aap_policy_examples/extra_vars_validation.rego
這個 extra_vars_validation 規則是如何運作的呢？讓我們來逐一拆解其 Rego 程式碼。

1. 資料定義：valid_extra_var_values
   
   這是一個靜態資料物件，是整個政策的「真理來源」(source of truth)
   鍵 (key) 是 $extra_vars$ 中需要被檢查的鍵名，這裡為 "extra_var_key"。
   值 (value) 是一個陣列 (array)，包含了所有被允許的值，這裡為 ["allowed_value1", "allowed_value2"]。
   如果未來需要驗證更多的鍵，可以直接擴充這個物件。

2. 預設規則：
   
   如果後續的 extra_vars_validation 規則因為條件不滿足而沒有被觸發，OPA 就會回傳這個預設值。這代表「預設允許」(default-allow) 的邏輯。換句話說，除非明確發現違規，否則就視為通過。

3. 主要驗證邏輯部分
   

讓我們一步步分解：
input_extra_vars := object.get(input, ["extra_vars"], {})
從傳入的 input 中安全地取得 extra_vars 物件。
object.get 函式的好處是，如果 input 中不存在 extra_vars，它會回傳指定的預設值 {} (一個空物件)，而不是導致錯誤。這讓政策更具彈性。

violating_keys := [key | ... ]
這是一個「列表生成式」(list comprehension)，用來建立一個名為$violating_keys 的列表。
valid_extra_var_values[key]: 這行會迭代 valid_extra_var_values 物件中的每一個鍵 (key)。在此範例中，key 只會有一個值："extra_var_key"。
not allowed_value(key, input_extra_vars[key]): 這是篩選條件。對於每一個 key，它會從 input_extra_vars 中取出對應的值，然後呼叫輔助規則 allowed_value 來檢查該值是否不被允許。如果 allowed_value 回傳 false，not 會將其轉為 true，從而將該 key 加入 violating_keys 列表中。

count(violating_keys) > 0
這是一個判斷條件。只有當 violating_keys 列表中的元素數量大於 0 (即，至少有一個鍵的值是違規的)，這個規則的主體才會被執行。

result := { ... }
如果上述條件成立，規則的最終結果 result 就會被設定為這個物件。
"allowed": false: 明確表示請求被拒絕。
"violations": 提供一個詳細的錯誤訊息陣列。sprintf 函式被用來格式化一個易於理解的字串，告訴使用者哪些鍵 (%v) 包含了不允許的值，並提示所有允許的值 (%v)。

4. 輔助規則：allowed_value(key, value)
   
   這是一個輔助規則 ，其功能非常單純：檢查給定的 value 是否存在於 key 對應的允許值列表中。

五、驗證修正後的與預設的場景
理解了 Rego 規則後，讓我們來完成最後的測試。

情境二：預期成功的測試
將 Extra variables 修改為規則所允許的值(extra_var_key: allowed_value2)：

再次執行 Job Template，任務成功運行！OPA 的回應也如預期般顯示允許：

情境三：觸發預設規則的測試
現在，我們將 Extra variables 區塊完全清空。

然後再次執行，任務同樣可以成功執行！這是因為當 extra_vars 為空時，主要驗證邏輯中的 violating_keys 列表會是空的，因此 count(violating_keys) > 0 條件不成立，OPA 最終回傳了我們設定的 default result。

最後我們從封包細節來看AAP傳了那些值過去OPA：

結論
透過這幾個範例，我們實際操作並驗證了 AAP 與 OPA 的整合流程。從一個簡單的全局阻擋規則，到一個針對 extra_vars 進行精確內容驗證的進階規則，我們可以清楚地看到 AAP 如何將 Job 的上下文（Context）傳遞給 OPA 進行決策。這為企業實現更精細、更動態的自動化治理策略（Governance）打下了堅實的基礎。