Azure REST API のドキュメント更新で追加された AKS の cluster-level FIPS は、AKS クラスター全体で FIPS モードを宣言・強制するためのプレビュー API 変更です。結論から言うと、通常の AKS 利用者がすぐ本番設定を変更する必要はありません。一方で、FedRAMP などのコンプライアンス要件を意識して AKS を運用しているチーム、ARM テンプレート・Bicep・REST API・SDK で AKS を自動構築しているチームは、早めに仕様差分を確認すべきです。
今回の変更で重要なのは、従来の「ノードプール単位で FIPS 対応イメージを使う」という考え方に加えて、ManagedClusterProperties にクラスター単位の enableFIPS が追加された点です。特に、enableFIPS を有効にする場合は、クラスター内のすべてのノードプールも FIPS 対応である必要があるため、既存環境へ安易に適用すると構成不整合やデプロイ失敗につながる可能性があります。(GitHub)
Azure REST API のドキュメント更新で何が変わったのか
今回の Azure REST API documentation update は、Azure Kubernetes Service、つまり AKS の 2026-03-02-preview API に対する変更です。GitHub の Azure REST API 仕様リポジトリでは、PR #42799「Add cluster-level FIPS to AKS 2026-03 preview」として管理され、ManagedClusterProperties に enableFIPS プロパティを追加する内容として説明されています。(GitHub)
変更点を実務目線で整理すると、次のようになります。
| 確認項目 | 内容 |
|---|---|
| 対象サービス | Azure Kubernetes Service（AKS） |
| 対象 API | ARM / Control Plane API |
| API バージョン | 2026-03-02-preview |
| 追加プロパティ | properties.enableFIPS |
| 型 | boolean |
| 位置づけ | プレビュー API に対する追加変更 |
| 主な影響 | AKS クラスター単位で FIPS モードを有効化する構成を表現できる |
| 注意点 | 有効化時は、すべてのノードプールも FIPS 対応である必要がある |
PR の説明では、この変更は「additive preview API change」とされています。つまり、既存の安定版 API を直接破壊する変更ではなく、プレビュー API に新しいプロパティが追加された形です。変更ファイルには、TypeSpec の共通モデル、クライアント向けカスタマイズ、2026-03-02-preview の managedClusters.json が含まれています。(GitHub)
cluster-level FIPS は従来のノードプール FIPS と何が違うのか
AKS の FIPS 対応は、これまでもノードプール単位で利用できました。Microsoft Learn では、AKS で FIPS 140-2 が有効な Linux および Windows ノードプールを作成でき、FIPS 対応ノードプール上のデプロイが暗号モジュールを利用してセキュリティ要件への対応を支援できると説明されています。(Microsoft Learn)
従来の考え方は、主に「どのノードプールを FIPS 対応にするか」でした。今回追加された cluster-level FIPS は、「クラスター全体として FIPS を有効にするか」を ARM API 上で表現するものです。
| 観点 | 従来のノードプール FIPS | 今回の cluster-level FIPS |
|---|---|---|
| 設定単位 | ノードプール | AKS クラスター |
| 主なプロパティ | agentPoolProfiles[].enableFIPS など | properties.enableFIPS |
| 目的 | FIPS 対応ノードイメージの利用 | AKS 管理コンポーネントを含めたクラスター単位の FIPS 有効化 |
| 影響範囲 | 対象ノードプール上のワークロード | ノード OS、アドオン、AKS 管理のコンテナ化コンポーネントなど |
| 注意点 | ノードプールごとに設定漏れが起きやすい | 全ノードプールの FIPS 対応が前提になる |
PR 内の説明では、cluster-level FIPS を有効にすると、ノード OS、アドオン、AKS 管理のコンテナ化コンポーネントなど、AKS 管理対象コンポーネントに対して FIPS 準拠を強制する旨が記載されています。また、このプロパティを有効にする場合、クラスター内のすべてのノードプールも FIPS 対応でなければならないとされています。(GitHub)
ここで誤解しやすいのは、cluster-level FIPS を有効にすれば、アプリケーションのコンテナイメージまで自動的に FIPS 準拠として評価されるわけではない点です。Microsoft Learn の FIPS ノードプールに関する制限事項でも、FIPS ノード上のコンテナーイメージは FIPS 準拠について評価されないと説明されています。(Microsoft Learn)
誰が対応すべきか
今回の Azure REST API documentation update で、特に確認が必要なのは次のようなチームです。
| 対象者 | 確認すべき理由 |
|---|---|
| AKS をコンプライアンス要件下で運用しているチーム | FIPS をクラスター全体の統制項目として扱える可能性があるため |
| ARM テンプレートや Bicep で AKS を作成しているチーム | properties.enableFIPS をテンプレートに追加すべきか判断する必要があるため |
| REST API で AKS を自動構築しているチーム | 2026-03-02-preview を利用する場合、リクエスト・レスポンスに新プロパティが現れるため |
| Azure SDK を利用する開発チーム | SDK 生成やプロパティ名の違いに注意が必要なため |
| セキュリティ監査や構成監査を担当するチーム | 「ノードプールだけ確認する」監査では不十分になる可能性があるため |
逆に、AKS を通常の開発・検証用途で使っていて、FIPS 要件がない場合は、今回の変更だけで急いで構成を変える必要はありません。2026-03-02-preview はプレビュー API であり、本番適用前には対象リージョン、サブスクリプション、Azure CLI / SDK / IaC ツールの対応状況を確認する必要があります。
REST API や IaC で確認すべき影響範囲
Azure REST API の観点では、AKS の Managed Clusters は ARM の管理プレーン API として扱われます。現行の AKS REST API ドキュメントでも、マネージドクラスターの作成または更新は PUT メソッドで行われることが示されています。(Microsoft Learn)
今回の追加により、2026-03-02-preview を使う場合は、AKS クラスター作成・更新時の JSON に次のようなプロパティが含まれる可能性があります。
{
"location": "japaneast",
"properties": {
"dnsPrefix": "my-aks",
"enableRBAC": true,
"enableFIPS": true,
"agentPoolProfiles": [
{
"name": "systempool",
"mode": "System",
"type": "VirtualMachineScaleSets",
"count": 3,
"vmSize": "Standard_D4s_v5",
"osType": "Linux",
"enableFIPS": true
}
]
},
"identity": {
"type": "SystemAssigned"
}
}実務で注意したいのは、enableFIPS の位置です。クラスター単位の enableFIPS は properties 直下にあります。一方、ノードプール単位の FIPS は agentPoolProfiles 配下にあります。名前が似ているため、テンプレートレビュー時に混同しやすいポイントです。
SDK 利用時はプロパティ名の差にも注意する
PR では、C# と Java の SDK クライアント向けに FIPS の頭字語を扱う命名カスタマイズも追加されています。具体的には、C# では IsFipsEnabled、Java では enableFips というクライアント名のカスタマイズが追加されています。(GitHub)
REST API の JSON では enableFIPS でも、SDK では言語ごとの命名規則に合わせて表記が変わる場合があります。監査スクリプトや生成コードを直接参照している場合は、REST のプロパティ名と SDK のプロパティ名を同一視しないようにしてください。
既存 AKS クラスターでまず確認すること
既存環境に対して最初に行うべきことは、cluster-level FIPS を有効化することではありません。まず、現在の AKS クラスターとノードプールの FIPS 状態を把握します。
ノードプール単位の FIPS 状態を確認する
Microsoft Learn では、az aks show で agentPoolProfiles の enableFips を確認する例が示されています。(Microsoft Learn)
az aks show \
--resource-group <resource-group-name> \
--name <aks-cluster-name> \
--query "agentPoolProfiles[].{name:name, enableFips:enableFips}" \
-o table出力例は次のようになります。
Name EnableFips
---------- ----------
systempool true
userpool1 falseこの例では、userpool1 が FIPS 対応ではありません。cluster-level FIPS を有効化する前に、このようなノードプールをどう扱うかを決める必要があります。単にプロパティを追加するだけではなく、ノードプールの再作成、ワークロード退避、Pod Disruption Budget、スケール設定、メンテナンス時間帯まで含めて計画してください。
cluster-level FIPS のプロパティを REST API で確認する
2026-03-02-preview API が利用できる環境では、次のように REST API 経由で properties.enableFIPS を確認できます。
az rest \
--method get \
--url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedClusters/<aks-cluster-name>?api-version=2026-03-02-preview" \
--query "properties.{clusterEnableFIPS:enableFIPS,nodePools:agentPoolProfiles[].{name:name,enableFips:enableFips}}"プレビュー API のため、環境によっては API バージョンがまだ利用できない、またはプロパティが返らない場合があります。その場合は、現在利用している API バージョン、Azure CLI、SDK、リージョン、プレビュー機能の提供状況を確認してください。
移行や導入を検討する際の判断基準
cluster-level FIPS を導入するかどうかは、「FIPS が使えるなら有効化する」ではなく、要件から逆算して判断するのが安全です。
| 判断ポイント | 確認内容 |
|---|---|
| コンプライアンス要件 | FIPS をクラスター全体で強制する必要があるか |
| 対象環境 | 本番、検証、規制対象ワークロードのどれに適用するか |
| ノードプール構成 | すべての System / User ノードプールが FIPS 対応可能か |
| OS とイメージ | 利用中の OS SKU が FIPS 対応ノードプールをサポートしているか |
| アドオン | 監視、Ingress、CSI、セキュリティ系アドオンの動作確認が済んでいるか |
| IaC | ARM テンプレート、Bicep、Terraform、CI/CD に設定漏れがないか |
| 運用影響 | ノードイメージ更新、再イメージ化、メンテナンス時間を考慮しているか |
新規クラスターであれば、最初から cluster-level FIPS と全ノードプールの FIPS 対応をそろえる設計がしやすくなります。既存クラスターでは、非 FIPS ノードプールが混在しているケースが多いため、設定追加よりも移行計画が重要です。
特に、FIPS 対応 Linux イメージは通常の Linux イメージとは異なり、バージョン番号や更新サイクルが異なる場合があると Microsoft Learn で説明されています。(Microsoft Learn) そのため、ノードイメージの更新タイミングや検証環境での再現性も確認しておくべきです。
失敗しやすいポイント
cluster-level FIPS はセキュリティ上わかりやすい設定に見えますが、実務では次のようなミスが起きやすくなります。
| 失敗例 | なぜ問題になるか | 対策 |
|---|---|---|
クラスターだけ enableFIPS: true にする | ノードプールが FIPS 非対応だと整合性が取れない | すべての agentPoolProfiles を確認する |
| 既存の User ノードプールを見落とす | 一部ワークロードだけ非 FIPS ノードに残る | System / User の両方を棚卸しする |
| SDK のプロパティ名だけで判断する | REST JSON と SDK の命名が異なる場合がある | REST 仕様と利用 SDK の両方を確認する |
| FIPS を有効にすればアプリも準拠すると誤解する | コンテナイメージ自体は自動評価されない | アプリ側の暗号ライブラリやベースイメージも監査する |
| ストレージ接続を事前検証しない | FIPS により一部の認証モジュールが無効になり、CIFS 共有のマウントに影響する場合がある | ファイル共有、CSI、バックアップ処理を検証する |
| プレビュー API を本番前提で組み込む | 仕様や提供状況が変わる可能性がある | 非本番で検証し、安定版 API の反映を追跡する |
Microsoft Learn の制限事項では、FIPS によって一部の認証モジュールが無効になるため CIFS 共有のマウントが失敗する可能性があることも示されています。(Microsoft Learn) AKS 上で Azure Files やファイル共有を利用している場合は、FIPS 有効化前に実際のマウント、読み書き、再起動後の復旧まで確認してください。
REST API 利用者向けのチェックリスト
Azure REST API で AKS を作成・更新している場合は、次の順序で確認すると安全です。
現在の API バージョンを確認する
まず、CI/CD や自動化スクリプトで使っている api-version を確認します。2026-03-02-preview を使っていない場合、今回の enableFIPS はまだリクエストやレスポンスに現れない可能性があります。
grep -R "Microsoft.ContainerService/managedClusters" ./infra
grep -R "api-version" ./scripts
grep -R "enableFIPS\|enableFips" ./infra ./scriptsテンプレート内の FIPS 設定を二重に確認する
ARM テンプレートや Bicep では、次の 2 箇所を分けて確認します。
properties.enableFIPS
properties.agentPoolProfiles[].enableFIPScluster-level FIPS を入れる場合は、ノードプール単位の FIPS 設定も必ずセットで確認してください。
監査ルールを更新する
Azure Policy、独自の構成監査、GitHub Actions、Azure DevOps Pipeline などで AKS のセキュリティ設定をチェックしている場合は、監査対象をノードプールだけに限定しないようにします。
確認ロジックの例は次のようになります。
- properties.enableFIPS が true か
- agentPoolProfiles の全要素で enableFIPS が true か
- 新規ノードプール追加時にも enableFIPS が true になっているか
- 非 FIPS ノードプールを許可する例外条件が明文化されているかいま取るべき行動
今回の Azure REST API documentation update は、AKS の FIPS 対応をよりクラスター単位で管理しやすくする重要な変更です。ただし、プレビュー API の追加であり、すべての AKS 環境で即座に本番適用すべき変更ではありません。
まずは、現在の AKS クラスターでノードプール単位の FIPS 状態を確認してください。次に、コンプライアンス要件上、cluster-level FIPS が必要かどうかをセキュリティ担当者や監査担当者と整理します。そのうえで、非本番環境で 2026-03-02-preview の REST API、ARM テンプレート、Bicep、SDK の挙動を検証するのが現実的です。
FIPS 要件がある組織では、今後の安定版 API、Azure CLI、Azure SDK、IaC ツールへの反映を追跡し、AKS の標準構成に properties.enableFIPS と全ノードプールの FIPS 設定を組み込む準備を進めておくとよいでしょう。FIPS 要件がない組織でも、AKS のセキュリティ設定を棚卸しするきっかけとして、現在のテンプレートと監査ルールを確認しておく価値があります。
コメント