GSP496

概要

このラボでは、デフォルトの GKE クラスタ構成におけるセキュリティ上の懸念事項と、それに対応する強化策について説明します。強化策では、Pod のエスケープとクラスタの権限昇格を発生させる複数の方法を防止します。具体的には、次のようなシナリオにおける攻撃方法です。

1. 外部に接続された Pod 内のアプリケーションに、サーバー側のリクエスト フォージェリ（SSRF）攻撃を可能にする不具合がある場合。
2. Pod 内のコンテナが完全に不正使用され、リモート コマンド実行（RCE）が可能になっている場合。
3. 悪意のある内部ユーザーがいる場合や、特定の名前空間で Pod の作成や更新を行える内部ユーザーの認証情報セットを攻撃者が不正使用する場合。

このラボは、デフォルトの GKE クラスタ構成を強化する方法について理解を深められるように、GKE Helmsman のエンジニアによって作成されました。

このラボのサンプルコードは現状のまま提供されるもので、いかなる保証もありません

目標

このラボを完了すると、GKE Instance Metadata を保護し、環境に適した PodSecurityPolicy ポリシーを定義する必要性を理解できます。

このチュートリアルでは、次のことを行います。

1. デフォルトの設定を使用して小規模な GKE クラスタを作成する。
2. 悪意のある内部ユーザーの視点で、Pod のエスケープとクラスタの権限昇格を行う一般的な方法を検証する。
3. これらの問題に対応できるよう GKE クラスタを強化する。
4. これらのアクションを実行できなくなったことをクラスタで検証する。

設定と要件

[ラボを開始] ボタンをクリックする前に

こちらの手順をお読みください。ラボの時間は記録されており、一時停止することはできません。[ラボを開始] をクリックするとスタートするタイマーは、Google Cloud のリソースを利用できる時間を示しています。

このハンズオンラボでは、シミュレーションやデモ環境ではなく、実際のクラウド環境を使ってご自身でラボのアクティビティを行うことができます。そのため、ラボの受講中に Google Cloud にログインおよびアクセスするための、新しい一時的な認証情報が提供されます。

このラボを完了するためには、下記が必要です。

• 標準的なインターネット ブラウザ（Chrome を推奨）

注: このラボの実行には、シークレット モードまたはシークレット ブラウジング ウィンドウを使用してください。これにより、個人アカウントと受講者アカウント間の競合を防ぎ、個人アカウントに追加料金が発生することを防ぎます。

• ラボを完了するために十分な時間を確保してください。ラボをいったん開始すると一時停止することはできません。

注: すでに個人の Google Cloud アカウントやプロジェクトをお持ちの場合でも、このラボでは使用しないでください。アカウントへの追加料金が発生する可能性があります。

ラボを開始して Google Cloud コンソールにログインする方法

1. [ラボを開始] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるポップアップでお支払い方法を選択してください。 左側の [ラボの詳細] パネルには、以下が表示されます。

   • [Google コンソールを開く] ボタン
   • 残り時間
   • このラボで使用する必要がある一時的な認証情報
   • このラボを行うために必要なその他の情報（ある場合）

2. [Google コンソールを開く] をクリックします。 ラボでリソースが起動し、別のタブで [ログイン] ページが表示されます。

   ヒント: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。

   注: [アカウントの選択] ダイアログが表示されたら、[別のアカウントを使用] をクリックします。

3. 必要に応じて、[ラボの詳細] パネルから [ユーザー名] をコピーして [ログイン] ダイアログに貼り付けます。[次へ] をクリックします。

4. [ラボの詳細] パネルから [パスワード] をコピーして [ようこそ] ダイアログに貼り付けます。[次へ] をクリックします。

   重要: 認証情報は左側のパネルに表示されたものを使用してください。Google Cloud Skills Boost の認証情報は使用しないでください。 注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。

5. その後次のように進みます。

   • 利用規約に同意してください。
   • 一時的なアカウントなので、復元オプションや 2 要素認証プロセスは設定しないでください。
   • 無料トライアルには登録しないでください。

その後このタブで Cloud Console が開きます。

注: 左上にある [ナビゲーション メニュー] をクリックすると、Google Cloud のプロダクトやサービスのリストが含まれるメニューが表示されます。

Cloud Shell をアクティブにする

Cloud Shell は、開発ツールと一緒に読み込まれる仮想マシンです。5 GB の永続ホーム ディレクトリが用意されており、Google Cloud で稼働します。Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。

1. Google Cloud コンソールの上部にある「Cloud Shell をアクティブにする」アイコン をクリックします。

接続した時点で認証が完了しており、プロジェクトに各自の PROJECT_ID が設定されます。出力には、このセッションの PROJECT_ID を宣言する次の行が含まれています。

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud は Google Cloud のコマンドライン ツールです。このツールは、Cloud Shell にプリインストールされており、タブ補完がサポートされています。

2. （省略可）次のコマンドを使用すると、有効なアカウント名を一覧表示できます。

gcloud auth list

3. [承認] をクリックします。

4. 出力は次のようになります。

出力:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. （省略可）次のコマンドを使用すると、プロジェクト ID を一覧表示できます。

gcloud config list project

出力:

[core] project = <project_ID>

出力例:

[core] project = qwiklabs-gcp-44776a13dea667a6 注: Google Cloud における gcloud ドキュメントの全文については、gcloud CLI の概要ガイドをご覧ください。

タスク 1. シンプルな GKE クラスタを作成する

1. MY_ZONE という環境変数にゾーンを設定します。このラボでは「」を使用しますが、必要に応じてゾーンを選択することもできます。

export MY_ZONE={{{project_0.default_zone|ZONE}}}

2. 次のコマンドを実行して、Kubernetes Engine が管理する simplecluster という Kubernetes クラスタを起動し、ノードが 2 つ実行されるように構成します。

gcloud container clusters create simplecluster --zone $MY_ZONE --num-nodes 2 --metadata=disable-legacy-endpoints=false --cluster-version=1.24

Kubernetes Engine によって仮想マシンがプロビジョニングされるため、クラスタの作成には数分かかります。新しいバージョンで利用できる機能についての警告が表示されたら、このラボでは無視してかまいません。

3. クラスタが作成されたら、kubectl version コマンドを使用して、インストール済みの Kubernetes のバージョンを確認します。

kubectl version

kubectl は、gcloud container clusters create コマンドで自動的に認証されました。

4. Google Cloud コンソールで実行中のノードを表示します。ナビゲーション メニューで、[Compute Engine] > [VM インスタンス] をクリックします。

Kubernetes クラスタを使用する準備が整いました。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 シンプルな GKE クラスタを作成する

タスク 2. Google Cloud SDK Pod を実行する

1. Cloud Shell のプロンプトで、Google Cloud SDK コンテナの単一のインスタンスを起動します。

kubectl run -it --rm gcloud --image=google/cloud-sdk:latest --restart=Never -- bash

完了するまでに数分かかります。

注: タイムアウト エラーが表示される場合は、コマンドを再度実行してください。

2. これで、Pod のコンテナ内で bash シェルを使用できるようになりました。

root@gcloud:/#

コンテナが起動してコマンド プロンプトが表示されるまでに数秒かかる場合があります。コマンド プロンプトが表示されない場合は、Enter キーを押してください。

Compute Metadata エンドポイントを確認する

1. 次のコマンドを実行して、v1 Compute Metadata エンドポイントにアクセスします。

curl -s http://metadata.google.internal/computeMetadata/v1/instance/name

出力は以下のようになります。

...snip... Your client does not have permission to get URL /computeMetadata/v1/instance/name from this server. Missing Metadata-Flavor:Google header. ...snip...

カスタム HTTP ヘッダーが必要であることを示すエラーがどのように返されるか確認します。

2. 次のコマンドを実行してカスタム ヘッダーを追加し、この Pod を実行している Compute Engine インスタンスの名前を取得します。

curl -s -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/name

出力は以下のようになります。

gke-simplecluster-default-pool-b57a043a-6z5v 注: Compute Engine Instance Metadata エンドポイントにアクセスする際にカスタム HTTP ヘッダーを必須にしない場合、アプリケーションに不具合があれば攻撃者はウェブ URL に誤認させてユーザー認証情報を取得できます。カスタム HTTP ヘッダーを必須にすると、アプリケーションの不具合とカスタム ヘッダーの両方が必要となるため、攻撃がより困難になります。

このシェルを、次のステップで利用できる Pod 内に残しておきます。

3. 誤って Pod を閉じた場合は、次のコマンドで再実行してください。

kubectl run -it --rm gcloud --image=google/cloud-sdk:latest --restart=Never -- bash

GKE ノードのブートストラップ用認証情報を確認する

1. 同じ Pod シェル内から次のコマンドを実行して、基盤となる Compute Engine インスタンスに関連付けられた属性のリストを取得します。必ず最後にスラッシュを含めてください。

curl -s -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/attributes/

このリストで最も機密性が高いデータは kube-env であると考えられます。kubelet がノードを GKE クラスタに関連付ける際に初期の認証情報として使用する複数の変数が含まれています。CA_CERT、KUBELET_CERT、KUBELET_KEY の変数にこの情報が含まれているため、クラスタ管理者以外には機密と見なされます。

2. 機密の可能性がある変数やデータを表示するには、次のコマンドを実行します。

curl -s -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/attributes/kube-env

次のいずれかの状況で懸念事項が発生する可能性があります。

• Pod アプリケーションで SSRF が発生する可能性がある不具合
• Pod で RCE が発生する可能性がある、アプリケーションまたはライブラリの不具合
• Pod の作成や Pod に対する操作を実行できる内部ユーザー

Compute Metadata エンドポイント経由で、kubelet の機密のブートストラップ用認証情報が不正使用されたり流出したりする可能性が高くなります。kubelet の認証情報を利用すると、特定の環境で権限を cluster-admin に昇格させることができます。そのため、データ、アプリケーション、基盤となるノードへのアクセス権限など、GKE Cluster を完全に制御できます。

このノードプールのサービス アカウントに割り当てられた権限を利用する

デフォルトでは、Compute API が有効になっている Google Cloud プロジェクトにはデフォルトのサービス アカウントがあります。プロジェクト内で NNNNNNNNNN-compute@developer.gserviceaccount.com の形式になっており、編集者のロールが割り当てられています。また、デフォルトでは、サービス アカウントを指定せずに作成された GKE クラスタは、デフォルトの Compute のサービス アカウントを利用し、そのサービス アカウントをすべてのワーカーノードに関連付けます。

1. 次の curl コマンドを実行して、基盤となる Compute Engine インスタンスに関連付けられたサービス アカウントに紐付いている OAuth スコープのリストを取得します。

curl -s -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/scopes

（出力）

https://www.googleapis.com/auth/devstorage.read_only https://www.googleapis.com/auth/logging.write https://www.googleapis.com/auth/monitoring https://www.googleapis.com/auth/service.management.readonly https://www.googleapis.com/auth/servicecontrol https://www.googleapis.com/auth/trace.append

認証スコープとサービス アカウントの権限の組み合わせによって、このノードのアプリケーションがアクセスできる対象が決まります。ほとんどの GKE クラスタで上記のリストが必要最小限のスコープとなりますが、ユースケースによっては追加のスコープが必要になる場合があります。

警告: クラスタ作成中に、認証スコープに「https://www.googleapis.com/auth/cloud-platform」が含まれるよう構成した場合、任意の Google Cloud API がスコープ内と見なされ、サービス アカウントに割り当てられた IAM 権限のみがアクセス権を決定します。

また、編集者のデフォルト IAM ロールを使用するデフォルトのサービス アカウントが使用中の場合、GKE クラスタがデプロイされていれば、このノードプールの任意の Pod に Google Cloud プロジェクトに対する編集者権限が付与されます。編集者 IAM ロールには、プロジェクト リソース（Compute インスタンス、Cloud Storage バケット、GCR レジストリなど）を操作できる広範な読み取りと書き込みの権限があるため、これは重大なセキュリティ リスクとなります。

2. 次のコマンドを入力してこの Pod を閉じます。

exit 注: Cloud Shell に戻らない場合は、Ctrl+C キーを押してください

タスク 3. ホストのファイルシステムをマウントする Pod をデプロイする

基盤となるホストに「エスケープ」するシンプルな方法の 1 つは、Pod の仕様で Kubernetes の標準の volumes と volumeMounts を使用して、ホストのファイルシステムを Pod のファイルシステムにマウントすることです。

1. これを確認するために、次のコマンドを実行して、基盤となるホストのファイルシステム / を、コンテナ内の /rootfs というフォルダにマウントする Pod を作成します。

cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: hostpath spec: containers: - name: hostpath image: google/cloud-sdk:latest command: ["/bin/bash"] args: ["-c", "tail -f /dev/null"] volumeMounts: - mountPath: /rootfs name: rootfs volumes: - name: rootfs hostPath: path: / EOF

2. kubectl get pod を実行します（「Running」の状態になるまで何度か実行します）。

kubectl get pod

（出力）

NAME READY STATUS RESTARTS AGE hostpath 1/1 Running 0 30s

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 ホストのファイルシステムをマウントする Pod をデプロイする

タスク 4. 基盤となるホストを確認し、不正使用する

1. 次のコマンドを実行して、先ほど作成した Pod 内のシェルを取得します。

kubectl exec -it hostpath -- bash

2. Pod シェルのルート ファイルシステムを、基盤となるホストのルート ファイルシステムを参照するように切り替えます。

chroot /rootfs /bin/bash

このシンプルなコマンドを実行することで、Pod はノード上で root シェルになりました。これで、以下の操作を実行できます。

完全な権限で標準の docker コマンドを実行する	docker ps
docker イメージのリストを取得する	docker images
docker run 選択する特権付きコンテナ	docker run --privileged <imagename>:<imageversion>
マウントされた Kubernetes の Secret を調べる	mount | grep volumes | awk '{print $3}' | xargs ls
exec 任意の実行中コンテナに対して実行する（別の名前空間にある別の Pod に対して実行することも可能）	docker exec -it <docker container ID> sh

root ユーザーが実行できるほとんどの操作は、この Pod シェルで実行できます。これには、永続的に利用できるメカニズムが含まれます（SSH ユーザー / 認証鍵の追加、Kubernetes が参照できないホスト上の特権付き docker コンテナの実行など）。

3. Pod シェルを閉じるには、exit を 2 回実行します。1 回目で chroot、2 回目で Pod のシェルが閉じます。

exit exit 注: Cloud Shell に戻らない場合は、Ctrl+C キーを押してください

4. これで、hostpath Pod を削除できます。

kubectl delete pod hostpath

利用可能なコントロールを理解する

このデモの次のステップでは、以下の内容を確認します。

• Legacy Compute Engine Metadata API エンドポイントを無効化する - カスタム メタデータのキーと値を指定すると、v1beta1 メタデータ エンドポイントはインスタンスから利用できなくなります。
• メタデータ隠蔽を有効にする - クラスタまたはノードプールの作成時に追加の構成を渡すことで、各ノードに軽量のプロキシがインストールされ、Metadata API に対するすべてのリクエストをプロキシ処理し、機密のエンドポイントへのアクセスを防ぎます。
• PodSecurityPolicy を有効化、構成する - GKE クラスタ上でこのオプションを構成すると、PodSecurityPolicy アドミッション コントローラが追加されます。これは、Pod の作成中に安全でない設定の使用を制限するために使用できます。このデモのケースでは、コンテナが root ユーザーとして実行されることを防ぎ、基盤となるホストのファイルシステムをマウントできます。

タスク 5. 2 つ目のノードプールをデプロイする

メタデータ エンドポイントが保護されている場合と保護されていない場合のテストが実施できるように、追加の設定を 2 つ含む 2 つ目のノードプールを作成します。1 つ目の一般的なノードプールに対してスケジュール設定された Pod は保護されず、2 つ目のノードプールに対してスケジュール設定された Pod は保護されます。

注: Legacy エンドポイントは 2020 年 9 月 30 日に非推奨となりました。GKE バージョン 1.12 以降では、「--metadata=disable-legacy-endpoints=true」の設定が自動的に有効になります。以下のコマンドは、この設定を明示的に定義しています。

• 2 つ目のノードプールを作成します。

gcloud beta container node-pools create second-pool --cluster=simplecluster --zone=$MY_ZONE --num-nodes=1 --metadata=disable-legacy-endpoints=true --workload-metadata-from-node=SECURE

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 2 つ目のノードプールをデプロイする

タスク 6. Google Cloud SDK Pod を実行する

1. Cloud Shell で、保護されている 2 つ目のノードプールでのみ実行され、かつ root ユーザーとして実行されない Google Cloud SDK コンテナの単一のインスタンスを起動します。

kubectl run -it --rm gcloud --image=google/cloud-sdk:latest --restart=Never --overrides='{ "apiVersion": "v1", "spec": { "securityContext": { "runAsUser": 65534, "fsGroup": 65534 }, "nodeSelector": { "cloud.google.com/gke-nodepool": "second-pool" } } }' -- bash 注: タイムアウト エラーが表示される場合は、コマンドを再度実行してください。

2. これで、second-pool というノードプール上で実行される Pod のコンテナ内で bash シェルを利用できます。次の結果が表示されます。

nobody@gcloud:/$

コンテナが起動し、コマンド プロンプトが開くまで数秒かかることがあります。

コマンド プロンプトが表示されない場合は Enter キーを押してください。

さまざまなブロックされたエンドポイントを調べる

1. 2 つ目のノードプールの構成が --workload-metadata-from-node=SECURE に設定されていると、機密ファイル kube-env を取得する次のコマンドがエラーになります。

curl -s -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/attributes/kube-env

（出力）

This metadata endpoint is concealed.

2. 機密でないエンドポイントに対して他のコマンドを実行すると、適切な HTTP ヘッダーが渡された場合は引き続き正常に動作します。

curl -s -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/name

（出力例）

gke-simplecluster-second-pool-8fbd68c5-gzzp

3. Pod を閉じます。

exit

Cloud Shell に戻ります。

タスク 7. PodSecurityPolicy オブジェクトをデプロイする

1. 続行に必要な権限を設定するために、cluster-admin になるための明示的な権限を独自のユーザー アカウントに付与します。

kubectl create clusterrolebinding clusteradmin --clusterrole=cluster-admin --user="$(gcloud config list account --format 'value(core.account)')"

（出力）

clusterrolebinding.rbac.authorization.k8s.io/clusteradmin created

2. 次に、デフォルトの名前空間内のすべての認証済みユーザーに、より制限の厳しい PodSecurityPolicy をデプロイします。

cat <<EOF | kubectl apply -f - --- apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: restrictive-psp annotations: seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default' apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default' seccomp.security.alpha.kubernetes.io/defaultProfileName: 'docker/default' apparmor.security.beta.kubernetes.io/defaultProfileName: 'runtime/default' spec: privileged: false # Required to prevent escalations to root. allowPrivilegeEscalation: false # This is redundant with non-root + disallow privilege escalation, # but we can provide it for defense in depth. requiredDropCapabilities: - ALL # Allow core volume types. volumes: - 'configMap' - 'emptyDir' - 'projected' - 'secret' - 'downwardAPI' # Assume that persistentVolumes set up by the cluster admin are safe to use. - 'persistentVolumeClaim' hostNetwork: false hostIPC: false hostPID: false runAsUser: # Require the container to run without root privileges. rule: 'MustRunAsNonRoot' seLinux: # This policy assumes the nodes are using AppArmor rather than SELinux. rule: 'RunAsAny' supplementalGroups: rule: 'MustRunAs' ranges: # Forbid adding the root group. - min: 1 max: 65535 fsGroup: rule: 'MustRunAs' ranges: # Forbid adding the root group. - min: 1 max: 65535 EOF

（出力）

podsecuritypolicy.extensions/restrictive-psp created

3. 次に、ClusterRole を追加して、この PodSecurityPolicy を「使用」できるようにします。

cat <<EOF | kubectl apply -f - --- kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: restrictive-psp rules: - apiGroups: - extensions resources: - podsecuritypolicies resourceNames: - restrictive-psp verbs: - use EOF

（出力）

clusterrole.rbac.authorization.k8s.io/restrictive-psp created

4. 最後に、デフォルトの名前空間に RoleBinding を作成して、任意の認証済みユーザー権限で PodSecurityPolicy を利用できるようにします。

cat <<EOF | kubectl apply -f - --- # All service accounts in kube-system # can 'use' the 'permissive-psp' PSP apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: restrictive-psp namespace: default roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: restrictive-psp subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: system:authenticated EOF

（出力）

rolebinding.rbac.authorization.k8s.io/restrictive-psp created 注: 実際の環境では、RoleBinding の system:authenticated ユーザーを、デフォルトの名前空間で Pod を作成できるようにする特定のユーザーまたはサービス アカウントに置き換えることを検討してください。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 PodSecurityPolicy オブジェクトをデプロイする

PodSecurity ポリシーを有効にする

• PodSecurityPolicy アドミッション コントローラを有効にします。

gcloud beta container clusters update simplecluster --zone $MY_ZONE --enable-pod-security-policy

こちらは、完了するまでに数分かかります。

タスク 8. ホストのファイルシステムをマウントするブロックされた Pod をデプロイする

GKE クラスタのデプロイに使用するアカウントには、前のステップで cluster-admin の権限が付与されました。そのため、クラスタを操作して PodSecurityPolicy が適用されていることを検証する別の「ユーザー」アカウントを作成する必要があります。

1. これを行うには、次のコマンドを実行します。

gcloud iam service-accounts create demo-developer

（出力）

Created service account [demo-developer].

2. 次に、以下の各コマンドを実行して、クラスタの操作と Pod の作成を行える権限をサービス アカウントに付与します。

MYPROJECT=$(gcloud config list --format 'value(core.project)') gcloud projects add-iam-policy-binding "${MYPROJECT}" --role=roles/container.developer --member="serviceAccount:demo-developer@${MYPROJECT}.iam.gserviceaccount.com"

3. 次のコマンドを実行して、サービス アカウントの認証情報ファイルを取得します。

gcloud iam service-accounts keys create key.json --iam-account "demo-developer@${MYPROJECT}.iam.gserviceaccount.com"

4. kubectl を構成して、このサービス アカウントとして認証します。

gcloud auth activate-service-account --key-file=key.json

5. 次のコマンドを実行して、クラスタと通信する際にこれらの認証情報を使用するように kubectl を構成します。

gcloud container clusters get-credentials simplecluster --zone $MY_ZONE

6. 基盤となるホストのファイルシステム / を、コンテナ内の /rootfs というフォルダにマウントする別の Pod を作成します。

cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: hostpath spec: containers: - name: hostpath image: google/cloud-sdk:latest command: ["/bin/bash"] args: ["-c", "tail -f /dev/null"] volumeMounts: - mountPath: /rootfs name: rootfs volumes: - name: rootfs hostPath: path: / EOF

7. この出力では、PSP によってブロックされていることを確認できます。

Error from server (Forbidden): error when creating "STDIN": pods "hostpath" is forbidden: unable to validate against any pod security policy: [spec.volumes[0]: Invalid value: "hostPath": hostPath volumes are not allowed to be used]

8. restrictive-psp の基準を満たす別の Pod をデプロイします。

cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: hostpath spec: securityContext: runAsUser: 1000 fsGroup: 2000 containers: - name: hostpath image: google/cloud-sdk:latest command: ["/bin/bash"] args: ["-c", "tail -f /dev/null"] EOF

（出力）

pod/hostpath created

9. 次のコマンドを実行して、作成を承認した PodSecurityPolicy を示す Pod に追加されるアノテーションを表示します。

kubectl get pod hostpath -o=jsonpath="{ .metadata.annotations.kubernetes\.io/psp }"

（Cloud Shell コマンドラインに出力が追加されます）

restrictive-psp

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 ホストのファイルシステムをマウントするブロックされた Pod をデプロイする

お疲れさまでした

このラボでは、Google Kubernetes Engine でデフォルトの Kubernetes クラスタを構成しました。その後、Pod に対して利用できるアクセスをプローブ、悪用してからクラスタを強化し、悪意のあるアクションが実行できなくなっていることを確認しました。

クエストを完了する

このセルフペース ラボは、「Google Kubernetes Engine Best Practices: Security」クエストの一部です。クエストとは学習プログラムを構成する一連のラボのことで、完了すると成果が認められてバッジが贈られます。バッジは公開して、オンライン レジュメやソーシャル メディア アカウントにリンクできます。このラボの修了後、こちらのクエストまたはこのラボが含まれるクエストに登録すれば、すぐにクレジットを受け取ることができます。受講可能なすべてのクエストについては、Google Cloud Skills Boost カタログをご覧ください。

次のラボを受講する

「Google Kubernetes Engine Security: Binary Authorization」に進んでクエストを続けるか、以下の Google Cloud Skills Boost ラボをご確認ください。

• Kubernetes Engine でアプリケーションを保護する - 3 つの例
• Kubernetes Engine におけるロールベースのアクセス制御の使用

次のステップと詳細情報

重要: このラボでは複数のセキュリティ上の問題について詳しく説明しましたが、実際の環境内で検討が必要な点は他にもあります。追加情報については、クラスタのセキュリティを強化するガイドをご覧ください。

PodSecurityPolicy: PodSecurityPolicies を使用するガイドおよびクラスタのセキュリティを強化するガイド

ノードのサービス アカウント: 権限ガイド

ノードのメタデータを保護する: ノードのメタデータを保護するガイド

Google Cloud トレーニングと認定資格

Google Cloud トレーニングと認定資格を通して、Google Cloud 技術を最大限に活用できるようになります。必要な技術スキルとベスト プラクティスについて取り扱うクラスでは、学習を継続的に進めることができます。トレーニングは基礎レベルから上級レベルまであり、オンデマンド、ライブ、バーチャル参加など、多忙なスケジュールにも対応できるオプションが用意されています。認定資格を取得することで、Google Cloud テクノロジーに関するスキルと知識を証明できます。

マニュアルの最終更新日: 2023 年 10 月 3 日

ラボの最終テスト日: 2023 年 10 月 9 日

Copyright 2024 Google LLC All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。