GSP496
概要
このラボでは、デフォルトの GKE クラスタ構成におけるセキュリティ上の懸念事項と、それに対応する強化策について説明します。強化策では、Pod のエスケープとクラスタの権限昇格を発生させる複数の方法を防止します。具体的には、次のようなシナリオにおける攻撃方法です。
外部に接続された Pod 内のアプリケーションに、サーバーサイド リクエスト フォージェリ(SSRF)攻撃を可能にする不具合がある場合。
Pod 内のコンテナが完全に不正使用され、リモート コマンド実行(RCE)が可能になっている場合。
悪意のある内部ユーザーがいる場合や、特定の名前空間で Pod の作成や更新を行える内部ユーザーの認証情報セットを攻撃者が不正使用する場合。
このラボは、デフォルトの GKE クラスタ構成を強化する方法について理解を深められるように、GKE Helmsman のエンジニアによって作成されました。
このラボのサンプルコードは現状のまま提供されるもので、いかなる保証もありません
目標
このラボを完了すると、GKE Instance Metadata を保護し、環境に適した PodSecurityPolicy ポリシーを定義する必要性を理解できます。
このラボで行うことは、以下のとおりです。
デフォルトの設定を使用して小規模な GKE クラスタを作成する。
悪意のある内部ユーザーの視点で、Pod のエスケープとクラスタの権限昇格を行う一般的な方法を検証する。
これらの問題に対応できるよう GKE クラスタを強化する。
これらのアクションを実行できなくなったことをクラスタで検証する。
設定と要件
[ラボを開始] ボタンをクリックする前に
こちらの説明をお読みください。ラボには時間制限があり、一時停止することはできません。タイマーは、Google Cloud のリソースを利用できる時間を示しており、[ラボを開始 ] をクリックするとスタートします。
このハンズオンラボでは、シミュレーションやデモ環境ではなく実際のクラウド環境を使って、ラボのアクティビティを行います。そのため、ラボの受講中に Google Cloud にログインおよびアクセスするための、新しい一時的な認証情報が提供されます。
このラボを完了するためには、下記が必要です。
標準的なインターネット ブラウザ(Chrome を推奨)
注: このラボの実行には、シークレット モード(推奨)またはシークレット ブラウジング ウィンドウを使用してください。これにより、個人アカウントと受講者アカウント間の競合を防ぎ、個人アカウントに追加料金が発生しないようにすることができます。
ラボを完了するための時間(開始後は一時停止できません)
注: このラボでは、受講者アカウントのみを使用してください。別の Google Cloud アカウントを使用すると、そのアカウントに料金が発生する可能性があります。
ラボを開始して Google Cloud コンソールにログインする方法
[ラボを開始 ] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるダイアログでお支払い方法を選択してください。
左側の [ラボの詳細] ペインには、以下が表示されます。
[Google Cloud コンソールを開く] ボタン
残り時間
このラボで使用する必要がある一時的な認証情報
このラボを行うために必要なその他の情報(ある場合)
[Google Cloud コンソールを開く ] をクリックします(Chrome ブラウザを使用している場合は、右クリックして [シークレット ウィンドウで開く ] を選択します)。
ラボでリソースがスピンアップし、別のタブで [ログイン] ページが表示されます。
ヒント: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。
注: [アカウントの選択 ] ダイアログが表示されたら、[別のアカウントを使用 ] をクリックします。
必要に応じて、下のユーザー名 をコピーして、[ログイン ] ダイアログに貼り付けます。
{{{user_0.username | "Username"}}}
[ラボの詳細] ペインでもユーザー名を確認できます。
[次へ ] をクリックします。
以下のパスワード をコピーして、[ようこそ ] ダイアログに貼り付けます。
{{{user_0.password | "Password"}}}
[ラボの詳細] ペインでもパスワードを確認できます。
[次へ ] をクリックします。
重要: ラボで提供された認証情報を使用する必要があります。Google Cloud アカウントの認証情報は使用しないでください。
注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。
その後次のように進みます。
利用規約に同意してください。
一時的なアカウントなので、復元オプションや 2 要素認証プロセスは設定しないでください。
無料トライアルには登録しないでください。
その後、このタブで Google Cloud コンソールが開きます。
注: Google Cloud のプロダクトやサービスにアクセスするには、ナビゲーション メニュー をクリックするか、[検索 ] フィールドにサービス名またはプロダクト名を入力します。
Cloud Shell をアクティブにする
Cloud Shell は、開発ツールと一緒に読み込まれる仮想マシンです。5 GB の永続ホーム ディレクトリが用意されており、Google Cloud で稼働します。Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。
Google Cloud コンソールの上部にある「Cloud Shell をアクティブにする 」アイコン をクリックします。
ウィンドウで次の操作を行います。
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 にプリインストールされており、タブ補完がサポートされています。
(省略可)次のコマンドを使用すると、有効なアカウント名を一覧表示できます。
gcloud auth list
[承認 ] をクリックします。
出力:
ACTIVE: *
ACCOUNT: {{{user_0.username | "ACCOUNT"}}}
To set the active account, run:
$ gcloud config set account `ACCOUNT`
(省略可)次のコマンドを使用すると、プロジェクト ID を一覧表示できます。
gcloud config list project
出力:
[core]
project = {{{project_0.project_id | "PROJECT_ID"}}}
注: Google Cloud における gcloud
ドキュメントの全文については、gcloud CLI の概要ガイド をご覧ください。
タスク 1. シンプルな GKE クラスタを作成する
MY_ZONE という環境変数にゾーンを設定します。このラボでは「 」を使用しますが、必要に応じてゾーン を選択することもできます。
export MY_ZONE={{{project_0.default_zone|ZONE}}}
次のコマンドを実行して、Kubernetes Engine が管理する simplecluster
という Kubernetes クラスタを起動し、ノードが 2 つ実行されるように構成します。
gcloud container clusters create simplecluster --zone $MY_ZONE --num-nodes 2 --metadata=disable-legacy-endpoints=false
Kubernetes Engine によって仮想マシンがプロビジョニングされるため、クラスタの作成には数分かかります。新しいバージョンで利用できる機能についての警告が表示されたら、このラボでは無視してかまいません。
クラスタが作成されたら、kubectl version
コマンドを使用して、インストール済みの Kubernetes のバージョンを確認します。
kubectl version
kubectl
は、gcloud container clusters create
コマンドで自動的に認証されました。
Google Cloud コンソールで実行中のノードを表示します。ナビゲーション メニュー で、[Compute Engine ] > [VM インスタンス ] をクリックします。
Kubernetes クラスタを使用する準備が整いました。
[進行状況を確認 ] をクリックして、目標に沿って進んでいることを確認します。 シンプルな GKE クラスタを作成する
タスク 2. Google Cloud SDK Pod を実行する
Cloud Shell のプロンプトで、Google Cloud SDK コンテナの単一のインスタンスを起動します。
kubectl run -it --rm gcloud --image=google/cloud-sdk:latest --restart=Never -- bash
完了するまでに数分かかります。
注: タイムアウト エラーが表示される場合は、コマンドを再度実行してください。
これで、Pod のコンテナ内で bash シェルを使用できるようになりました。
root@gcloud:/#
コンテナが起動してコマンド プロンプトが表示されるまでに数秒かかる場合があります。コマンド プロンプトが表示されない場合は、Enter キーを押してください。
Compute Metadata エンドポイントを確認する
次のコマンドを実行して、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 ヘッダーが必要であることを示すエラーがどのように返されるか確認します。
次のコマンドを実行してカスタム ヘッダーを追加し、この 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 内に残しておきます。
誤って Pod を閉じた場合は、次のコマンドで再実行してください。
kubectl run -it --rm gcloud --image=google/cloud-sdk:latest --restart=Never -- bash
GKE ノードのブートストラップ用認証情報を確認する
同じ 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
の変数にこの情報が含まれているため、クラスタ管理者以外には機密と見なされます。
機密の可能性がある変数やデータを表示するには、次のコマンドを実行します。
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 のサービス アカウントを利用し、そのサービス アカウントをすべてのワーカーノードに関連付けます。
次の 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 レジストリなど)を操作できる広範な読み取りと書き込みの権限があるため、これは重大なセキュリティ リスクとなります。
次のコマンドを入力してこの Pod を閉じます。
exit
注: Cloud Shell に戻らない場合は、Ctrl+C キーを押してください
タスク 3. ホストのファイルシステムをマウントする Pod をデプロイする
基盤となるホストに「エスケープ」するシンプルな方法の 1 つは、Pod
の仕様で Kubernetes の標準の volumes
と volumeMounts
を使用して、ホストのファイルシステムを Pod のファイルシステムにマウントすることです。
これを確認するために、次のコマンドを実行して、基盤となるホストのファイルシステム /
を、コンテナ内の /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
kubectl get pod
を実行します(「Running」の状態になるまで何度か実行します)。
kubectl get pod
(出力)
NAME READY STATUS RESTARTS AGE
hostpath 1/1 Running 0 30s
[進行状況を確認 ] をクリックして、目標に沿って進んでいることを確認します。 ホストのファイルシステムをマウントする Pod をデプロイする
タスク 4. 基盤となるホストを確認し、不正使用する
次のコマンドを実行して、先ほど作成した Pod 内のシェルを取得します。
kubectl exec -it hostpath -- bash
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 コンテナの実行など)。
Pod シェルを閉じるには、exit
を 2 回実行します。1 回目で chroot
、2 回目で Pod のシェルが閉じます。
exit
exit
注: Cloud Shell に戻らない場合は、Ctrl+C キーを押してください
これで、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」の設定が自動的に有効になります。以下のコマンドは、この設定を明示的に定義しています。
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 を実行する
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
注: タイムアウト エラーが表示される場合は、コマンドを再度実行してください。
これで、second-pool
というノードプール上で実行される Pod のコンテナ内で bash シェルを利用できます。次の結果が表示されます。
nobody@gcloud:/$
コンテナが起動し、コマンド プロンプトが開くまで数秒かかることがあります。
コマンド プロンプトが表示されない場合は Enter キーを押してください。
さまざまなブロックされたエンドポイントを調べる
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.
機密でないエンドポイントに対して他のコマンドを実行すると、適切な HTTP ヘッダーが渡された場合は引き続き正常に動作します。
curl -s -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/name
(出力例)
gke-simplecluster-second-pool-8fbd68c5-gzzp
Pod を閉じます。
exit
Cloud Shell に戻ります。
タスク 7. Pod セキュリティ標準を適用する
続行に必要な権限を設定するには、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
次に、Pod セキュリティ標準を適用します。「デフォルトの」名前空間に最も適したセキュリティ標準を選択します。「制限付き」プロファイルでは、より強固なセキュリティが提供されます。
kubectl label namespace default pod-security.kubernetes.io/enforce=restricted
次に、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
次に、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 が適用されていることを検証する別の「ユーザー」アカウントを作成する必要があります。
これを行うには、次のコマンドを実行します。
gcloud iam service-accounts create demo-developer
(出力)
Created service account [demo-developer].
次に、以下の各コマンドを実行して、クラスタの操作と 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"
次のコマンドを実行して、サービス アカウントの認証情報ファイルを取得します。
gcloud iam service-accounts keys create key.json --iam-account "demo-developer@${MYPROJECT}.iam.gserviceaccount.com"
kubectl
を構成して、このサービス アカウントとして認証します。
gcloud auth activate-service-account --key-file=key.json
次のコマンドを実行して、クラスタと通信する際にこれらの認証情報を使用するように kubectl
を構成します。
gcloud container clusters get-credentials simplecluster --zone $MY_ZONE
基盤となるホストのファイルシステム /
を、コンテナ内の /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
この出力では、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")
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 に対して利用できるアクセスをプローブ、悪用してからクラスタを強化し、悪意のあるアクションが実行できなくなっていることを確認しました。
次のステップと詳細情報
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 の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。