Kubernetesエンジン(OKE)でのポッド・セキュリティ・ポリシーの使用
Kubernetes Engine (OKE)を使用して作成したKubernetesクラスタでポッド・セキュリティ・ポリシーを使用する方法をご紹介します。
アップストリームKubernetesプロジェクトは、Kubernetesバージョン1.21でポッド・セキュリティ・ポリシーを非推奨にし、Kubernetesバージョン1.25で機能を削除しました。したがって、Kubernetesエンジンは、Kubernetesバージョン1.25以降を実行しているクラスタでポッド・セキュリティ・ポリシーおよびPodSecurityPolicyアドミッション・コントローラをサポートしていません。
同様の機能が必要な場合は、かわりにKubernetesポッド・セキュリティ標準およびPodSecurityアドミッション・コントローラ(特権ポリシー、ベースライン・ポリシーおよび制限ポリシーとともに)の使用を検討してください。デフォルトでは、Kubernetes Engineは、ポッド・セキュリティ標準をサポートするために、Kubernetesバージョン1.23以降を実行しているクラスタでPodSecurityアドミッション・コントローラを有効にします。Kubernetesポッド・セキュリティ標準およびPodSecurity入場コントローラの詳細は、Kubernetesドキュメントのポッド・セキュリティ標準を参照してください。
または、Kubernetesエコシステムで開発されている他の代替手段を使用してポリシーを適用することを検討してください。
ポッド・セキュリティ・ポリシーおよびPodSecurityPolicyアドミッション・コントローラの使用からポッド・セキュリティ標準およびPodSecurityアドミッション・コントローラの使用に移行する場合は、KubernetesドキュメントのPodSecurityPolicyから組込みPodSecurityアドミッション・コントローラへの移行を参照してください。Kubernetesバージョン1.25を実行している新しいクラスタを作成する前に、またはKubernetesバージョン1.25を実行するために既存のKubernetesバージョン1.24クラスタをアップグレードする前に、移行を完了することが重要です。また、コンソールには、Kubernetesエンジンによって作成および管理される既存のKubernetesクラスタでのPodSecurityPolicyアドミッション・コントローラの使用を無効にする便利な方法があります(コンソールを使用したPodSecurityPolicyアドミッション・コントローラの無効化を参照)。
クラスタのポッド・セキュリティ・ポリシーを設定して、Kubernetesエンジンで作成したクラスタでポッドが実行できる操作を制御できます。ポッド・セキュリティ・ポリシーは、セキュリティ関連の条件を満たしてからポッドがクラスタに受け入れられるようにする手段です。たとえば、ポッド・セキュリティ・ポリシーを使用して次のことを実行できます:
- ポッドに使用可能なストレージの選択肢の制限
- ポッドがアクセスできるホストのネットワークとポートの制限
- ポッドがルート・ユーザーとして実行されることの防止
- 特権モードでのポッドの実行の防止
また、ポッドの変更によってポッドのデフォルト値を提供するようにポッド・セキュリティ・ポリシーを使用することもできます。
クラスタにポッド・セキュリティ・ポリシーを定義したら、ポリシーを使用するためにリクエスト・ユーザーまたはターゲット・ポッドのサービス・アカウントを認可する必要があります。これを行うには、ロール(またはclusterrole)を作成してポッド・セキュリティ・ポリシーにアクセスし、ロール(またはclusterrole)とリクエスト・ユーザーかターゲット・ポッドのサービス・アカウントの間にロール・バインディング(またはclusterrolebinding)を作成します。ロール、clusterroleおよびバインディングの詳細は、アクセス制御とKubernetesエンジン(OKE)についてを参照してください。
クラスタでクラスタに定義されたポッド・セキュリティ・ポリシーを実施するかどうかは、クラスタのPodSecurityPolicyアドミッション・コントローラを有効にすることで指定します。PodSecurityPolicyアドミッション・コントローラはポッドの作成と変更を操作し、ポッド仕様でリクエストされたセキュリティ・コンテキストとクラスタのポッド・セキュリティ・ポリシーに基づいて、ポッドをクラスタに許可するかどうかを決定します。複数のポッド・セキュリティ・ポリシーが存在する場合、PodSecurityPolicyアドミッション・コントローラはまずポッドと変化しないポリシーをアルファベット順に比較し、次にポッドを正常に検証した最初のポリシーを使用します。変化しないポッドがポッドを検証しない場合、PodSecurityPolicyアドミッション・コントローラはまずポッドと変化するポリシーをアルファベット順に比較し、次にポッドを正常に検証した最初のポリシーを使用します。
注意1:
クラスタのPodSecurityPolicyアドミッション・コントローラを有効にする場合、ポリシーにポッドを関連付けるために適切なポッド・セキュリティ・ポリシーがロール(またはclusterrole)およびロール・バインディング(またはclusterrolebinding)とともに存在する場合を除いて、クラスタ上でアプリケーション・ポッドが開始できないことに注意することが非常に重要です。これらの前提条件が満たされないかぎり、PodSecurityPolicyアドミッション・コントローラが有効なクラスタでアプリケーション・ポッドを実行することはできません。
次のようにPodSecurityPolicyアドミッション・コントローラを使用することを強くお薦めします:
- 新しいクラスタを作成するたびに、ポッド・セキュリティ・アドミッション・コントローラを有効にします。
- 新しいクラスタを作成したら、ただちにロール(またはclusterrole)およびロール・バインディング(またはclusterrolebinding)とともにポッド・セキュリティ・ポリシーを作成します。
注意2:
すでに本番環境にある既存のクラスタのPodSecurityPolicyアドミッション・コントローラを有効にする前(つまり、作成後しばらくの間)に、ポッド・セキュリティ・ポリシーを作成する必要があります。既存のクラスタのPodSecurityPolicyアドミッション・コントローラを有効にする場合は、まず開発環境またはテスト環境でクラスタのポッド・セキュリティ・ポリシーを検証することを強くお薦めします。これにより、ポッドのセキュリティ・ポリシーが期待どおりに機能し、クラスタ上でのポッドの開始を正しく許可(または拒否)できます。
Kubernetes Engineで作成したクラスタのPodSecurityPolicyアドミッション・コントローラを有効にすると、Kubernetesシステム権限ポッドのポッド・セキュリティ・ポリシーが(関連付けられたclusterroleおよびclusterrolebindingとともに)自動的に作成されます。このポッド・セキュリティ・ポリシーとclusterroleおよびclusterrolebindingにより、Kubernetesシステム・ポッドを実行できます。ポッド・セキュリティ・ポリシー、clusterroleおよびclusterrolebindingは、kube-system.yamlファイル(kube-system.yamlリファレンスを参照)で定義されます。
クラスタのPodSecurityPolicyアドミッション・コントローラを有効にする前に、クラスタのポッド・セキュリティ・ポリシーを作成できることに注意してください。また、以前に有効化されたクラスタのPodSecurityPolicyアドミッション・コントローラを無効化することもできます。この場合、以前に作成したポップ・セキュリティ・ポリシー、ロール(またはclusterrole)およびロール・バインディング(またはclusterrolebinding)はいずれも削除されません。ポッド・セキュリティ・ポリシーが実施されるだけではありません。すべてのアプリケーション・ポッドがクラスタ上で実行できるようになります。
ポッド・セキュリティ・ポリシーおよびPodSecurityPolicyアドミッション・コントローラの詳細は、Kubernetesのドキュメントを参照してください。
アプリケーション・ポッドのポッド・セキュリティ・ポリシーの作成
アプリケーション・ポッドのポッド・セキュリティ・ポリシーを作成するには、ポッド・セキュリティ・ポリシーにアクセスするロールを作成し、アプリケーション・ポッドがポッド・セキュリティ・ポリシーを使用できるようにロール・バインディングを作成します:
- アプリケーション・ポッドのポッド・セキュリティ・ポリシーを作成します:
ポッド・セキュリティ・ポリシーを定義してファイルに保存します。たとえば、
acme-app-psp.yaml
です。たとえば、このポリシー(Kubernetesドキュメントを参照)によって特権ポッドが作成されないようにします:
apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: acme-app-psp spec: privileged: false # Don't allow privileged pods! # The rest fills in some required fields. seLinux: rule: RunAsAny supplementalGroups: rule: RunAsAny runAsUser: rule: RunAsAny fsGroup: rule: RunAsAny volumes: - '*'
次のコマンドを入力して、ポッド・セキュリティ・ポリシーを作成します:
kubectl create -f <filename>.yaml
例:
kubectl create -f acme-app-psp.yaml
- ポッド・セキュリティ・ポリシーにアクセスするためのロール(またはclusterrole)を作成します:
ロール(またはclusterrole)を定義してファイルに保存します。たとえば、
acme-app-psp-crole.yaml
です。例:
# Cluster role which grants access to the app pod security policy apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: acme-app-psp-crole rules: - apiGroups: - policy resourceNames: - acme-app-psp resources: - podsecuritypolicies verbs: - use
ロール(またはclusterrole)を作成するには、次のコマンドを入力します:
kubectl create -f <filename>.yaml
例:
kubectl create -f acme-app-psp-crole.yaml
- ポッド・セキュリティ・ポリシーを使用するアプリケーション・ポッドを認可するロール・バインディング(またはclusterrolebinding)を作成します:
ロール・バインディング(またはclusterrolebinding)を定義し、ファイルに保存します。たとえば、
acme-app-psp-crole-bind.yaml
です。例:
# Role binding which grants access to the app pod security policy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: acme-app-psp-binding namespace: acme-namespace roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: acme-app-psp-crole subjects: # For all service accounts in acme-namespace - apiGroup: rbac.authorization.k8s.io kind: Group name: system:serviceaccounts:acme-namespace
ロール(またはclusterrolebinding)を作成するには、次のコマンドを入力します:
kubectl create -f <filename>.yaml
例:
kubectl create -f acme-app-psp-crole-bind.yaml
ロールとロール・バインディング(またはclusterroleとclusterrolebinding)を作成することにより、ポッド・セキュリティ・ポリシーを定義してこれを使用するようにアプリケーション・ポッドを認可したら、クラスタのPodSecurityPolicyアドミッション・コントローラを有効にしてポッド・セキュリティ・ポリシーを適用できます(まだ有効になっていない場合)。
コンソールを使用したPodSecurityPolicyアドミッション・コントローラの有効化
コンソールを使用して新規クラスタを作成する際にPodSecurityPolicyアドミッション・コントローラを有効にするには:
- コンソールにログインします。
-
コンソールを使用した、カスタム作成ワークフローでの明示的に定義された設定によるクラスタの作成の新しいクラスタの作成手順に従って、「拡張オプションの表示」をクリックし、「ポッド・セキュリティ・ポリシー - 実施済」オプションを選択します。このオプションでは、PodSecurityPolicyアドミッション・コントローラが有効になります。
ポリシーにポッドを関連付けるために適切なポッド・セキュリティ・ポリシーがロール(またはclusterrole)およびロール・バインディング(またはclusterrolebindings)とともに存在する場合を除いて、クラスタ上でアプリケーション・ポッドは新規クラスタに対して受け入れられません。
- 手順に従って残りのクラスタ詳細を設定し、「クラスタの作成」をクリックして新しいクラスタを作成します。
-
アプリケーション・ポッドのポッド・セキュリティ・ポリシーの作成の手順に従って、ポッドを新しいクラスタに受け入れるときに適用するPodSecurityPolicyアドミッション・コントローラのポッド・セキュリティ・ポリシーを作成します。
コンソールを使用して既存のクラスタでPodSecurityPolicyアドミッション・コントローラを有効化するには:
-
アプリケーション・ポッドのポッド・セキュリティ・ポリシーの作成の手順に従って、既存のクラスタにポッドを受け入れるときに適用するPodSecurityPolicyアドミッション・コントローラのポッド・セキュリティ・ポリシーを作成します。
まず、開発環境またはテスト環境でポッド・セキュリティ・ポリシーを検証することを強くお薦めします。これにより、ポッドのセキュリティ・ポリシーが期待どおりに機能し、クラスタ上でのポッドの開始を正しく許可(または拒否)できます。
- ナビゲーション・メニューを開き、「開発者サービス」をクリックします。「コンテナとアーティファクト」で、「Kubernetesクラスタ(OKE)」をクリックします。
- 作業する権限があるコンパートメントを選択します。
- 「クラスタ・リスト」ページで、変更するクラスタの名前をクリックします。
- 「クラスタの詳細」タブで、「ポッド・セキュリティ・ポリシー」の横にある「未適用」をクリックします。
-
「ポッド・セキュリティ・ポリシー」ウィンドウで「実施済」を選択します。
今後、ポッドをポリシーに関連付けるために適切なポッド・セキュリティ・ポリシーがロール(またはclusterrole)およびロール・バインディング(またはclusterrolebinding)とともに存在する場合を除いて、新しいアプリケーション・ポッドはクラスタに受け入れられなくなります。現在実行中のすべてのポッドは、引き続き実行されます。
- 「変更の保存」をクリックします。
コンソールを使用したPodSecurityPolicyアクセス・コントローラの無効化
以前に有効化されたクラスタでPodSecurityPolicyアドミッション・コントローラを無効にするには:
- ナビゲーション・メニューを開き、「開発者サービス」をクリックします。「コンテナとアーティファクト」で、「Kubernetesクラスタ(OKE)」をクリックします。
- 作業する権限があるコンパートメントを選択します。
- 「クラスタ・リスト」ページで、変更するクラスタの名前をクリックします。
- 「クラスタ詳細」タブで、「ポッド・セキュリティ・ポリシー」の横にある「強制」をクリックします。
-
「ポッド・セキュリティ・ポリシー」ウィンドウで「未実施」を選択します。
今後、ポッド・セキュリティ・ポリシー、ロール(またはclusterrole)およびロール・バインディング(またはclusterrolebinding)を必要とせずに、新しいアプリケーション・ポッドがクラスタに受け入れられます。現在実行中のすべてのポッドは、引き続き実行されます。
- 「変更の保存」をクリックします。
APIの使用
APIの使用およびリクエストの署名の詳細は、REST APIのドキュメントおよびセキュリティ資格証明を参照してください。SDKの詳細は、SDKおよびCLIを参照してください。
PodSecurityPolicyアドミッション・コントローラを有効にするには、次を使用します:
- 新規クラスタの作成時のCreateCluster操作
- 既存のクラスタを変更時のクラスタの更新操作
kube-system.yamlリファレンス
クラスタのPodSecurityPolicyアドミッション・コントローラを有効にすると、Kubernetesシステム権限ポッドのポッド・セキュリティ・ポリシー、および関連するclusterroleとclusterrolebindingが自動的に作成されます。これらを使用すると、kube-systemネームスペースのすべてのポッドを実行できます。これらは、次に示すkube-system.yamlの定義で作成されます:
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
annotations:
# See https://kubernetes.io/docs/concepts/policy/pod-security-policy/#seccomp
seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
name: oke-privileged
spec:
allowedCapabilities:
- '*'
allowPrivilegeEscalation: true
fsGroup:
rule: 'RunAsAny'
hostIPC: true
hostNetwork: true
hostPID: true
hostPorts:
- min: 0
max: 65535
privileged: true
readOnlyRootFilesystem: false
runAsUser:
rule: 'RunAsAny'
seLinux:
rule: 'RunAsAny'
supplementalGroups:
rule: 'RunAsAny'
volumes:
- '*'
---
# Cluster role which grants access to the privileged pod security policy
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: oke-privileged-psp
rules:
- apiGroups:
- policy
resourceNames:
- oke-privileged
resources:
- podsecuritypolicies
verbs:
- use
---
# Role binding for kube-system - allow kube-system service accounts - should take care of CNI i.e. flannel running in the kube-system namespace
# Assumes access to the kube-system is restricted
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: kube-system-psp
namespace: kube-system
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: oke-privileged-psp
subjects:
# For all service accounts in the kube-system namespace
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:serviceaccounts:kube-system