プレビュー - Azure Kubernetes Service (AKS) でポッド セキュリティ ポリシーを使用してクラスターのセキュリティを保護する

警告

このドキュメントで説明されている機能、ポッド セキュリティ ポリシー (プレビュー) は、Kubernetes バージョン 1.21 で非推奨となり、バージョン1.25 で削除されます。 Kubernetes Upstream がそのマイルストーンに近づくにつれ、Kubernetes コミュニティは実行可能な代替手段を文書化していきます。 前回の非推奨の発表は、お客様にとって実行可能な選択肢がなかった時点で行われました。 現在、Kubernetes コミュニティが代替手段に取り組んでいるため、Kubernetes の前に非推奨とする緊急の必要性がなくなりました。

ポッド セキュリティ ポリシー (プレビュー) が非推奨となった後、今後のクラスター アップグレードを実行し、Azure サポート内に留まるには、非推奨の機能を使用する既存のクラスターでその機能を無効にする必要があります。

AKS クラスターのセキュリティを向上させるには、どのポッドをスケジュールできるかを制限することができます。 許可しないリソースを要求するポッドは、AKS クラスターで実行できません。 ポッド セキュリティ ポリシーを使用してこのアクセスを定義します。 この記事では、ポッド セキュリティ ポリシーを使用して AKS でのポッドのデプロイを制限する方法について説明します。

重要

AKS のプレビュー機能は、セルフサービスのオプトイン単位で利用できます。 プレビューは、"現状有姿のまま" および "利用可能な限度" で提供され、サービス レベル アグリーメントおよび限定保証から除外されるものとします。 AKS プレビューは、ベストエフォート ベースでカスタマー サポートによって部分的にカバーされます。 そのため、これらの機能は、運用環境での使用を意図していません。 詳細については、次のサポート記事を参照してください。

開始する前に

この記事は、AKS クラスターがすでに存在していることを前提としています。 AKS クラスターが必要な場合は、Azure CLI を使用した場合または Azure portal を使用した場合の AKS のクイックスタートを参照してください。

Azure CLI バージョン 2.0.61 以降がインストールされて構成されている必要があります。 バージョンを確認するには、az --version を実行します。 インストールまたはアップグレードする必要がある場合は、Azure CLI のインストールに関するページを参照してください。

aks-preview CLI 拡張機能をインストールする

ポッド セキュリティ ポリシーを使用するには、aks-preview CLI 拡張機能のバージョン 0.4.1 以降が必要です。 az extension add コマンドを使用して aks-preview Azure CLI 拡張機能をインストールし、az extension update コマンドを使用して使用可能な更新プログラムがあるかどうかを確認します。

# Install the aks-preview extension
az extension add --name aks-preview

# Update the extension to make sure you have the latest version installed
az extension update --name aks-preview

ポッド セキュリティ ポリシー機能プロバイダーを登録する

このドキュメントと機能は、2020 年 10 月 15 日に非推奨となる予定です。

ポッド セキュリティ ポリシーを使用するために AKS クラスターを作成または更新するには、まず自分のサブスクリプションで機能フラグを有効にします。 PodSecurityPolicyPreview 機能フラグを登録するには、次の例に示すように az feature register コマンドを使用します。

az feature register --name PodSecurityPolicyPreview --namespace Microsoft.ContainerService

状態が [登録済み] と表示されるまでに数分かかります。 登録状態を確認するには、az feature list コマンドを使用します。

az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/PodSecurityPolicyPreview')].{Name:name,State:properties.state}"

準備ができたら、az provider register コマンドを使用して、Microsoft.ContainerService リソース プロバイダーの登録を更新します。

az provider register --namespace Microsoft.ContainerService

ポッド セキュリティ ポリシーの概要

Kubernetes クラスターでは、リソースが作成されるときに API サーバーへの要求をインターセプトするためにアドミッション コントローラーが使用されます。 次にアドミッション コントローラーは、一連のルールに対してリソース要求を 検証 したり、デプロイ パラメーターを変更するようにリソースを 変化 させたりすることができます。

PodSecurityPolicy は、ポッド仕様が定義されている要件を満たしていることを検証するアドミッション コント ローラーです。 これらの要件により、特権コンテナーの使用、特定の種類のストレージへのアクセス、またはコンテナーを実行できるユーザーやグループが制限される可能性があります。 ポッド セキュリティ ポリシーに概説されている要件をポッド仕様が満たしていない場合にリソースをデプロイしようとすると、要求は拒否されます。 AKS クラスターにどのポッドをスケジュールできるかを制御するこの機能により、いくつかの潜在的なセキュリティの脆弱性や特権エスカレーションを防ぐことができます。

AKS クラスターでポッド セキュリティ ポリシーを有効にすると、いくつかの既定のポリシーが適用されます。 これらの既定のポリシーには、どのようなポッドをスケジュールできるかを定義するための、すぐに使えるエクスペリエンスが用意されています。 ただし、独自のポリシーを定義するまでは、クラスター ユーザーはポッドのデプロイで問題に遭遇する可能性があります。 推奨される方法:

  • AKS クラスターを作成する
  • 独自のポッド セキュリティ ポリシーを定義する
  • ポッド セキュリティ ポリシー機能を有効にする

既定のポリシーでポッドのデプロイがどのように制限されるかを示すために、この記事では、最初にポッド セキュリティ ポリシー機能を有効にしてから、カスタム ポリシーを作成します。

ポッドのセキュリティ ポリシーと Azure Policy の動作変更

ポッドのセキュリティポリシーと Azure Policy の動作変更の概要を次に示します。

シナリオ ポッドのセキュリティ ポリシー Azure Policy
インストール ポッドのセキュリティ ポリシー機能を有効にします Azure Policy アドオンを有効にします
ポリシーのデプロイ ポッドのセキュリティ ポリシーのリソースをデプロイします サブスクリプションまたはリソース グループのスコープに Azure Policy を割り当てます。 Kubernetes リソース アプリケーションには Azure Policy アドオンが必要です。
既定のポリシー AKS でポッドのセキュリティ ポリシーが有効になっている場合、既定の特権ポリシーおよび無制限のポリシーが適用されます。 Azure Policy アドオンを有効にしても、既定のポリシーは適用されません。 Azure Policy では、ポリシーを明示的に有効にする必要があります。
ポリシーの作成と割り当てが可能なユーザー クラスター管理者がポッドのセキュリティ ポリシー リソースを作成します。 ユーザーには、少なくとも AKS クラスター リソース グループに対する "所有者" または "リソース ポリシーの共同作成者" 権限を含むロールが必要です。 - ユーザーは、API を通じて、AKS クラスター リソース スコープでポリシーを割り当てることができます。 ユーザーには、少なくとも AKS クラスター リソースに対する "所有者" または "リソース ポリシーの共同作成者" 権限が必要です。 - Azure portal では、ポリシーを管理グループ、サブスクリプション、またはリソース グループ レベルで割り当てることができます。
ポリシーの承認 ユーザーおよびサービス アカウントには、ポッドのセキュリティ ポリシーを使用するための明示的な権限が必要です。 ポリシーを承認するために、追加の割り当ては必要ありません。 Azure でポリシーが割り当てられると、すべてのクラスター ユーザーがこれらのポリシーを使用できるようになります。
ポリシーの適用性 管理者ユーザーは、ポッド セキュリティ ポリシーの適用をバイパスします。 すべてのユーザー (管理者および管理者以外) は同じポリシーを認識します。 ユーザーに基づく特殊な文字種はありません。 ポリシーの適用は、名前空間レベルで除外できます。
ポリシーのスコープ ポッドのセキュリティ ポリシーには、名前空間が指定されていません。 Azure Policy によって使用される制約テンプレートには、名前空間が指定されていません。
拒否/監査/変異アクション ポッドのセキュリティ ポリシーでは、拒否アクションのみがサポートされます。 作成要求では、既定値を使用して変異を実行できます。 更新要求中に検証を行うことができます。 Azure Policy では、監査アクションと拒否アクションの両方がサポートされています。 変異はまだサポートされていませんが、計画中です。
ポッドのセキュリティ ポリシーへの準拠 ポッドのセキュリティ ポリシーを有効にする前に存在していたポッドが、それに準拠しているかどうかを可視化することはできません。 ポッドのセキュリティ ポリシーを有効にした後に作成された非準拠ポッドは拒否されます。 Azure ポリシーを適用する前に存在していた非準拠ポッドは、ポリシー違反として表示されます。 ポリシーに deny 効果が設定されている場合、Azure ポリシーを有効にした後に作成された非準拠ポッドは拒否されます。
クラスターでポリシーを表示する方法 kubectl get psp kubectl get constrainttemplate - すべてのポリシーが返されます。
ポッドのセキュリティ ポリシーの標準 - 特権 この機能を有効にすると、特権ポッド セキュリティ ポリシー リソースが既定で作成されます。 特権モードは、制限がないことを意味します。したがって、Azure Policy が割り当てられていないことと同じです。
ポッドのセキュリティ ポリシーの標準 - ベースライン/既定 ユーザーは、ポッドのセキュリティ ポリシーのベースライン リソースをインストールします。 Azure Policy には、ベースライン ポッド セキュリティ ポリシーにマップされる組み込みベースライン イニシアチブが用意されています。
ポッドのセキュリティ ポリシーの標準 - 制限付き ユーザーは、ポッドのセキュリティ ポリシーの制限付きリソースをインストールします。 Azure Policy には、制限付きポッド セキュリティ ポリシーにマップされる組み込みの制限付きイニシアチブが用意されています。

AKS クラスターでポッド セキュリティ ポリシーを有効にする

az aks update コマンドを使用して、ポッド セキュリティ ポリシーを有効または無効にすることができます。 次の例は、myResourceGroup という名前のリソース グループ内のクラスター名 myAKSCluster に対してポッド セキュリティ ポリシーを有効にします。

注意

実際の使用では、独自のカスタム ポリシーを定義するまではポッド セキュリティ ポリシーを有効にしないでください。 この記事では、既定のポリシーでポッドのデプロイがどのように制限されるかを確認するために、最初の手順としてポッド セキュリティ ポリシーを有効にします。

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --enable-pod-security-policy

既定の AKS ポリシー

ポッド セキュリティ ポリシーを有効にすると、AKS によって、privileged という名前の既定ポリシーが 1 つ作成されます。 既定のポリシーを編集または削除しないでください。 代わりに、自分が制御したい設定を定義する、独自のポリシーを作成します。 最初に、これらの既定のポリシーがどのようなものか、そしてそれらがどのようにポッドのデプロイに影響を与えるかについて見てみましょう。

使用可能なポリシーを表示するには、次の例に示すように kubectl get psp コマンドを使用します。

$ kubectl get psp

NAME         PRIV    CAPS   SELINUX    RUNASUSER          FSGROUP     SUPGROUP    READONLYROOTFS   VOLUMES
privileged   true    *      RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *     configMap,emptyDir,projected,secret,downwardAPI,persistentVolumeClaim

privileged ポッド セキュリティ ポリシーは、AKS クラスター内のすべての認証済みユーザーに適用されます。 この割り当ては、ClusterRole と ClusterRoleBinding によって制御されます。 kubectl get clusterrolebindings コマンドを使用して、kube-system 名前空間で default:privileged: バインドを検索します。

kubectl get rolebindings default:privileged -n kube-system -o yaml

次の縮約された出力に示されているように、psp:privileged ClusterRole は、すべての system:authenticated ユーザーに割り当てられます。 この機能により、独自のポリシーが定義されていなくても基本レベルの特権が提供されます。

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  [...]
  name: default:privileged
  [...]
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: psp:privileged
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:masters

独自のセキュリティ ポリシーの作成を開始する前に、これらの既定のポリシーがポッドをスケジュールするためにどのようにユーザー要求に作用するかを理解することが重要です。 次のいくつかのセクションでは、これらの既定のポリシーの動作を確認するために、いくつかポッドをスケジュールしてみましょう。

AKS クラスターでテスト ユーザーを作成する

既定により、az aks get-credentials コマンドを使用すると、AKS クラスターの "管理者" 資格情報が kubectl config. に追加されます。管理者ユーザーは、ポッド セキュリティ ポリシーの適用をバイパスします。 AKS クラスターに Azure Active Directory 統合を使用する場合は、管理者以外のユーザーの資格情報でサインインして、ポリシーの適用の動作を確認することができます。 この記事では、自分が使用できる AKS クラスターにテスト ユーザー アカウントを作成しましょう。

kubectl create namespace コマンドを使用して、テスト リソース用に psp-aks という名前のサンプル名前空間を作成します。 そして、kubectl create serviceaccount コマンドを使用して、nonadmin-user という名前のサービス アカウントを作成します。

kubectl create namespace psp-aks
kubectl create serviceaccount --namespace psp-aks nonadmin-user

次に、kubectl create rolebinding コマンドを使用して、名前空間で基本的な操作を行うために "管理者以外のユーザー" の RoleBinding を作成します。

kubectl create rolebinding \
    --namespace psp-aks \
    psp-aks-editor \
    --clusterrole=edit \
    --serviceaccount=psp-aks:nonadmin-user

管理者と管理者以外のユーザーのエイリアス コマンドを作成する

kubectl を使用する際の通常の管理者ユーザーと、前の手順で作成した管理者以外のユーザーの違いを明らかにするために、次のように 2 つのコマンドライン エイリアスを作成します。

  • kubectl-admin エイリアスは通常の管理者ユーザー用で、スコープは psp-aks 名前空間です。
  • Kubectl nonadminuser エイリアスは、前の手順で作成した 管理者以外のユーザー 用で、スコープは psp aks 名前空間です。

次のコマンドで示すように、これらの 2 つのエイリアスを作成します。

alias kubectl-admin='kubectl --namespace psp-aks'
alias kubectl-nonadminuser='kubectl --as=system:serviceaccount:psp-aks:nonadmin-user --namespace psp-aks'

特権のあるポッドの作成をテストする

まず、privileged: true のセキュリティ コンテキストを持つポッドをスケジュールしたときに何が起こるかをテストしてみましょう。 このセキュリティ コンテキストは、ポッドの特権をエスカレートします。 既定の AKS ポッド セキュリティ ポリシーを示した前のセクションでは、privilege ポリシーがこの要求を拒否するはずです。

nginx-privileged.yaml という名前のファイルを作成し、次の YAML マニフェストを貼り付けます。

apiVersion: v1
kind: Pod
metadata:
  name: nginx-privileged
spec:
  containers:
    - name: nginx-privileged
      image: mcr.microsoft.com/oss/nginx/nginx:1.14.2-alpine
      securityContext:
        privileged: true

kubectl apply コマンドを使用してポッドを作成し、YAML マニフェストのファイル名を指定します。

kubectl-nonadminuser apply -f nginx-privileged.yaml

次の出力例に示すように、このポッドはスケジュールできません。

$ kubectl-nonadminuser apply -f nginx-privileged.yaml

Error from server (Forbidden): error when creating "nginx-privileged.yaml": pods "nginx-privileged" is forbidden: unable to validate against any pod security policy: []

ポッドはスケジューリング段階に達しないため、続行する前に削除するリソースはありません。

特権のないポッドの作成をテストする

前の例で、ポッド仕様は特権のエスカレーションを要求しました。 この要求は既定の privilege ポッド セキュリティ ポリシーによって拒否されるため、ポッドはスケジュールできません。 次に、特権エスカレーション要求なしでその同じ NGINX ポッドを実行してみましょう。

nginx-unprivileged.yaml という名前のファイルを作成し、次の YAML マニフェストを貼り付けます。

apiVersion: v1
kind: Pod
metadata:
  name: nginx-unprivileged
spec:
  containers:
    - name: nginx-unprivileged
      image: mcr.microsoft.com/oss/nginx/nginx:1.14.2-alpine

kubectl apply コマンドを使用してポッドを作成し、YAML マニフェストのファイル名を指定します。

kubectl-nonadminuser apply -f nginx-unprivileged.yaml

次の出力例に示すように、このポッドはスケジュールできません。

$ kubectl-nonadminuser apply -f nginx-unprivileged.yaml

Error from server (Forbidden): error when creating "nginx-unprivileged.yaml": pods "nginx-unprivileged" is forbidden: unable to validate against any pod security policy: []

ポッドはスケジューリング段階に達しないため、続行する前に削除するリソースはありません。

特定のユーザー コンテキストでのポッドの作成をテストする

前の例では、コンテナー イメージは、自動的に root を使用して NGINX をポート 80 にバインドしようとしました。 この要求は既定の privilege ポッド セキュリティ ポリシーによって拒否されたため、ポッドは開始できません。 次に、runAsUser: 2000 などの特定のユーザー コンテキストを使用して、その同じ NGINX ポッドを実行してみましょう。

nginx-unprivileged-nonroot.yaml という名前のファイルを作成し、次の YAML マニフェストを貼り付けます。

apiVersion: v1
kind: Pod
metadata:
  name: nginx-unprivileged-nonroot
spec:
  containers:
    - name: nginx-unprivileged
      image: mcr.microsoft.com/oss/nginx/nginx:1.14.2-alpine
      securityContext:
        runAsUser: 2000

kubectl apply コマンドを使用してポッドを作成し、YAML マニフェストのファイル名を指定します。

kubectl-nonadminuser apply -f nginx-unprivileged-nonroot.yaml

次の出力例に示すように、このポッドはスケジュールできません。

$ kubectl-nonadminuser apply -f nginx-unprivileged-nonroot.yaml

Error from server (Forbidden): error when creating "nginx-unprivileged-nonroot.yaml": pods "nginx-unprivileged-nonroot" is forbidden: unable to validate against any pod security policy: []

ポッドはスケジューリング段階に達しないため、続行する前に削除するリソースはありません。

カスタム ポッド セキュリティ ポリシーを作成する

既定のポッド セキュリティ ポリシーのビヘイビアーを確認したので、管理者以外のユーザー が正常にポッドをスケジュールする方法を提供しましょう。

特権アクセスを要求するポッドを拒否するポリシーを作成しましょう。 runAsUser や許可される ボリューム などのその他のオプションは、明示的に制限されません。 この種類のポリシーは特権アクセスの要求を拒否しますが、それ以外の場合は、要求されたポッドをクラスターに実行させます。

psp-deny-privileged.yaml という名前のファイルを作成し、次の YAML マニフェストを貼り付けます。

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: psp-deny-privileged
spec:
  privileged: false
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  volumes:
  - '*'

kubectl apply コマンドを使用してポリシーを作成し、YAML マニフェストのファイル名を指定します。

kubectl apply -f psp-deny-privileged.yaml

使用可能なポリシーを表示するには、次の例に示すように kubectl get psp コマンドを使用します。 psp-deny-privileged ポリシーを、前述のポッドを作成する例で適用されていた既定の privilege ポリシーと比較します。 PRIV エスカレーションの使用のみがポリシーによって拒否されます。 psp-deny-privileged ポリシーには、ユーザーまたはグループの制限はありません。

$ kubectl get psp

NAME                  PRIV    CAPS   SELINUX    RUNASUSER          FSGROUP     SUPGROUP    READONLYROOTFS   VOLUMES
privileged            true    *      RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *
psp-deny-privileged   false          RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *          

ユーザー アカウントでのカスタム ポッド ポリシーの使用を許可する

前の手順では、特権アクセスを要求するポッドを拒否するポッド セキュリティ ポリシーを作成しました。 このポリシーの使用を許可するには、Role または ClusterRole を作成します。 次に、RoleBinding または ClusterRoleBinding を使用してこれらのロールのいずれかを関連付けます。

この例では、前の手順で作成した psp-deny-privileged ポリシーの 使用 を可能にする ClusterRole を作成します。 psp-deny-privileged-clusterrole.yaml という名前のファイルを作成し、次の YAML マニフェストを貼り付けます。

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: psp-deny-privileged-clusterrole
rules:
- apiGroups:
  - extensions
  resources:
  - podsecuritypolicies
  resourceNames:
  - psp-deny-privileged
  verbs:
  - use

kubectl apply コマンドを使用して ClusterRole を作成し、YAML マニフェストのファイル名を指定します。

kubectl apply -f psp-deny-privileged-clusterrole.yaml

次に、前の手順で作成した ClusterRole を使用するために ClusterRoleBinding を作成します。 psp-deny-privileged-clusterrolebinding.yaml という名前のファイルを作成し、次の YAML マニフェストを貼り付けます。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: psp-deny-privileged-clusterrolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: psp-deny-privileged-clusterrole
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:serviceaccounts

kubectl apply コマンドを使用して ClusterRoleBinding を作成し、YAML マニフェストのファイル名を指定します。

kubectl apply -f psp-deny-privileged-clusterrolebinding.yaml

注意

この記事の最初の手順で、ポッド セキュリティ ポリシー機能が AKS クラスターで有効にされました。 推奨プラクティスは、独自のポリシーを定義した後でのみポッド セキュリティ ポリシーを有効にするというものでした。 これが、ポッド セキュリティ ポリシー機能を有効にする段階です。 1 つ以上のカスタム ポリシーが定義されており、ユーザー アカウントがそれらのポリシーに関連付けられています。 これで、ポッド セキュリティ ポリシー機能を安全に有効にして、既定のポリシーによって引き起こされる問題を最小限に抑えることができます。

特権のないポッドの作成をもう一度テストする

カスタム ポッド セキュリティ ポリシーが適用され、そのポリシーを使用するためのユーザー アカウントのバインディングが作成されたので、特権のないポッドをもう一度作成してみましょう。 kubectl apply コマンドを使って、同じ nginx-privileged.yaml マニフェストを使用してポッドを作成します。

kubectl-nonadminuser apply -f nginx-unprivileged.yaml

ポッドが正常にスケジュールされます。 kubectl get pods コマンドを使用してポッドの状態を確認すると、ポッドは Running 状態です。

$ kubectl-nonadminuser get pods

NAME                 READY   STATUS    RESTARTS   AGE
nginx-unprivileged   1/1     Running   0          7m14s

この例は、カスタム ポッド セキュリティ ポリシーを作成して、さまざまなユーザーまたはグループのための AKS クラスターへのアクセス権を定義する方法を示しています。 既定の AKS ポリシーでは、ポッドが実行できることに対して厳格な管理が提供されているので、独自のカスタム ポリシーを作成して、自分に必要な制限を正しく定義します。

kubectl delete コマンドを使用して、特権のない NGINX ポッドを削除し、YAML マニフェストの名前を指定します。

kubectl-nonadminuser delete -f nginx-unprivileged.yaml

リソースをクリーンアップする

ポッド セキュリティ ポリシーを無効にするには、再び az aks update コマンドを使用します。 次の例は、myResourceGroup という名前のリソース グループ内のクラスター名 myAKSCluster でポッド セキュリティ ポリシーを無効にします。

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --disable-pod-security-policy

次に、ClusterRole と ClusterRoleBinding を削除します。

kubectl delete -f psp-deny-privileged-clusterrolebinding.yaml
kubectl delete -f psp-deny-privileged-clusterrole.yaml

kubectl delete コマンドを使用してセキュリティ ポリシーを削除し、YAML マニフェストの名前を指定します。

kubectl delete -f psp-deny-privileged.yaml

最後に、次のように psp-aks 名前空間を削除します。

kubectl delete namespace psp-aks

次のステップ

この記事では、特権アクセスの使用を防止するためのポッド セキュリティ ポリシーを作成する方法を示しました。 ボリュームの種類や RunAs ユーザーなど、ポリシーが適用できるたくさんの機能があります。 利用可能なオプションの詳細については、Kubernetes ポッド セキュリティ ポリシーの参照ドキュメントに関するページを参照してください。

ポッド ネットワーク トラフィックの制限の詳細については、「Azure Kubernetes Service (AKS) のネットワーク ポリシーを使用したポッド間のトラフィックの保護」を参照してください。