Azure Policy の使用に関するエラーをトラブルシューティングする
ポリシー定義を作成したり、SDK を操作したり、Kubernetes 用の Azure Policy アドオンを設定したりするときに、エラーが発生することがあります。 この記事では、発生する可能性があるさまざまな一般的エラーについて説明し、その解決方法を示します。
エラーの詳細を見つける
エラーの詳細の場所は、操作している Azure Policy の側面によって異なります。
- カスタム ポリシーを操作している場合は、Azure portal に移動し、リンティングによるスキーマに関するフィードバックを取得するか、結果のコンプライアンス データを確認して、リソースがどのように評価されたかを確認してください。
- さまざまな SDK を操作している場合は、SDK によって、関数が失敗した理由に関する詳細が提供されます。
- Kubernetes のアドオンを操作している場合は、クラスター内のログから開始します。
一般エラー
シナリオ:エイリアスが見つからない
問題
正しくないまたは存在しないエイリアスがポリシー定義で使用されています。 Azure Policy がエイリアスを使用して、Azure Resource Manager のプロパティにマップしています。
原因
正しくないまたは存在しないエイリアスがポリシー定義で使用されています。
解像度
まず、Resource Manager プロパティにエイリアスがあることを確認します。 使用可能なエイリアスを検索するには、Visual Studio Code 用の Azure Policy 拡張機能、または SDK にアクセスします。 Resource Manager プロパティのエイリアスが存在しない場合は、サポート チケットを作成します。
シナリオ:評価の詳細が最新ではない
問題
リソースが "Not Started (未開始) " 状態であるか、またはコンプライアンスの詳細が最新ではありません。
原因
新しいポリシーまたはイニシアチブの割り当ては、適用されるまでに約 5 分かかります。 既存の割り当てのスコープ内の新規または更新されたリソースは、約 15 分で使用できるようになります。 標準のコンプライアンス スキャンは、24 時間ごとに行われます。 詳細については、「評価のトリガー」を参照してください。
解像度
まず、評価が完了して Azure portal または SDK でコンプライアンスの結果を利用できるようになるまで、適切な時間待機します。 Azure PowerShell または REST API を使用して新しい評価スキャンを開始するには、「オンデマンドの評価スキャン」を参照してください。
シナリオ:コンプライアンスが想定どおりでない
問題点
あるリソースが、そのリソースに対して想定される "準拠している" または "準拠していない" の評価状態ではありません。
原因
リソースがポリシー割り当ての正しいスコープに含まれていないか、ポリシー定義が意図したとおりに動作していません。
解決方法
ポリシー定義をトラブルシューティングするには、次の手順を実行します。
- まず、評価が完了して Azure portal または SDK でコンプライアンスの結果を利用できるようになるまで、適切な時間待機します。
- Azure PowerShell または REST API を使用して新しい評価スキャンを開始するには、「オンデマンドの評価スキャン」を参照してください。
- 割り当てパラメーターと割り当てスコープが正しく設定されていることを確認します。
- ポリシー定義モードを確認します。
- モードは、すべてのリソースの種類に対して
all
である必要があります。 - ポリシー定義によってタグや場所が確認される場合は、モードは
indexed
である必要があります。
- モードは、すべてのリソースの種類に対して
- リソースのスコープが除外対象または適用除外対象でないことを確認します。
- ポリシー割り当ての準拠に
0/0
リソースが表示されている場合は、割り当てスコープ内で適用できると判断されたリソースはありません。 ポリシー定義と割り当てスコープの両方を確認してください。 - 準拠していると予期されていた非準拠のリソースについては、非準拠である理由の特定に関するページを参照してください。 定義と、評価されたプロパティ値を比較することで、リソースが非準拠であった理由がわかります。
- 対象の値が間違っている場合は、ポリシー定義を修正します。
- 現在の値が間違っている場合は、
resources.azure.com
を介してリソース ペイロードを検証します。
- RegEx 文字列パラメーターをサポートするリソース プロバイダー モード定義 (
Microsoft.Kubernetes.Data
や組み込み定義の "コンテナー イメージは信頼されたレジストリからのみデプロイする必要がある" など) の場合、RegEx 文字列パラメーターが正しいことを確認します。 - その他の一般的な問題と解決策については、トラブルシューティング: 適用が想定どおりでないに関する記事を参照してください。
複製してカスタマイズした組み込みのポリシー定義またはカスタム定義で引き続き問題が発生する場合は、問題が適切に転送されるように、"ポリシーの作成" についてサポート チケットを作成してください。
シナリオ:適用が想定どおりでない
問題
Azure Policy によって処理されると予想されているリソースが処理されておらず、Azure アクティビティ ログにエントリがありません。
原因
ポリシー割り当てで、enforcementMode の設定が "無効" に構成されました。 enforcementMode
が無効になっている間、そのポリシーの効果は適用されず、アクティビティ ログ内にエントリはありません。
解決方法
ポリシー割り当ての適用をトラブルシューティングするには、次の手順を実行します。
- まず、評価が完了して Azure portal または SDK でコンプライアンスの結果を利用できるようになるまで、適切な時間待機します。
- Azure PowerShell または REST API を使用して新しい評価スキャンを開始するには、「オンデマンドの評価スキャン」を参照してください。
- 割り当てパラメーターと割り当てスコープが正しく設定されていること、および
enforcementMode
が "有効" であることを確認します。 - ポリシー定義モードを確認します。
- モードは、すべてのリソースの種類に対して
all
である必要があります。 - ポリシー定義によってタグや場所が確認される場合は、モードは
indexed
である必要があります。
- モードは、すべてのリソースの種類に対して
- リソースのスコープが除外対象または適用除外対象でないことを確認します。
- リソースのペイロードがポリシー ロジックと一致することを確認します。 この確認は、HTTP アーカイブ (HAR) トレースをキャプチャする、または Azure Resource Manager テンプレート (ARM テンプレート) プロパティを確認することで実行できます。
- その他の一般的な問題と解決策については、「トラブルシューティング: コンプライアンスが想定どおりでない」を参照してください。
複製してカスタマイズした組み込みのポリシー定義またはカスタム定義で引き続き問題が発生する場合は、問題が適切に転送されるように、"ポリシーの作成" についてサポート チケットを作成してください。
シナリオ:Azure Policy による拒否
問題
リソースの作成または更新が拒否されました。
原因
新しいまたは更新されたリソースのスコープへのポリシー割り当てが、Deny 効果が適用されているポリシー定義の条件を満たしています。 これらの定義を満たしているリソースは、作成または更新できません。
解像度
拒否されたポリシー割り当てのエラー メッセージには、ポリシー定義とポリシー割り当て ID が含まれています。 メッセージ内のエラー情報が欠落している場合は、アクティビティ ログでも確認できます。 この情報を使用して、リソースの制限を理解し、許可された値に一致するように要求のリソース プロパティを調整します。
シナリオ: 複数のリソースの種類が定義の対象とされている
問題
複数のリソースの種類を含むポリシー定義が、作成時または更新時に次のエラーで検証に失敗します。
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}'.
原因
ポリシー定義ルールに、ターゲット リソースの種類によって評価されない 1 つ以上の条件が含まれています。
解決方法
エイリアスが使用されている場合、その前に種類の条件を追加することによって、そのエイリアスが属しているリソースの種類に対してのみエイリアスが評価されるようにします。 別の方法としては、ポリシー定義を複数の定義に分割して、複数のリソースの種類をターゲットにしないようにします。
シナリオ: サブスクリプションの上限超過
問題
Azure portal のコンプライアンス ページのエラー メッセージは、ポリシー割り当てのコンプライアンス取得時に表示されます。
原因
要求内で選択したスコープの下にあるサブスクリプションの数が、制限の 5,000 サブスクリプションを超えました。 コンプライアンスの結果が部分的に表示される場合があります。
解決方法
完全な結果を表示するには、より少ない子サブスクリプションを含む、より詳細なスコープを選択します。
テンプレート エラー
シナリオ:ポリシーでサポートされる関数がテンプレートによって処理される
問題点
Azure Policy では、多くの ARM テンプレート関数とポリシー定義内でのみ使用できる関数がサポートされています。 Resource Manager は、ポリシー定義の一部としてではなく、デプロイの一部としてこれらの機能を処理します。
原因
parameter()
や resourceGroup()
などのサポートされている関数を使用すると、ポリシー定義や Azure Policy エンジンの関数に処理させる代わりに、デプロイ時に関数の処理結果が得られます。
解決方法
関数をポリシー定義の一部として渡すには、プロパティが [[resourceGroup().tags.myTag]
のようになるように [
で文字列全体をエスケープします。 このエスケープ文字により、Resource Manager でテンプレートが処理されるときに値は文字列として扱われます。 その後、関数は Azure Policy によってポリシー定義に配置され、それにより、予期したとおりに動的になります。 詳細については、「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 チャートが既にインストールされているか、部分的にインストールされています。
解決方法
Kubernetes 用の Azure Policy アドオンを削除する指示に従ってから、helm install azure-policy-addon
コマンドを再実行します。
シナリオ:Azure 仮想マシンのユーザー割り当て ID がシステム割り当てマネージド ID に置き換えられる
問題
マシン内の監査設定にゲスト構成ポリシーのイニシアチブを割り当てると、マシンに割り当てられていたユーザー割り当てマネージド ID は割り当てられなくなります。 システム割り当てマネージド ID のみが割り当てられます。
原因
ゲスト構成の deployIfNotExists
定義内で以前に使用されていたポリシー定義により、システム割り当て ID はマシンに確実に割り当てられました。 しかし、ユーザー割り当て ID の割り当ても削除されました。
解決方法
以前にこの問題の原因となった定義は \[Deprecated\]
として表示され、ユーザー割り当てマネージド ID は削除されずに、前提条件を管理するポリシー定義に置き換えられています。 手動操作が必要です。 \[Deprecated\]
としてマークされているすべての既存のポリシー割り当てを削除し、元と同じ名前の、更新された前提条件ポリシー イニシアチブとポリシー定義に置き換えます。
詳細な説明については、ゲスト構成の監査ポリシーに関してリリースされた重要な変更に関するブログ記事を参照してください。
Kubernetes 一般的エラー用アドオン
シナリオ:エグレス制限のため、アドオンは Azure Policy サービス エンドポイントに接続できません
問題
アドオンは Azure Policy サービス エンドポイントに接続できず、次のいずれかのエラーが返されます。
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 Policy サービス エンドポイントに接続できない
問題
アドオンは Azure Policy サービス エンドポイントに接続できず、次のいずれかのエラーが返されます。
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
がクラスター上にインストールされており、kube-system ポッドが aad-pod-identity
内で除外されていない場合に発生します。
aad-pod-identity
コンポーネントの Node Managed Identity (NMI) ポッドは、ノードの iptable を変更し、Azure インスタンス メタデータ エンドポイントへの呼び出しをインターセプトします。 この設定は、ポッドが aad-pod-identity
を使用しない場合でも、メタデータ エンドポイントに対して行われたすべての要求は、NMI にインターセプトされることを意味します。 AzurePodIdentityException
CustomResourceDefinition (CRD) は、CRD 内で定義されたラベルに一致するポッドから送信されたメタデータエンドポイントへのすべての要求を、NMI 内で何も処理せずにプロキシ経由にする必要があることを aad-pod-identity
に通知するように構成できます。
解決方法
AzurePodIdentityException
CRD を構成することで、aad-pod-identity
内の kube-system 名前空間内に kubernetes.azure.com/managedby: aks
ラベルがあるシステム ポッドを除外します。
詳細については、特定のポッドまたはアプリケーションでの Azure Active Directory (Azure AD) ポッド ID の無効化に関する記事を参照してください。
例外を構成するには、この例に従ってください。
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 Policy サービス エンドポイントに接続できますが、アドオン ログに次のいずれかのエラーが表示されます。
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 Policy サービス エンドポイントに接続できますが、次のエラーが表示されます。
The subscription '{subId}' has been disabled for azure data-plane policy. Please contact support.
原因
このエラーは、サブスクリプションに問題があると判断され、このサブスクリプションをブロックするために機能フラグ Microsoft.PolicyInsights/DataPlaneBlocked
が追加されたことを示しています。
解決方法
この問題を調査して解決するには、機能チームにお問い合わせください。
シナリオ: "ゲスト構成" カテゴリの定義を Azure portal から複製できない
問題点
Azure portal のポリシー定義ページからカスタム ポリシー定義を作成しようとする際、[定義を複製する] ボタンを選択します。 そのポリシーを割り当てた後、ゲスト構成の割り当てリソースが存在しないために、マシンが "非準拠" になっていることに気付きます。
原因
ゲスト構成割り当てリソースを作成する際、ポリシー定義に追加されたカスタム メタデータが使用されます。 Azure portal 内の [定義を複製する] アクティビティでは、カスタム メタデータはコピーされません。
解決方法
ポータルではなく Policy Insights 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 Policy コンプライアンス上に顧客へのフラグとして非準拠として報告されます。
シナリオに関係なく、Azure ポリシーはクラスター上の最後の既知のポリシーを保持し、ガードレールをそのまま維持します。
次のステップ
お客様の問題がこの記事に掲載されていない場合、または解決できない場合は、次のいずれかのチャネルにアクセスしてサポートを受けてください。
- Microsoft Q&A を通じて、専門家からの回答を得る。
- @AzureSupport に問い合わせる。 この X 上の Microsoft Azure 公式リソースは、Azure コミュニティを適切な回答、サポート、エキスパートに結び付けることで、カスタマー エクスペリエンスの向上に役立ちます。
- それでもヘルプが必要な場合は、Azure サポート サイトにアクセスして、[サポート チケットの送信] を選択してください。