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

[アーティクル]
08/04/2024

重要

ポッドセキュリティポリシー機能は、2023 年 8 月 1 日に非推奨となり、AKS バージョン 1.25 以降から削除されました。

Azure のサポートを維持できるように、ポッドセキュリティアドミッションコントローラーまたは Azure ポリシーに移行することをお勧めします。ポッドセキュリティアドミッションは、単一クラスター実装用の組み込みポリシーソリューションです。エンタープライズレベルのポリシーをお探しの場合は、Azure ポリシーの方が適しています。

開始する前に

この記事は、AKS クラスターがすでに存在していることを前提としています。 AKS クラスターが必要な場合は、Azure CLI、Azure PowerShell、または Azure portal を使用して作成します。
Azure CLI バージョン 2.0.61 以降がインストールされて構成されている必要があります。バージョンを確認するには、az --version を実行します。インストールまたはアップグレードする必要がある場合は、「Azure CLI のインストール」を参照してください。

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

重要

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

az extension add コマンドを使用して aks-preview 拡張機能をインストールします。
```
az extension add --name aks-preview
```
az extension update コマンドを使って拡張機能の最新バージョンに更新します。
```
az extension update --name aks-preview
```

`PodSecurityPolicyPreview` 機能フラグを登録する

az feature register コマンドを使用して、PodSecurityPolicyPreview 機能フラグを登録します。
```
az feature register --namespace "Microsoft.ContainerService" --name "PodSecurityPolicyPreview"
```
状態が [登録済み] と表示されるまでに数分かかります。

az feature show コマンドを使用して、登録の状態を確認します。

az feature show --namespace "Microsoft.ContainerService" --name "PodSecurityPolicyPreview"

状態が Registered と表示されたら、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 を割り当てます。 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 クラスターでポッドセキュリティポリシーを有効にする

Note

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

az aks update コマンドを使用してポッドのセキュリティポリシーを有効にします。

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 クラスター内のすべての認証済みユーザーに適用されます。この割り当ては、ClusterRoles と ClusterRoleBindings によって制御されます。
kubectl get rolebindings コマンドを使用して、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 クラスターに Microsoft Entra 統合を使う場合は、管理者以外のユーザーの資格情報でサインインして、ポリシー適用の動作を確認できます。

kubectl create namespace コマンドを使用して、テストリソース用に psp-aks という名前のサンプル名前空間を作成します。
```
kubectl create namespace psp-aks
```
kubectl create serviceaccount コマンドを使用して、nonadmin-user という名前のサービスアカウントを作成します。
```
kubectl create serviceaccount --namespace psp-aks nonadmin-user
```
kubectl create rolebinding コマンドを使用して、名前空間で基本的な操作を行うために nonadmin-user の RoleBinding を作成します。
```
kubectl create rolebinding \
    --namespace psp-aks \
    psp-aks-editor \
    --clusterrole=edit \
    --serviceaccount=psp-aks:nonadmin-user
```

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

kubectl を使用する場合は、2 つのコマンドラインエイリアスを作成することで、通常の管理者ユーザーと管理者以外のユーザーの違いを明確にすることができます。

通常の管理者ユーザー用の kubectl-admin エイリアス。スコープは psp-aks 名前空間です。
前の手順で作成した nonadmin-user 用の 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 のセキュリティコンテキストを持つポッドをスケジュールすると何が起こるかをテストしてみましょう。このセキュリティコンテキストは、ポッドの特権をエスカレートします。既定の privilege AKS セキュリティポリシーでは、この要求を拒否する必要があります。

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
```
次の出力例は、ポッドをスケジュールできなかったことを示しています。
```
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
```
次の出力例は、ポッドをスケジュールできなかったことを示しています。
```
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
```
次の出力例は、ポッドをスケジュールできなかったことを示しています。
```
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 コマンドを使用して、使用可能なポリシーを表示します。
```
kubectl get psp
```
次の出力例で、psp-deny-privileged ポリシーを、前述のポッドを作成する例で適用されていた既定の privilege ポリシーと比較します。 PRIV エスカレーションの使用のみがポリシーによって拒否されます。 psp-deny-privileged ポリシーには、ユーザーまたはグループの制限はありません。
```
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 ポリシーの use を許可する 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 コマンドを使用し、YAML マニフェストのファイル名を指定して ClusterRole を作成します。
```
kubectl apply -f psp-deny-privileged-clusterrole.yaml
```

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 コマンドを使用し、YAML マニフェストのファイル名を指定して ClusterRoleBinding を作成します。
```
kubectl apply -f psp-deny-privileged-clusterrolebinding.yaml
```

注意

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

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

カスタムポッドセキュリティポリシーが適用され、そのポリシーを使用するためのユーザーアカウントのバインディングが作成されたので、特権のないポッドをもう一度作成してみましょう。

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

nginx-privileged.yaml マニフェスト使って、kubectl apply コマンドを使用してポッドを作成します。
```
kubectl-nonadminuser apply -f nginx-unprivileged.yaml
```
kubectl get pods コマンドを使用して、ポッドの状態を確認します。
```
kubectl-nonadminuser get pods
```
次の出力例は、ポッドが正常にスケジュールされ、Running であることを示しています。
```
NAME                 READY   STATUS    RESTARTS   AGE
nginx-unprivileged   1/1     Running   0          7m14s
```
kubectl delete コマンドを使用し、YAML マニフェストの名前を指定して、特権のない NGINX ポッドを削除します。
```
kubectl-nonadminuser delete -f nginx-unprivileged.yaml
```

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

az aks update コマンドを使用してポッドのセキュリティポリシーを無効にします。

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

kubectl delete コマンドを使用して、ClusterRole と ClusterRoleBinding を削除します。
```
kubectl delete -f psp-deny-privileged-clusterrole.yaml
```
kubectl delete コマンドを使用して、ClusterRoleBinding を削除します。
```
kubectl delete -f psp-deny-privileged-clusterrolebinding.yaml
```
kubectl delete コマンドを使用し、YAML マニフェストの名前を指定して、セキュリティポリシーを削除します。
```
kubectl delete -f psp-deny-privileged.yaml
```
kubectl delete コマンドを使用して psp-aks 名前空間を削除します。
```
kubectl delete namespace psp-aks
```

次のステップ

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

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

次の方法で共有

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

開始する前に

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

`PodSecurityPolicyPreview` 機能フラグを登録する

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

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

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

既定の AKS ポリシー

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

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

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

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

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

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

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

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

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

次のステップ

その他のリソース

次の方法で共有

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

開始する前に

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

PodSecurityPolicyPreview 機能フラグを登録する

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

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

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

既定の AKS ポリシー

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

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

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

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

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

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

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

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

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

次のステップ

その他のリソース

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

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

`PodSecurityPolicyPreview` 機能フラグを登録する

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

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

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

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

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

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

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

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