PodSecurityPolicy の使用

このページでは、Google Kubernetes Engine の PodSecurityPolicy を使用する方法について説明します。

概要

PodSecurityPolicy は、クラスタ上でポッドを作成および更新するリクエストを検証するために作成するアドミッション コントローラ リソースです。PodSecurityPolicy は、クラスタに受け入れられるためにポッドが満たす必要がある一連の条件を定義します。ポッドの作成または更新のリクエストが PodSecurityPolicy の条件を満たさない場合、そのリクエストは拒否され、エラーが返されます。

PodSecurityPolicy を使用するには、新規ポッドおよび更新されたポッドが満たさなければならないポリシーをまず作成して定義する必要があります。次に、定義されたポリシーに従ってポッドの作成リクエストおよび更新リクエストを検証する PodSecurityPolicy アドミッション コントローラを有効にする必要があります。

複数の PodSecurityPolicy が使用可能な場合、アドミッション コントローラは、検証に成功した最初のポリシーを使用します。ポリシーはアルファベット順に並べられ、コントローラは、変更ポリシーよりも非変更ポリシー（ポッドを変更しないポリシー）を優先します。

PodSecurityPolicy は、Kubernetes バージョン 1.8.6 以降を実行する GKE クラスタで使用できます。

始める前に

このタスクの準備として、次の手順を行います。

  • Google Kubernetes Engine API が有効になっていることを確認します。
    • Google Kubernetes Engine API の有効化
  • Cloud SDK がインストール済みであることを確認します。
  • デフォルトのプロジェクト ID を設定します。 
    gcloud config set project [PROJECT_ID]
  • ゾーンクラスタを使用する場合は、デフォルトのコンピューティング ゾーンを設定します。
    gcloud config set compute/zone [COMPUTE_ZONE]
  • リージョン クラスタを使用する場合は、デフォルトのコンピューティング リージョンを設定します。
    gcloud config set compute/region [COMPUTE_REGION]
  • gcloud を最新バージョンに更新します。
    gcloud components update

PodSecurityPolicy の定義

PodSecurityPolicy コントローラがポッドを検証してクラスタ内に受け入れるには、その前に PodSecurityPolicy リソースをクラスタ内で定義する必要があります。

PodSecurityPolicy は、そのポリシー下で作成されるポッドの制限、要件、およびデフォルト値のリストを指定します。例として、特権コンテナ、hostPath ボリューム、およびホスト ネットワーキングの使用を制限すること、または、すべてのコンテナをデフォルトで seccomp プロファイルにより実行することが挙げられます。PodSecurityPolicy アドミッション コントローラは、利用可能な PodSecurityPolicy に従って、リクエストを検証します。

サンプル PodSecurityPolicy として次に示す my-psp.yaml は、単に特権ポッドが作成されないようにします。また、このポリシーは、使用可能なすべてのボリュームへのアクセスを許可するなど、制御に関して他のいくつかの側面にも影響します。

apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
  name: my-psp
spec:
  privileged: false  # Prevents creation of privileged Pods
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  volumes:
  - '*'

PodSecurityPolicy 仕様により、制御の多くの側面のセキュリティを確保できます。制御のさまざまな側面のうちこの例で指定されているもの（seLinux、supplementalGroups、runAsUser、および fsGroup）はすべて RunAsAny に設定されており、それは、これらのフィールドの有効な任意の値をこのポリシーで使用できることを示しています。

PodSecurityPolicy とその制御の側面については、Kubernetes ドキュメントの PodSecurityPolicy とは と、ポリシーのリファレンスをご覧ください。

このリソースは、kubectl コマンドライン ツールを使用して作成します。

kubectl apply -f my-psp.yaml

PodSecurityPolicy の構成例については、Kubernetes ドキュメントの PodSecurityPolicy のページにある例を参照してください。

ポリシーの承認

cluster-admin 役割を持つアカウントは、役割ベースのアクセス制御を使用して、目的のサービス アカウントに PodSecurityPolicy へのアクセス権を付与する Role または ClusterRole を作成できます。ClusterRole はクラスタ全体にわたる権限を付与し、Role は自分が定義する名前空間内で権限を付与します。

たとえば、ClusterRole である次の my-clusterrole.yaml は、verb: use で示されているように、my-psp という PodSecurityPolicy へのアクセス権を付与します。

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

次のコマンドを実行して ClusterRole を作成します。

kubectl apply -f my-clusterrole.yaml

Role（または ClusterRole）を作成した後、RoleBinding（または ClusterRoleBinding）リソースを作成することにより、目的のサービス アカウントに関連付けます。

次の RoleBinding、my-rolebinding.yaml は、ClusterRole my-clusterrole を、特定の名前空間 my-namespace のサービス アカウントにバインドします。

# Bind the ClusterRole to the desired set of service accounts.
# Policies should typically be bound to service accounts in a namespace.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: my-rolebinding
  namespace: my-namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: my-clusterrole
subjects:
# Example: All service accounts in my-namespace
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:serviceaccounts
# Example: A specific service account in my-namespace
- kind: ServiceAccount # Omit apiGroup
  name: default
  namespace: my-namespace

この RoleBinding において、

  • subjects フィールドは、ClusterRole がどのアカウントにバインドされるかを指定します。
  • 最初のサブジェクトは Group である system:serviceaccounts です。これは、クラスタ内のすべてのサービス アカウントを含むものです。
  • 2 番目のサブジェクトは個別の ServiceAccount である default です。これは、ネームスペース内のデフォルトのサービス アカウントを指定するものです。

次のコマンドを実行して RoleBinding を作成します。

kubectl apply -f my-rolebinding.yaml

RBAC の詳細については、RBAC 認証の使用を参照してください。

PodSecurityPolicy コントローラを有効にする

PodSecurityPolicy アドミッション コントローラを使用するには、新しいクラスタを作成するか、--enable-pod-security-policy フラグを使用して既存のクラスタを更新する必要があります。

PodSecurityPolicy を使用して新しいクラスタを作成するには、次のコマンドを実行します。

gcloud beta container clusters create [CLUSTER_NAME] --enable-pod-security-policy

既存のクラスタを更新するには、次のコマンドを実行します。

gcloud beta container clusters update [CLUSTER_NAME] --enable-pod-security-policy

PodSecurityPolicy コントローラを無効にする

PodSecurityPolicy コントローラを無効にするには、次のコマンドを実行します。

gcloud beta container clusters update [CLUSTER_NAME] --no-enable-pod-security-policy

コントローラを無効にすると、クラスタは既存のポリシーの検証とデフォルト設定を停止しますが、削除するわけではありません。バインディングも削除されません。

NetworkPolicy に関する処理

NetworkPolicy を使用していて、PodSecurityPolicy の対象となるポッドがある場合は、PodSecurityPolicy を使用する権限を持つ RBAC 役割または ClusterRole を作成します。その後、役割または ClusterRole をポッドのサービス アカウントにバインドします。この場合、ユーザー アカウントに権限を付与するだけでは不十分です。詳細については、ポリシーの承認をご覧ください。

次のステップ