ステップ 1: すべてのポッドが ibm-privileged-psp PSP の下で実行されていることを確認する

以下のステップを実行して、すべてのポッドが ibm-privileged-psp PSP の下で実行されるようにします。

ポッド・セキュリティー・アドミッションと PodSecurityPolicies の違いの 1 つとして、ポッド・セキュリティー・アドミッションは検証中ですが、 PodSecurityPolicies はミュータブルにすることができます。 これにより、アップグレードする前にポッドが ibm-privileged-psp(ミュータブル PSP ではない) を使用することが重要になります。 ポッド・セキュリティー・アドミッションと ibm-privileged-psp は両方とも検証中であるため、ポッドはどちらでも同じように動作します。

例えば、ポッドが現在 ibm-restricted-psp の下で実行されている場合、PSP 内の MustRunAs 範囲に基づいて、ポッドの securityContext セクションで fsGroup および supplementalGroups を 1 に設定できます。 ibm-restricted-psp はポッド securityContext を変更することができる。 このような変更は、実行中のポッドの securityContext と、ポッドを作成するデプロイメント・リソースまたは類似リソースのポッド・テンプレート内の securityContext との差として表示されます。 ibm-privileged-psp はミュータブルではないため、その下で実行されているポッドは異なるグループで実行され、既存の PVC に保管されているデータにアクセスできない可能性があります。

1. すべてのポッドの詳細を取得し、それらの PSP を確認します。

   kubectl get pods -A -o jsonpath="{.items[*].metadata.annotations.kubernetes\.io\/psp}" | tr " " "\n" | sort -u
   

2. ibm-privileged-psp 以外の PSP のコマンド出力を確認します。 ポッドが別の PSP を使用している場合は、クラスターをアップグレードする前に、 ibm-privileged-psp を使用するようにアプリケーションを更新する必要があります。 他の PSP がリストされていない場合は、アップグレードを続行できます。

出力に PSP ibm-privileged-psp 以外の PSP がリストされている場合、 へのアップグレードは 1.25 推奨されません。

ステップ 2: privileged-psp-user クラスター役割バインディングがデフォルト構成を使用していることを確認する

以下のステップを実行して、 privileged-psp-user クラスター役割バインディングがデフォルト構成を使用していることを確認します。 これにより、すべてのサービス・アカウントおよびユーザーに、 privileged-psp-user クラスター役割バインディングを介して ibm-restricted-psp を使用する権限が付与されます。

クラスターロールバインディングが、以下の例に示されているとおりに正確に subjects デフォルトの role および を持たない場合、 へのアップ 1.25 グレードは失敗します。

1. privileged-psp-user クラスター役割バインディングの詳細を取得します。

   kubectl get clusterrolebinding privileged-psp-user -o yaml
   

2. 出力の role および subjects を確認します。 出力が以下の例と異なる場合は、 1.25にアップグレードしないでください。 privileged-psp-user クラスター役割バインディングが以下の例と一致する場合は、アップグレードを続行できます。

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     creationTimestamp: "2022-10-06T20:12:36Z"
     name: privileged-psp-user
     resourceVersion: "151862"
     uid: 15014736-94d2-4cba-a3a8-92dd36de453b
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: ibm-privileged-psp-user
   subjects:
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:masters
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:nodes
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:serviceaccounts
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:authenticated
   

ステップ 3: restricted-psp-user クラスター役割バインディングがデフォルト構成を使用していることを確認する

以下のステップを実行して、 restricted-psp-user クラスター役割バインディングがデフォルト構成を使用していることを確認します。 これにより、すべてのサービス・アカウントおよびユーザーに、 restricted-psp-user クラスター役割バインディングを介して ibm-restricted-psp を使用する権限が付与されます。

クラスターロールのバインディングに、以下の例に示すようにデフォルト subjects の role および が含まれていない場合、 へのアップ 1.25 グレードは失敗します。

1. restricted-psp-user クラスター役割バインディングの詳細を取得します。

   kubectl get clusterrolebinding restricted-psp-user -o yaml
   

2. コマンドの出力を確認します。 以下の例に示すように、クラスター役割バインディングに role および subjects のデフォルト設定が含まれていない場合は、クラスターをバージョン 1.25 にアップグレードしないでください。

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     creationTimestamp: "2022-10-06T20:13:10Z"
     name: restricted-psp-user
     resourceVersion: "151890"
     uid: 4edb362f-9933-48d7-95e2-f41cd9f4dead
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: ibm-restricted-psp-user
   subjects:
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:masters
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:nodes
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:serviceaccounts
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:authenticated
   

ステップ 4:IBM 以外の PSP の確認

以下のステップを実行して、クラスターがIBM 以外の PSP を使用しているかどうかを確認します。

バージョンへのアップグレードは、コマンド出力が 1.25 以下の例に追加のPSPを含んでいる場合に失敗します。 サード・パーティー・アプリケーションからの追加 PSP があり、それらのアプリケーションに使用する適切なアップグレード戦略を決定するために、アプリケーションの更新またはアプリケーション・ベンダーとの連携が必要になる場合があります。

1. ポッド・セキュリティー・ポリシーをリストします。

   kubectl get podsecuritypolicies -o name
   

2. コマンドの出力を確認します。

   Warning: policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
   podsecuritypolicy.policy/ibm-anyuid-hostaccess-psp
   podsecuritypolicy.policy/ibm-anyuid-hostpath-psp
   podsecuritypolicy.policy/ibm-anyuid-psp
   podsecuritypolicy.policy/ibm-privileged-psp
   podsecuritypolicy.policy/ibm-restricted-psp
   

3. IBM PSP を使用するようにアプリを更新します。

ステップ 1: 1.24 クラスターでポッド・セキュリティー・アドミッションを有効にする

1.24 クラスターでポッド・セキュリティー・アドミッションを有効にします。 このコマンドは、新しいポッド・セキュリティー・アドミッション構成を使用するようにクラスター・マスターを更新します。 クラスタマスターの更新には数分かかる場合があります。

ibmcloud ks cluster master pod-security set --cluster <CLUSTER>

ステップ 2: 名前空間のアクセス権を確認する

外部 Kubernetes の資料で名前空間の許可を確認してください。 Kubernetes の権限が IAM サービス・ロールによって管理されている場合、ネームスペースの作成または編集とポッド・セキュリティ・ラベルの設定には Manager サービス・ロールが必要です。

• 名前空間のアクセス権の確認

ステップ 3: PSP の簡素化と標準化

外部 Kubernetes 資料の手順に従って、ポッド・セキュリティー構成をクリーンアップします。 PSP ibm-privileged-psp、 ibm-anyuid-psp、 ibm-anyuid-hostpath-psp、 ibm-anyuid-hostaccess-psp 、および ibm-restricted-psp のいずれも変更または削除 しないでください。

• 簡素化と標準化 PodSecurityPolicies

ステップ 4: クラスター内の名前空間を更新する

外部 Kubernetes 資料の手順に従って、クラスター内の名前空間を更新します。 これらのステップは、 IBM Cloudによって管理されていないクラスター内のすべての名前空間で実行する必要があります。 このセクションに含まれている例外に注意してください。

以下の名前空間で管理されているPodセキュリティラベルを削除 IBM Cloud または変更しないでください： kube-system, ibm-system, ibm-operators.

ステップ 3.d. このステップでリンクされている外部ドキュメントのバイパ PodSecurity スポリシーに従い、提案されている特権PSPを作成しないでください。 この追加のPSPを作成した場合、 アップグレード 要件に記載されている通り、 1.25 バージョン にアップグレードする前に削除する必要があります。 代わりに、コマンド kubectl create -n $NAMESPACE rolebinding disable-psp --clusterrole ibm-privileged-psp-user --group system:serviceaccounts:$NAMESPACE を使用して、 ibm-privileged-psp-user クラスター役割に対する RoleBinding を作成します。

• 名前空間の更新

ステップ 5: 名前空間作成プロセスの確認

外部 Kubernetes 資料の情報を参照して、クラスター内に作成された新しい名前空間にポッド・セキュリティー・プロファイルが適用されていることを確認します。

• 名前空間作成プロセスの確認

ステップ 6: オプション。 クラスター内の PSP 機能を無効にします。

1. クラスター内の PodSecurityPolicy アドミッション・コントローラーを無効にします。 このコマンドは、新しい構成を使用するようにクラスター・マスターを更新します。

   ibmcloud ks cluster master pod-security policy disable --cluster <cluster>
   

2. クラスター・マスターの更新が完了するまで数分待ちます。
3. PSP と、関連する Roles、 ClusterRoles、 RoleBindings、および ClusterRoleBindings を削除します。 削除するコンポーネントによって、他の場所で必要になる可能性がある他の関連のない権限が付与されないようにしてください。 PSP ibm-privileged-psp、 ibm-anyuid-psp、 ibm-anyuid-hostpath-psp、 ibm-anyuid-hostaccess-psp 、および ibm-restricted-psp は削除 しないでください。 ClusterRoles および ClusterRoleBindings( privileged-psp-user および restricted-psp-user) を削除 しないでください。

クラスタ 1.24 でPSPを再度有効にする必要がある場合は、. を実行してください ibmcloud ks cluster master pod-security policy enable --cluster <cluster>。 このコマンドは、PSP 構成を使用するようにクラスター・マスターを更新します。

ステップ 7: オプション。 クラスターのアップグレード

クラスターを少なくともバージョン にアップグレード 1.25 して、Pod セキュリティアドミッションを使用してください。 または、アップグレードの準備が整うまで、Pod Security Admissionを有効にした状態でクラ 1.24 スターをバージョンに維持してください。