概要
サブスクリプションに Azure Policy の「Require a tag on resources（日本語表記：リソースでタグを必須にする 効果: Deny）」を割り当てている環境において、Azure Kubernetes Service（AKS）を新規作成すると、作成途中でエラーとなりクラスターが作成できない事象が発生しました。
本記事では、以下の内容を整理します。
- 発生する事象
- 発生する理由
- 対処方法
- 推奨される対処方法の考え方
- そのほかに起こりうる影響例
前提条件・確認環境
- Azure サブスクリプションへのポリシー割り当て権限があること
- AKS 作成時に「Azure Monitor マネージド Prometheus（推奨アラート）」を有効化していること
- Windows 環境から Azure Portal を使用して操作していること
発生する事象
サブスクリプションに以下のポリシーが割り当てられている状態で、AKS を新規作成するとエラーになります。
- ポリシー：Require a tag on resources
- 効果（Effect）：Deny
エラーメッセージ例（Azure Portal のデプロイエラー画面に表示されます）
一見すると Prometheus 関連の設定エラーに見えますが、実際にはタグ必須ポリシーが原因で作成がブロックされています。
発生する理由
AKS の作成時には、ユーザーが明示的に作成していない内部リソースが自動的に作成されます。
その中には、作成時にタグを指定する手段がないリソースが含まれており、タグ必須ポリシーが有効な場合、その内部リソースの作成が拒否されます。
結果として、AKS クラスター全体の作成が失敗します。
特に、AKS 作成時に Azure Monitor マネージド Prometheus（推奨アラート）を有効化している場合に、この問題が発生しやすくなります。
対処方法
本事象に対する主な対処方法は以下の 4 つです。
対処方法 1（推奨）: prometheusRuleGroups の適用除外を作成する
ポリシー割り当てに対して適用除外（Policy Exemption）を作成し、リソースタイプの条件として以下を指定します。
Microsoft.AlertsManagement/prometheusRuleGroups
これにより、AKS 作成時に自動生成される Prometheus 関連リソースのみがタグ必須ポリシーの評価対象から除外されます。
設定手順の概要
- Azure Portal で [ポリシー] > [適用除外] に移動します。
- [+ 適用除外の追加] を選択し、スコープとして対象のサブスクリプションまたはリソースグループを指定します。
- 適用除外の対象ポリシー割り当てとして、リソースでタグを必須にする の割り当てを選択します。
- リソースセレクターを使用して、リソースタイプに
Microsoft.AlertsManagement/prometheusRuleGroupsを指定します。 - 適用除外カテゴリを選択して保存します。
対処方法 2: AKS 作成時に Prometheus を有効化しない
AKS 作成時の設定で、Azure Monitor マネージド Prometheus（推奨アラート）を有効化せずにクラスターを作成します。
Prometheus 関連の内部リソースが作成されなくなるため、タグ必須ポリシーによるブロックを回避できます。
ただし、クラスター作成後に Prometheus を有効化する場合は、同様にタグ必須ポリシー違反が発生する可能性があります。その場合も対処方法 1 と同様の手順で適用除外を作成してください。
なお、検証目的であれば Prometheus を有効化しないまま運用する選択肢もありますが、本番環境での運用においては、監視・アラートの設計を別途検討するか、対処方法 1 を適用した上で Prometheus を有効化することを推奨します。
対処方法 3: 事前にリソースグループを作成し、そのリソースグループを除外する
AKS を作成する専用のリソースグループをあらかじめ作成し、そのリソースグループをポリシーの適用除外対象に設定します。
対処方法 4: 一時的にポリシー割り当てを無効化する
AKS 作成時のみ、タグ必須ポリシーの割り当てを一時的に無効化し、作成完了後に再度有効化します。
対処方法 1 を推奨する理由
対処方法 1（リソースタイプ単位での適用除外）が最も推奨される理由は次のとおりです。
- 除外範囲が最小限である
- 業務で利用するリソースへのタグ必須ルールを維持できる
- 将来的にリソースグループ単位の例外運用を増やさずに済む
- AKS 本体のリソースは引き続きポリシーの評価対象にできる
対処方法 2 は検証目的での一時的な回避策としては有効ですが、本番環境での監視設計を考慮すると、後から同じ問題が再発する可能性があります。
一方、リソースグループ単位の除外（対処方法 3）やポリシー割り当ての一時無効化（対処方法 4）は、意図しないリソース作成まで許可してしまうリスクが高く、ガバナンスの観点では推奨されません。
まとめ
タグ必須ポリシーは有効なガバナンス手段ですが、ユーザーがタグを指定できない内部リソースやサービスが自動生成するリソースが存在することを前提に設計する必要があります。
AKS 作成でエラーが発生する場合は、ポリシーを緩めるのではなく、リソースタイプ単位で適用除外（対処方法 1）を設定することが最も安全で実務上も推奨される対応方法です。
補足: そのほかに起こりうる影響例
タグ必須ポリシー（Deny）を有効にしている環境では、AKS 以外にも「作成時にタグを指定できないリソース」で同様の問題が発生することがあります。
Azure Automation Runbook
既存の Automation アカウントに対して Runbook を新規作成しようとすると、タグ必須ポリシーによって作成が拒否される場合があります。
Runbook の作成画面では、タグを指定する手段が提供されていません。そのため、タグ必須ポリシーが有効な環境では、Azure Portal からの Runbook 作成が拒否されます。
対処方法としては、対象の Automation アカウントをポリシーの適用除外に設定することで Runbook の作成が可能になります。なお、この方法で作成した Runbook にはタグが付与されないため、必要に応じてデプロイ後にタグを手動で付与してください。
参考情報
- Azure Policy の組み込みポリシー定義 - タグ | Microsoft Learn
- Azure Policy の適用除外の構造 | Microsoft Learn
- Azure Monitor マネージド Prometheus の概要 | Microsoft Learn
- Azure リソースでのタグのサポート | Microsoft Learn
- 新規リソース作成時にタグ付けを必須とするポリシーの設定方法 | Cloud Steady（Runbook が作成できない事象についての参考情報。なお、本記事は 2022 年 9 月時点の情報です）