このページでは、Google Kubernetes Engine の PodSecurityPolicy を使用する方法について説明します。
概要
PodSecurityPolicy は、クラスタ上で Pod を作成および更新するリクエストを検証するために作成するアドミッション コントローラ リソースです。PodSecurityPolicy は、クラスタに受け入れられるためにポッドが満たす必要がある一連の条件を定義します。ポッドの作成または更新のリクエストが PodSecurityPolicy の条件を満たさない場合、そのリクエストは拒否され、エラーが返されます。
PodSecurityPolicy を使用するには、新規ポッドおよび更新されたポッドが満たさなければならないポリシーをまず作成して定義する必要があります。次に、定義されたポリシーに従ってポッドの作成リクエストおよび更新リクエストを検証する PodSecurityPolicy アドミッション コントローラを有効にする必要があります。
複数の PodSecurityPolicy が使用可能な場合、アドミッション コントローラは、検証に成功した最初のポリシーを使用します。ポリシーはアルファベット順に並べられ、コントローラは、変更ポリシーよりも非変更ポリシー(ポッドを変更しないポリシー)を優先します。
PodSecurityPolicy は、Kubernetes バージョン 1.8.6 以降を実行する GKE クラスタで使用できます。
始める前に
作業を始める前に、次のことを確認してください。
- Google Kubernetes Engine API が有効になっていることを確認します。 Google Kubernetes Engine API を有効にする
- Cloud SDK がインストール済みであることを確認します。
次のいずれかの方法で gcloud
のデフォルトの設定を指定します。
gcloud init
。デフォルトの設定全般を確認する場合に使用します。gcloud config
。プロジェクト ID、ゾーン、リージョンを個別に設定する場合に使用します。
gcloud init の使用
エラー One of [--zone, --region] must be supplied: Please specify
location
を受信した場合は、このセクションの内容を実施します。
-
gcloud init
を実行して、次の操作を行います。gcloud init
リモート サーバーで SSH を使用している場合は、
--console-only
フラグを指定して、コマンドがブラウザを起動しないようにします。gcloud init --console-only
- 手順に従って
gcloud
を承認し、Google Cloud アカウントを使用します。 - 新しい構成を作成するか、既存の構成を選択します。
- Google Cloud プロジェクトを選択します。
- ゾーンクラスタの場合はデフォルトの Compute Engine ゾーン、リージョン クラスタまたは Autopilot クラスタの場合はデフォルトの Compute Engine リージョンを選択します。
gcloud config の使用
- デフォルトのプロジェクト ID を設定します。
gcloud config set project PROJECT_ID
- ゾーンクラスタを使用する場合は、デフォルトのコンピューティング ゾーンを設定します。
gcloud config set compute/zone COMPUTE_ZONE
- Autopilot クラスタまたはリージョン クラスタを使用する場合は、デフォルトのコンピューティング リージョンを設定します。
gcloud config set compute/region COMPUTE_REGION
gcloud
を最新バージョンに更新します。gcloud components update
- GKE でロールベースのアクセス制御を使用する方法を理解しておいてください。
PodSecurityPolicy の定義
PodSecurityPolicy コントローラがポッドを検証してクラスタ内に受け入れるには、その前に PodSecurityPolicy リソースをクラスタ内で定義する必要があります。
PodSecurityPolicy は、そのポリシー下で作成される Pod の制限、要件、およびデフォルト値のリストを指定します。例として、特権コンテナ、hostPath
Volume、およびホスト ネットワーキングの使用を制限すること、または、すべてのコンテナをデフォルトで seccomp プロファイルにより実行することが挙げられます。PodSecurityPolicy アドミッション コントローラは、利用可能な PodSecurityPolicy に従って、リクエストを検証します。
次の PodSecurityPolicy の my-psp.yaml
の例では、単に特権 Pod が作成されないようにします。また、このポリシーは、使用可能なすべてのボリュームへのアクセスを許可するなど、制御に関して他のいくつかの側面にも影響します。
apiVersion: policy/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 とその制御の側面については、PodSecurityPolicy とはと Kubernetes のドキュメントの中のポリシーのリファレンスをご覧ください。
このリソースは、kubectl
コマンドライン ツールを使用して作成します。
kubectl apply -f my-psp.yaml
PodSecurityPolicy の構成例については、Kubernetes ドキュメントの PodSecurityPolicy のページにある例を参照してください。
ポリシーの承認
cluster-admin ロールを持つアカウントは、ロールベースのアクセス制御を使用して、目的のサービス アカウントに PodSecurityPolicy へのアクセス権を付与する Role または ClusterRole を作成できます。ClusterRole はクラスタ全体にわたる権限を付与し、ロールは自分が定義する Namespace 内で権限を付与します。
たとえば、以下の ClusterRole my-clusterrole.yaml
は、verb: use
で示されているように、my-psp
という PodSecurityPolicy へのアクセスを付与します。
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: my-clusterrole
rules:
- apiGroups:
- policy
resources:
- podsecuritypolicies
verbs:
- use
resourceNames:
- my-psp
次のコマンドを実行して ClusterRole を作成します。
kubectl apply -f my-clusterrole.yaml
Role(または ClusterRole)を作成した後、RoleBinding(または ClusterRoleBinding)リソースを作成することにより、目的のサービス アカウントに関連付けます。
次の RoleBinding、my-rolebinding.yaml
は、ClusterRole my-clusterrole
を、特定の Namespace 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
です。これは、Namespace 内のデフォルトのサービス アカウントを指定するものです。
次のコマンドを実行して 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 の対象となる Pod がある場合は、PodSecurityPolicy を使用する権限を持つ RBAC Role または ClusterRole を作成します。その後、役割または ClusterRole をポッドのサービス アカウントにバインドします。この場合、ユーザー アカウントに権限を付与するだけでは不十分です。詳細については、ポリシーの承認をご覧ください。