針對使用 Azure 原則的錯誤進行疑難排解

  • 發行項

建立原則定義、使用 SDK，或設定適用於 Kubernetes 的 Azure 原則附加元件時，可能會發生錯誤。 本文描述可能發生的各種一般錯誤，並建議這些錯誤的解決方法。

尋找錯誤詳細資料

錯誤詳細資料的位置取決於目前使用的 Azure 原則層面。

  • 如果您正在使用自訂原則，請移至 Azure 入口網站以取得有關架構的 Lint 分析意見反應，或檢閱產生的合規性資料以查看資源的評估方式。
  • 如果您使用多種 SDK 的其中一種，則 SDK 會提供函式失敗原因的詳細資料。
  • 如果您是使用 Kubernetes 的附加元件，請從叢集中的記錄開始。

一般錯誤

案例：找不到別名

問題

原則定義中使用不正確或不存在的別名。 Azure 原則使用別名以對應至 Azure Resource Manager 屬性。

原因

原則定義中使用不正確或不存在的別名。

解決方法

首先，驗證 Resource Manager 屬性是否具有別名。 若要查閱可用的別名，移至適用於 Visual Studio Code 的 Azure 原則延伸模組或 SDK。 如果 Resource Manager 屬性的別名不存在，請建立支援票證。

案例：評估詳細資料不是最新

問題

資源處於未啟動狀態，或合規性詳細資料不是最新。

原因

套用新原則或方案指派大約需要 5 分鐘。 現有指派範圍內的新資源或更新資源大約會在 15 分鐘內提供。 標準合規性掃描會每隔 24 小時發生一次。 如需詳細資訊，請參閱評估觸發程序。

解決方法

首先，等候適當的時間量，讓評估完成並讓合規性結果在 Azure 入口網站或 SDK 中變得可用。 若要使用 Azure PowerShell 或 REST API 開始新的評估掃描，請參閱隨選評估掃描。

案例：合規性未如預期

問題

不處於符合規範或不符合規範評估狀態的資源，是資源的預期狀態。

原因

資源不在原則指派的正確範圍內，或原則定義無法如預期般運作。

解決方法

若要針對原則定義進行疑難排解，請執行下列動作：

  1. 首先，等候適當的時間量，讓評估完成並讓合規性結果在 Azure 入口網站或 SDK 中變得可用。

  2. 若要使用 Azure PowerShell 或 REST API 開始新的評估掃描，請參閱隨選評估掃描。

  3. 確保已正確設定指派參數和指派範圍。

  4. 檢查原則定義模式：

    • 所有資源類型的模式應該為 all。
    • 如果原則定義會檢查標籤或位置，則模式應該為 indexed。

  5. 確保未排除或豁免資源的範圍。

  6. 如果原則指派的合規性顯示 0/0 資源，則不會判定任何資源在指派範圍內適用。 檢查原則定義和指派範圍。

  7. 對於預期符合規範的不相容資源，請參閱判斷不符合規範的原因。 定義與所評估屬性值的比較會指出資源不符合規範的原因。

    • 如果目標值錯誤，請修改原則定義。
    • 如果目前的值錯誤，請透過 resources.azure.com 驗證資源承載。

  8. 對於支援 RegEx 字串參數的資源提供者模式定義 (例如 Microsoft.Kubernetes.Data 和內建定義「容器映像只能從信任的登錄部署」)，請驗證 RegEx 字串參數是否正確。

  9. 如需其他常見問題和解決方案，請參閱疑難排解：強制執行未如預期。

如果您仍有重複和自訂的內建原則定義或自訂定義的問題，請在撰寫原則底下建立支援票證，以將問題正確路由。

案例：強制執行未如預期

問題

您預期套用 Azure 原則的資源並未套用，而且 Azure 活動記錄中沒有任何項目。

原因

已針對設為 Disabled 的 enforcementMode 設定，設定原則指派。 停用 enforcementMode 時，不會強制執行原則效果，而且活動記錄中沒有項目。

解決方法

執行下列動作，針對原則指派的強制執行進行疑難排解：

  1. 首先，等候適當的時間量，讓評估完成並讓合規性結果在 Azure 入口網站或 SDK 中變成可用。

  2. 若要使用 Azure PowerShell 或 REST API 開始新的評估掃描，請參閱隨選評估掃描。

  3. 確保已正確設定指派參數和指派範圍，且 enforcementMode 為 Enabled。

  4. 檢查原則定義模式：

    • 所有資源類型的模式應該為 all。
    • 如果原則定義會檢查標籤或位置，則模式應該為 indexed。

  5. 確保未排除或豁免資源的範圍。

  6. 驗證資源承載符合原則邏輯。 做法是擷取 HTTP 封存 (HAR) 追蹤，或檢閱 Azure Resource Manager 範本 (ARM 範本) 屬性。

  7. 如需其他常見問題和解決方案，請參閱疑難排解：合規性未如預期。

如果您仍有重複和自訂的內建原則定義或自訂定義的問題，請在撰寫原則底下建立支援票證，以將問題正確路由。

案例：遭到 Azure 原則拒絕

問題

建立或更新資源遭到拒絕。

原因

新資源或更新資源範圍的原則指派符合原則定義的準則，並具有拒絕效果。 無法建立或更新符合這些定義的資源。

解決方法

拒絕原則指派的錯誤訊息包含原則定義和原則指派識別碼。 如果錯過訊息中的錯誤資訊，也可以在活動記錄中找到。 使用此資訊可取得更多詳細資料，以了解資源限制，並調整要求中的資源屬性以符合允許的值。

案例：定義以多個資源類型為目標

問題

包含多個資源類型的原則定義在建立或更新期間無法通過驗證，並出現下列錯誤：

The policy definition '{0}' targets multiple resource types, but the policy rule is authored in a way that makes the policy not applicable to the target resource types '{1}'.

原因

原則定義規則有一或多個條件，其不會由目標資源類型評估。

解決方法

如果有使用別名，請確定只會根據其所屬的資源類型評估該別名，方法是在其之前新增類型條件。 替代方法是將原則定義分割成多個定義，以避免以多個資源類型為目標。

案例：超過訂用帳戶限制

問題

擷取原則指派的合規性時，Azure 入口網站中的合規性頁面上顯示錯誤訊息。

原因

要求中所選範圍下的訂用帳戶數目已超過 5000 個訂用帳戶的限制。 合規性結果可能會部分顯示。

解決方法

選取具有較少子訂用帳戶的更細微範圍，以查看完整的結果。

範本錯誤

案例：範本所處理的原則支援函式

問題

Azure 原則支援一些 ARM 範本函式和僅於某個原則定義中提供的函式。 Resource Manager 會隨著部署的一部分處理這些函式，而不是作為原則定義的一部分。

原因

使用支援的函式，例如 parameter() 或 resourceGroup()，會導致函式在部署期間已處理的結果，而不是允許原則定義和 Azure 原則引擎處理的函式。

解決方法

若要將函式作為原則定義的一部分傳遞，請使用 [ 逸出整個字串，讓屬性看起來像 [[resourceGroup().tags.myTag]。 逸出字元會導致 Resource Manager 在處理範本時將值視為字串。 然後 Azure 原則會將函式放入原則定義中，讓函式如預期成為動態。 如需詳細資訊，請參閱 Azure Resource Manager 範本中的語法和運算式。

Kubernetes 安裝錯誤的附加元件

案例：使用 Helm Chart 安裝失敗，因為發生密碼錯誤

問題

helm install azure-policy-addon 命令失敗，並傳回下列其中一個錯誤：

  • !: event not found
  • Error: failed parsing --set data: key "<key>" has no value (cannot end with ,)

原因

產生的密碼包含逗號 (,)，Helm Chart 用其進行分割。

解決方法

執行 helm install azure-policy-addon 時，請使用反斜線 (\)，將密碼值中的逗號 (,) 逸出。

案例：使用 Helm Chart 安裝失敗，因為名稱已存在

問題

helm install azure-policy-addon 命令失敗，並傳回下列錯誤：

  • Error: cannot re-use a name that is still in use

原因

名稱為 azure-policy-addon 的 Helm Chart 已安裝或部分安裝。

解決方法

依照指示移除適用於 Kubernetes 的 Azure 原則附加元件，然後重新執行 helm install azure-policy-addon 命令。

案例：Azure 虛擬機器使用者指派的識別會由系統指派的受控識別取代

問題

指派來賓設定原則計劃來稽核機器內的設定之後，就不再會指派已指派給機器的使用者指派受控識別。 只會指派系統指派的受控識別。

原因

先前用於來賓設定 DeployIfNotExists 定義的原則定義，可確保系統指派的識別會指派給機器，但也會移除使用者指派的識別指派。

解決方法

先前造成此問題的定義會顯示為 [已取代]，而且會由管理必要條件的原則定義取代，而不需要移除使用者指派的受控識別。 需要手動步驟。 刪除標示為 [已取代] 的任何現有原則指派，並將其取代為更新的必要條件原則方案和原則定義 (名稱與原始原則定義相同)。

如需詳細的敘述，請參閱部落格文章針對來賓設定稽核原則發行的重要變更。

Kubernetes 一般錯誤的附加元件

案例：附加元件因為輸出限制而無法連線到 Azure 原則服務端點

問題

附加元件無法連線到 Azure 原則服務端點，並傳回下列其中一個錯誤：

  • failed to fetch token, service not reachable
  • Error getting file "Get https://raw.githubusercontent.com/Azure/azure-policy/master/built-in-references/Kubernetes/container-allowed-images/template.yaml: dial tcp 151.101.228.133.443: connect: connection refused

原因

叢集輸出遭到鎖定時，就會發生此問題。

解決方法

確保下列文章中所提及的網域和連接埠已開啟：

案例：附加元件因為 aad-pod-identity 設定而無法連線到 Azure 原則服務端點

問題

附加元件無法連線到 Azure 原則服務端點，並傳回下列其中一個錯誤：

  • azure.BearerAuthorizer#WithAuthorization: Failed to refresh the Token for request to https://gov-prod-policy-data.trafficmanager.net/checkDataPolicyCompliance?api-version=2019-01-01-preview: StatusCode=404
  • adal: Refresh request failed. Status Code = '404'. Response body: getting assigned identities for pod kube-system/azure-policy-8c785548f-r882p in CREATED state failed after 16 attempts, retry duration [5]s, error: <nil>

原因

在叢集上安裝 aad-pod-identity 且未在 aad-pod-identity 中排除 kube-system Pod 時，就會發生此錯誤。

aad-pod-identity 元件節點受控識別 (NMI) Pod 會修改節點的 iptable 來攔截對 Azure 執行個體中繼資料端點的呼叫。 此設定表示即使 Pod 未使用 aad-pod-identity，對中繼資料端點所做的任何要求仍遭到 NMI 攔截。 AzurePodIdentityException CustomResourceDefinition (CRD) 可以設定為通知 aad-pod-identity，對源自符合 CRD 中所定義標籤的 Pod 的中繼資料端點的任何要求都應該經過代理，而不需在 NMI 中進行任何處理。

解決方法

藉由設定 AzurePodIdentityException CRD，排除在 aad-pod-identity 的 kube-system 命名空間中具有 kubernetes.azure.com/managedby: aks 標籤的系統 Pod。

如需詳細資訊，請參閱停用特定 Pod/應用程式的 Azure Active Directory (Azure AD) Pod 識別。

若要設定例外狀況，請遵循此範例：

apiVersion: "aadpodidentity.k8s.io/v1"
kind: AzurePodIdentityException
metadata:
  name: mic-exception
  namespace: default
spec:
  podLabels:
    app: mic
    component: mic
---
apiVersion: "aadpodidentity.k8s.io/v1"
kind: AzurePodIdentityException
metadata:
  name: aks-addon-exception
  namespace: kube-system
spec:
  podLabels:
    kubernetes.azure.com/managedby: aks

案例：尚未註冊資源提供者

問題

附加元件可以連線到 Azure 原則服務端點，但附加元件記錄會顯示下列其中一個錯誤：

  • The resource provider 'Microsoft.PolicyInsights' is not registered in subscription '{subId}'. See https://aka.ms/policy-register-subscription for how to register subscriptions.

  • policyinsightsdataplane.BaseClient#CheckDataPolicyCompliance: Failure responding to request: StatusCode=500 -- Original Error: autorest/azure: Service returned an error. Status=500 Code="InternalServerError" Message="Encountered an internal server error.

原因

尚未註冊 'Microsoft.PolicyInsights' 資源提供者。 必須註冊，附加元件才能取得原則定義並傳回合規性資料。

解決方法

在叢集訂用帳戶中註冊 'Microsoft.PolicyInsights' 資源提供者。 如需指示，請參閱註冊資源提供者。

案例：訂用帳戶已停用

問題

附加元件可以連線到 Azure 原則服務端點，但會顯示下列錯誤：

The subscription '{subId}' has been disabled for azure data-plane policy. Please contact support.

原因

此錯誤表示已判定訂用帳戶發生問題，並且已新增功能旗標 Microsoft.PolicyInsights/DataPlaneBlocked，以封鎖該訂用帳戶。

解決方法

若要調查並解決此問題，請連絡功能小組。

案例：類別「來賓設定」中的定義無法從 Azure 入口網站複製

問題

嘗試從原則定義的 Azure 入口網站頁面建立自訂原則定義時，您可以選取 [複製定義] 按鈕。 指派原則之後，您會發現機器為不符合規範，因為不存在任何來賓設定指派資源。

原因

來賓設定依賴於建立來賓設定指派資源時新增至原則定義的自訂中繼資料。 Azure 入口網站中的「複製定義」活動不會複製自訂中繼資料。

解決方法

不要使用入口網站，而是使用原則深入解析 API 來複製原則定義。 下列 PowerShell 範例提供一個選項。

# duplicates the built-in policy which audits Windows machines for pending reboots
$def = Get-AzPolicyDefinition -id '/providers/Microsoft.Authorization/policyDefinitions/4221adbc-5c0f-474f-88b7-037a99e6114c' | % Properties
New-AzPolicyDefinition -name (new-guid).guid -DisplayName "$($def.DisplayName) (Copy)" -Description $def.Description -Metadata ($def.Metadata | convertto-json) -Parameter ($def.Parameters | convertto-json) -Policy ($def.PolicyRule | convertto-json -depth 15)

案例：儘管指派了拒絕原則，仍會在連線失敗期間建立 Kubernetes 資源

問題

如果 Kubernetes 叢集連線失敗，可能會因為 Gatekeeper 的失敗開啟行為而略過新建立或更新資源的評估。

原因

GK 失敗開啟模型為預設設計，並且是基於社群的意見反應。 這裡的 Gatekeeper 文件會延伸說明原因：https://open-policy-agent.github.io/gatekeeper/website/docs/failing-closed#considerations。

解決方法

在上述事件中，可以從 kube-apiserver 所提供的許可 Webhook 計量監視錯誤案例。 而即使在建立時略過評估，且建立了物件，仍會在 Azure 原則合規性以旗標向客戶回報為不符合規範。

無論上述情況如何，在這類案例中，Azure 原則仍會保留叢集上最後一個已知原則，並就地保留護欄。

下一步

如果您的問題未列於本文中，或您無法解決此問題，請瀏覽下列其中一個通道來取得支援：

  • 透過 Microsoft Q&A 取得專家的解答。
  • 與 @AzureSupport 連絡。 Twitter 上的此官方 Microsoft Azure 資源，透過連線 Azure 社群以獲得正確的答案、支援和專家，以協助改善客戶體驗。
  • 如果您仍然需要協助，請移至 Azure 支援網站，然後選取 [提交支援要求]。