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

2. [Google Cloud コンソールを開く] をクリックします（Chrome ブラウザを使用している場合は、右クリックして [シークレット ウィンドウで開く] を選択します）。

   ラボでリソースがスピンアップし、別のタブで [ログイン] ページが表示されます。

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

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

3. 必要に応じて、下のユーザー名をコピーして、[ログイン] ダイアログに貼り付けます。

   {{{user_0.username | "Username"}}}

   [ラボの詳細] ペインでもユーザー名を確認できます。

4. [次へ] をクリックします。

5. 以下のパスワードをコピーして、[ようこそ] ダイアログに貼り付けます。

   {{{user_0.password | "Password"}}}

   [ラボの詳細] ペインでもパスワードを確認できます。

6. [次へ] をクリックします。

   重要: ラボで提供された認証情報を使用する必要があります。Google Cloud アカウントの認証情報は使用しないでください。 注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。

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

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

その後、このタブで Google Cloud コンソールが開きます。

注: Google Cloud のプロダクトやサービスにアクセスするには、ナビゲーション メニューをクリックするか、[検索] フィールドにサービス名またはプロダクト名を入力します。

Cloud Shell をアクティブにする

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

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

2. ウィンドウで次の操作を行います。

   • Cloud Shell 情報ウィンドウで操作を進めます。
   • Cloud Shell が認証情報を使用して Google Cloud API を呼び出すことを承認します。

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

Your Cloud Platform project in this session is set to {{{project_0.project_id | "PROJECT_ID"}}}

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

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

gcloud auth list

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

出力:

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} To set the active account, run: $ gcloud config set account `ACCOUNT`

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

gcloud config list project

出力:

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} 注: 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

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 に対するすべてのリクエストをプロキシ処理し、機密のエンドポイントへのアクセスを防ぎます。
• Pod セキュリティ アドミッションの有効化と利用 - GKE クラスタで Pod セキュリティ アドミッション（PSA）コントローラを有効にします。これにより、クラスタのセキュリティ ポスチャーを強化する Pod セキュリティ標準を適用できます。

タスク 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. Pod セキュリティ標準を適用する

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. 次に、Pod セキュリティ標準を適用します。「デフォルトの」名前空間に最も適したセキュリティ標準を選択します。「制限付き」プロファイルでは、より強固なセキュリティが提供されます。

kubectl label namespace default pod-security.kubernetes.io/enforce=restricted

3. 次に、ClusterRole を作成します。名前空間で Pod セキュリティ アドミッション レベルを変更できるユーザーを制御する場合は、pod-security-manager という ClusterRole を作成します。

cat <<EOF | kubectl apply -f - apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: pod-security-manager rules: - apiGroups: ['policy'] resources: ['podsecuritypolicies'] resourceNames: ['privileged', 'baseline', 'restricted'] verbs: ['use'] - apiGroups: [''] resources: ['namespaces'] verbs: ['get', 'list', 'watch', 'label'] EOF

4. 次に、RoleBinding を作成します。Pod セキュリティ アドミッションに関連する名前空間ラベルを変更できるユーザーを制限するには、「default」名前空間に RoleBinding を作成します。

cat <<EOF | kubectl apply -f - apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: pod-security-modifier namespace: default subjects: - kind: Group apiGroup: rbac.authorization.k8s.io name: system:authenticated roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: pod-security-manager EOF 注: 高度にカスタマイズされた動的 Pod セキュリティの適用については、OPA Gatekeeper や Kyverno などのツールを検討してください。

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

タスク 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. この出力では、Pod セキュリティ標準によってブロックされていることを確認できます。

Error from server (Forbidden): error when creating "STDIN": pods "hostpath" is forbidden: violates PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "hostpath" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "hostpath" must set securityContext.capabilities.drop=["ALL"]), restricted volume types (volume "rootfs" uses restricted volume type "hostPath"), runAsNonRoot != true (pod or container "hostpath" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "hostpath" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

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

cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: hostpath spec: securityContext: runAsNonRoot: true # Ensure a non-root user runAsUser: 1000 fsGroup: 2000 seccompProfile: # Add a seccomp profile type: RuntimeDefault containers: - name: hostpath image: google/cloud-sdk:latest command: ["/bin/bash"] args: ["-c", "tail -f /dev/null"] securityContext: allowPrivilegeEscalation: false capabilities: drop: ["ALL"] EOF

（出力）

pod/hostpath created

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

お疲れさまでした

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

次のステップと詳細情報

• 重要: このラボでは複数のセキュリティ上の問題について詳しく説明しましたが、実際の環境内で検討が必要な点は他にもあります。追加情報については、クラスタのセキュリティを強化するガイドをご覧ください。
• PodSecurity とクラスタのセキュリティを強化するガイドを使用して事前定義された Pod レベルのセキュリティ ポリシーを適用する
• ノードのサービス アカウント: 権限ガイド
• ノードのメタデータを保護する: ノードのメタデータを保護するガイド

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

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

マニュアルの最終更新日: 2024 年 2 月 14 日

ラボの最終テスト日: 2024 年 2 月 14 日

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