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

開始する前に

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

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

1. az extension add コマンドを使用して aks-preview 拡張機能をインストールします。

   az extension add --name aks-preview
   

2. az extension update コマンドを使って拡張機能の最新バージョンに更新します。

   az extension update --name aks-preview
   

PodSecurityPolicyPreview 機能フラグを登録する

1. az feature register コマンドを使用して、PodSecurityPolicyPreview 機能フラグを登録します。

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

   状態が [登録済み] と表示されるまでに数分かかります。

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

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

3. 状態が Registered と表示されたら、az provider register コマンドを使用して Microsoft.ContainerService リソース プロバイダーの登録を最新の情報に更新します。

   az provider register --namespace Microsoft.ContainerService
   

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

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

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

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

1. AKS クラスターを作成します。
2. 独自のポッドのセキュリティ ポリシーを定義する。
3. ポッドのセキュリティ ポリシー機能を有効にする。

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

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

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

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

既定の AKS ポリシー

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

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 によって制御されます。

2. 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 統合を使う場合は、管理者以外のユーザーの資格情報でサインインして、ポリシー適用の動作を確認できます。

1. kubectl create namespace コマンドを使用して、テスト リソース用に psp-aks という名前のサンプル名前空間を作成します。

   kubectl create namespace psp-aks
   

2. kubectl create serviceaccount コマンドを使用して、nonadmin-user という名前のサービス アカウントを作成します。

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

3. kubectl create rolebinding コマンドを使用して、名前空間で基本的な操作を行うために nonadmin-user の RoleBinding を作成します。

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

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

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

1. 通常の管理者ユーザー用の kubectl-admin エイリアス。スコープは psp-aks 名前空間です。
2. 前の手順で作成した 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 セキュリティ ポリシーでは、この要求を拒否する必要があります。

1. 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
   

2. 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 ポッドを特権エスカレーション要求なしで実行してみましょう。

1. 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
   

2. 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 ポッドを実行してみましょう。

1. 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
   

2. 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 や許可されるボリュームなどのその他のオプションは、明示的に制限されません。 この種類のポリシーは特権アクセスの要求を拒否しますが、要求されたポッドの実行をクラスターに許可します。

1. 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:
    - '*'
   

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

   kubectl apply -f psp-deny-privileged.yaml
   

3. 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 を作成します。

1. 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
   

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

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

3. 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
   

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

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

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

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

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

1. nginx-privileged.yaml マニフェスト使って、kubectl apply コマンドを使用してポッドを作成します。

   kubectl-nonadminuser apply -f nginx-unprivileged.yaml
   

2. kubectl get pods コマンドを使用して、ポッドの状態を確認します。

   kubectl-nonadminuser get pods
   

   次の出力例は、ポッドが正常にスケジュールされ、Running であることを示しています。

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

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

   kubectl-nonadminuser delete -f nginx-unprivileged.yaml
   

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

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

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

2. kubectl delete コマンドを使用して、ClusterRole と ClusterRoleBinding を削除します。

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

3. kubectl delete コマンドを使用して、ClusterRoleBinding を削除します。

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

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

   kubectl delete -f psp-deny-privileged.yaml
   

5. kubectl delete コマンドを使用して psp-aks 名前空間を削除します。

   kubectl delete namespace psp-aks
   

次のステップ

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

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