ACE#01

ACE#01 – ACE#02
R – F

お疲れ様でした!ACE#01のクイズ終了しました。

解答スコアは %%SCORE%% / %%TOTAL%% 問正解です。

%%RATING%%


あなたの選択した答えは強調表示されています。
問題1
特定のデプロイメントのログにいくつかのエラーが表示されています。問題は、エラーを発生させている「ad-generator」という名前の Pod に絞られています。エンジニアは、他の環境でエラーを再現することができません。彼らは、「コンテナに 5 分間接続する」ことができれば、根本的な原因を解明できると言っています。どのような手順を踏めば、コンテナに対してコマンドを実行できるようになりますか?
A
kubectl run コマンドを使用して、そのコンテナ上でシェルを実行します。
B
kubectl exec -it ad-generator -- /bin/bash コマンドを使用して、そのコンテナ上でシェルを実行します。
C
kubectl exec -it -- /bin/bash コマンドを使用して、そのコンテナ上でシェルを実行します。
D
kubectl run ad-generator /bin/bash コマンドを使用して、そのコンテナ上でシェルを実行します。
問題 1 の説明および補足 
実行中のコンテナに接続する
kubectl exec は、インタラクティブモードで Pod 上のシェルを開くのに役立ちます。

※実行中のコンテナに接続する
Pod へのシェルを開きます。
kubectl exec -it pod-name -- /bin/bash
Pod 内にコンテナが複数ある場合は、-c container-name を追加します。
これで、そのコンテナから bash コマンドを実行できます。ネットワークのテストや、アプリケーションで使用されているファイルやデータベースにアクセスできるかどうかを調べることができます。
参考URL:実行中のコンテナに接続する
問題2
あなたの会社には、インターネットに公開したくない内部バックエンドがいくつかあります。どのようにして外部への露出を減らしつつ、リモートワーク時やメンテナンス作業時のリソースへのアクセスを維持することができますか。
A
外部 IP アドレスを削除し、Cloud Shell を使用して内部のみのリソースにアクセスします。
B
外部 IP アドレスをロードバランサの背後に隠し、ロードバランサのアクセスを社内ネットワークに制限します。
C
外部 IP アドレスを削除し、リモートの従業員が会社の VPN 接続にダイヤルしてメンテナンス作業を行います。
D
外部 IP アドレスを削除し、踏み台ホストを使用して内部のみのリソースにアクセスします。
問題 2 の説明および補足 
踏み台インスタンス
インスタンスから外部 IP アドレスを削除して、インターネットからアクセスできないようにし、サーバーにログインできるように踏み台ホストを用意することがベストプラクティスです。

※踏み台インスタンス
次の図に示すように、踏み台インスタンスは、プライベート ネットワーク インスタンスを含むネットワークへの外部に面するエントリ ポイントを提供します。


このホストは、要塞化や監査のための単一の場所を提供します。また、SSH 通信を有効または無効にするために開始および停止できます。踏み台インスタンスを使用すると、外部 IP アドレスがない VM に接続できます。このアプローチでは、開発環境に接続するだけでなく、追加のファイアウォール ルールを構成しないで外部アプリケーションのデータベース インスタンスを管理できます。

踏み台インスタンスの完全な強化は、本ドキュメントの範囲外ですが、実施する最初のステップには以下のものが挙げられます。

・要塞と通信できるソース IP の CIDR 範囲を制限します。
・踏み台インスタンスからのみプライベート VM への SSH トラフィックを許可するように、ファイアウォール ルールを構成します。

デフォルトでは、VM 上の SSH は、認証用に秘密鍵を使用するように構成されます。踏み台インスタンスを使用する場合、まず踏み台インスタンスにログインし、次にターゲット プライベート VM にログインします。このように、踏み台インスタンスが「ジャンプ サーバー」と呼ばれる理由である 2 段階ログインがあるため、ターゲット マシンにアクセスする方法として、ターゲット マシンの秘密鍵を踏み台インスタンスに保存する代わりに ssh 転送を使用する必要があります。これは、踏み台インスタンスとターゲット VM に同じ鍵のペアを使用する場合でも必要です。踏み台インスタンスは、鍵ペアの公開鍵にしか直接アクセスできないためです。
参考URL:踏み台インスタンス
問題3
HTTP トリガーに応答し、JSON 形式で一部のデータを返す Cloud Functions のコードを作成しました。このコードはローカルでテストされ、動作しています。Google Cloud 内で関数を作成するには、どのコマンドを使用しますか?
A
gcloud function deploy
B
gcloud functions deploy
C
gcloud function create
D
gcloud functions create
問題 3 の説明および補足 
gcloud functions deploy
gcloud functions deploy コマンドを使用してコードをデプロイすることができます。

※ローカルマシンからのデプロイ
デプロイは、関数のソースコードを含むアーカイブを Google Cloud Storage バケットにアップロードすることで機能します。関数のソースコードを GitHub や Bitbucket などのソース リポジトリからデプロイする場合は、Google Cloud Source Repositories を使って、リポジトリのブランチやタグから直接関数をデプロイできます。
参考URL:ローカルマシンからのデプロイ
参考URL:Cloud Functions のデプロイ
参考URL:Cloud Source Repositories からのデプロイ
参考URL:gcloud functions deploy
問題4
Google Kubernetes Engine (GKE) 上にプロダクトを構築しています。GKE のクラスタは 1 つです。各顧客の Pod はそのクラスタで実行されており、顧客は Pod 内で任意のコードを実行できます。顧客の Pod 間の分離を最大化する必要があります。どのように対応しますか。
A
GKE ノードに cos_containerd イメージを使用します。顧客の Pod の仕様に cloud.google.com/gke-os-distribution: cos_containerd という値の nodeSelector を追加します。
B
gVisor でサンドボックスを有効にした GKE ノードプールを作成します。顧客の Pod の仕様にパラメータ runtimeClassName : gvisor を追加します。
C
Binary Authorization を使用して、顧客の Pod が使用するコンテナイメージのみをホワイトリストに登録します。
D
Container Analysis API を使用して、顧客の Pod が使用するコンテナの脆弱性を検出します。
問題 4 の説明および補足 
GKE Sandbox
ランタイム の gVisor を備えた GKE Sandbox は、ノードとコンテナに分離のレイヤーを提供します。gVisor はデフォルトのノードプールでは有効にできず、新しいノードプールを作成する必要があります。

※GKE Sandbox
GKE Sandbox は、オープンソースのコンテナ ランタイムである gVisor を使用して、アプリケーションの変更やコンテナとの対話方法を変更することなく、コンテナを追加の分離レイヤで実行します。gVisor はユーザー空間のカーネルを使用してシステムコールをインターセプトして処理することで、コンテナとホスト間のやり取りを減らし、攻撃にさらされる可能性を低減します。一方で、GKE Sandbox はマネージド サービスとしてこのような内部機能を抽象化するため、複数の保護レイヤを 1 ステップで簡素化できます。
参考URL:GKE Sandbox

GKE Sandbox を有効にするには、ノードプールを構成します。デフォルトのノードプール(クラスタの作成時に作成される最初のノードプール)は GKE Sandbox を使用できません。クラスタの作成時に GKE Sandbox を有効にするには、クラスタを作成するときに 2 つ目のノードプールを追加する必要があります。
参考URL:新しいクラスタの場合

※gVisor
gVisor は、セキュリティーと効率性、使いやすさに注力したコンテナーサンドボックスである[1][2]。Google によって開発され、2018年5月に発表された[1][2]。gVisor は約 200 のLinuxシステムコールをユーザースペースで実装しており、Linuxカーネル上で直接実行され名前空間を分離した Docker コンテナーと比べて、より安全である[3][4]。Linuxカーネルと比較して、gVisor はメモリー安全なプログラミング言語である Goで書かれており、C で書かれたソフトウエアが陥りがちな失敗を防止している
参考URL:gVisor

※Pod
Pod は、Kubernetes でデプロイできる最小かつ最も基本的なオブジェクトです。Pod は、クラスタ内で実行されるプロセスの単一インスタンスを表します。
参考URL:Pod
問題5
新しいネットワークとサブネット内にインスタンスを設定しました。ファイアウォール ルールは、以下のようにネットワーク内のすべてのインスタンスをターゲットにするように設定されています。
NAME:denyall | NETWORK:devnet | DIRECTION:INGRESS | PRIORITY:1000 | DENY:tcp:0-65535,udp:0-6553
NAME:open-ssh | NETWORK:devnet | DIRECTION:INGRESS | PRIORITY:5000 | ALLOW:tcp:22
しかし、SSH 経由でインスタンスに接続しようとすると、接続がタイムアウトします。最も可能性の高い原因は何ですか?
A
deny ルールが allow ルールより優先されるため、SSH は拒否されます。
B
SSH が拒否され、allow ルールを有効にするためにはインスタンスの再起動が必要になります。
C
ファイアウォール ルールをインスタンスに直接適用する必要があります。
D
SSH 鍵がインスタンスにアップロードされていません。
問題 5 の説明および補足 
VPC ファイアウォール ルール 優先度
ファイアウォール ルールは優先度に従って適用され、deny ルールは allow ルールと比較して優先度が高いため、SSH アクセスは拒否されます。

※VPC ファイアウォール ルール 優先度
ファイアウォール ルールの優先度は、0 から 65535 までの整数です。小さい整数が高い優先度を示します。ルールの作成時に優先度を指定しない場合、優先度 1000 が割り当てられます。ファイアウォール ルールの相対的な優先度によって、他のルールに対して評価されたときに、適用されるかどうかが決まります。評価ロジックは次のように機能します。

・特定のタイプのトラフィックで、ターゲットに適用可能な優先度が最も高いルールが優先されます。ターゲットの特性は関係ありません。たとえば、すべてのターゲット向けの、特定の宛先ポートとプロトコルで優先度の高い上り(内向き)ルールにより、特定のターゲット向けに同様に定義された、同じ宛先ポートとプロトコルの優先度の低いルールがオーバーライドされます。
・プロトコルと宛先ポートの定義がより一般的であっても、特定のプロトコルと宛先ポートの定義に適用可能な、優先度が最も高いルールが優先されます。たとえば、特定のターゲット向けの、すべてのプロトコルと宛先ポートでトラフィックを許可する優先度の高い上り(内向き)ルールにより、同じターゲット向けの、TCP 22 を拒否する優先度の低い上り(内向き)ルールはオーバーライドされます。
・deny アクションのルールが別の allow アクションのルールをオーバーライドするのは、2 つのルールの優先度が同じ場合に限られます。相対的な優先度を使用すると、deny ルールをオーバーライドする allow ルールや、allow ルールをオーバーライドする deny ルールを作成できます。
・同じ優先順位と同じアクションを持つルールは同じ結果になります。ただし、評価中に使用されるルールは不確定です。通常、ファイアウォール ルールのロギングを有効にしている場合を除き、どのルールが使用されても問題はありません。一定の明確な順序でファイアウォール ルールが評価されていることをログで確認できるようにするには、これらのルールに一意の優先順位を割り当てます。
参考URL:VPC ファイアウォール ルール 優先度

■以下は間違いです。
・ファイアウォール ルールをインスタンスに直接適用する必要があります。
→ファイアウォールはインスタンスに直接適用されるのではなく、ネットワーク タグを介して適用されるため間違いです。

・SSH 鍵がインスタンスにアップロードされていません。
→SSH がキーを自動的に生成し、インスタンスに転送するため間違いです。

・SSH が拒否され、allow ルールを有効にするためにはインスタンスの再起動が必要になります。
→ファイアウォール ルールは直接適用され、インスタンスの再起動を必要としないため間違いです。
問題6
あなたのチームは、サードパーティのモニタリングソリューションを使用しています。それを Kubernetes Engine クラスタの全ノードにデプロイするように言われました。最良の方法は何ですか?
A
各ノードに SSH で接続し、モニタリングソリューションをインストールします。
B
モニタリング Pod を DaemonSet としてデプロイします。
C
Deployment Manager を使用して、モニタリングソリューションをデプロイします。
D
モニタリング Pod を StatefulSet としてデプロイします。
問題 6 の説明および補足 
DaemonSet
DaemonSet は、すべてのノード上で実行する必要があるアプリケーションやツールのデプロイに役立つため、モニタリング Pod を DaemonSet としてデプロイします。

※DaemonSet
他のワークロード オブジェクトと同様に、DaemonSet は複製された Pod のグループを管理します。ただし、DaemonSet は、クラスタ全体またはノードのサブセットに渡って、ノードあたり 1 つの Pod のモデルを維持しようとします。ノードプールにノードが追加されると、DaemonSet は必要に応じて自動的に新しいノードに Pod を追加します。
DaemonSet は、Pod テンプレートを使用します。これには、その Pod の仕様が含まれています。Pod 仕様によって、各 Pod の外観(コンテナ内で実行するアプリケーション、マウントするボリューム、ラベルとセレクタなど)が決定されます。
DaemonSet は、すべてのノードまたは特定のノードで実行する必要があり、ユーザーの介入を必要としない、進行中のバックグラウンド タスクのデプロイに便利です。このようなタスクの例としては、ceph などのストレージ デーモン、fluent-bit などのログ収集デーモン、collectd などのノード モニタリング デーモンがあります。
たとえば、すべてのノードでデーモンのタイプごとに DaemonSet を実行できます。または、1 つのタイプのデーモンに対して複数の DaemonSet を実行することもできますが、ハードウェア タイプやリソースニーズによって異なる設定を使用することもできます。
参考URL:DaemonSet

■以下は間違いです。
・Deployment Manager を使用して、モニタリングソリューションをデプロイします。
→Deployment Manager は Pod を制御しないため間違いです。
参考URL:Cloud Deployment Manager

・モニタリング Pod を StatefulSet としてデプロイします。
→ StatefulSet は状態を維持するのに役立つため間違いです。

※StatefulSet
StatefulSet は、スケジュールされた場所にかかわらず GKE が保持する一意で永続的な ID と固有のホスト名を持つ Pod のセットを表します。任意の StatefulSet Pod の状態情報やその他の復元データは、StatefulSet に関連付けられた永続ディスク ストレージに保持されます。
参考URL:StatefulSet

・各ノードに SSH で接続し、モニタリングソリューションをインストールします。
→実行可能なオプションではないため間違いです。
問題7
あなたの組織では、将来の法的手続きにおける分析のために、すべてのアプリケーションからのメトリクスを 5 年間保持する必要があります。どのアプローチを使用する必要がありますか?
A
すべてのプロジェクトに Cloud Monitoring (Stackdriver Monitoring) を構成し、Google Cloud Storage にエクスポートします。
B
すべてのプロジェクトに Cloud Monitoring (Stackdriver Monitoring) を構成し、BigQuery にエクスポートします。
C
すべてのプロジェクトに Cloud Monitoring (Stackdriver Monitoring) をデフォルトの保持ポリシーで構成します。
D
セキュリティチームに各プロジェクトのログへのアクセスを許可します。
問題 7 の説明および補足 
Cloud Monitoring (Stackdriver Monitoring)
Cloud Monitoring (Stackdriver Monitoring) のメトリクスは、BigQuery または Google Cloud Storage にエクスポートできるため正解です。また、将来の分析が必要なため、BigQuery が適しています。
参考URL:Google Cloud のオペレーション スイート(旧称 Stackdriver)

■以下は間違いです。
・すべてのプロジェクトに Cloud Monitoring (Stackdriver Monitoring) を構成し、Google Cloud Storage にエクスポートします →Google Cloud Storage には分析機能がないため間違いです。
参考URL:Google Cloud Storage

・すべてのプロジェクトに Cloud Monitoring (Stackdriver Monitoring) をデフォルトの保持ポリシーで構成します。
→Cloud Monitoring は 5 年間データを保持できないため間違いです。
参考URL:データの保持

・セキュリティチームに各プロジェクトのログへのアクセスを許可します。
→プロジェクトのログは Cloud Monitoring で維持され、データ保持機能が制限されているため間違いです。
お疲れさまでした。 クイズが完了したら、「クイズの結果を見る」ボタンをクリックしてください。あなたが完了していないアイテムは、間違いのマークがされます。 クイズの結果を見る
問題は全部で 7 問。全て答えられるように頑張りましょう!
リスト
戻る
網掛け部分は完了した項目です。
12345
67ゴール
戻る
error: コンテンツの複製・転用は禁止されております。