はじめに
Google SkillsでGoogle Cloudのセキュリティ設定を扱う学習をした。この記事は、IAM、GKEのネットワーク分離、クラスタへの接続について、自分が理解した点を整理したメモ。
公開にあたって: 教材の設問、指定値、解答、採点条件、画面は再現していません。内容をぼかし、操作手順ではなく一般的な確認事項として書き直しています。ラボの解答や、実環境にそのまま適用できる構成例ではありません。
権限は「誰に・何を・どこまで」を分けて考える
IAMでは、権限の一覧だけでなく、付与先のIDと付与範囲を合わせて確認する。用途が異なる処理に同じサービスアカウントを使い回さず、必要なアクセスだけを割り当てる考え方が重要だった。
カスタムロールは細かい権限を定義できる一方、必ず作成すべきものではない。要件を満たす事前定義ロールがあるかを先に確認し、必要以上に広い場合にカスタムロールを検討する。権限の追加・変更時は、対象リソースと影響範囲も確認したい。
限定公開クラスタはアクセス経路まで設計する
GKEのネットワーク分離を考えるときは、ノードへのアクセスとコントロールプレーンへのアクセスを混同しない。どの端末・ネットワークから管理操作を行うか、利用するエンドポイントは何か、必要な通信が通るかを事前に整理する。
踏み台を経由する構成は一つの例だが、すべてのクラスタで必須とは限らない。エンドポイント方式や組織のネットワーク方針によって適切なアクセス方法は変わる。接続元を制限する場合も、IPアドレスだけでなく認証と権限設定を別に確認する。
接続できないときの切り分け
クラスタへの操作が失敗した場合、設定を闇雲に緩めず、次の観点を分けて調べる。
- 操作対象: 想定したプロジェクト、クラスタ、ロケーションを参照しているか
- 接続経路: 利用する端末から選択したエンドポイントに到達できるか
-
認証:
kubectlに必要な認証プラグインと認証情報があるか - 認可: 認証されたIDに、実行する操作の権限があるか
作業端末を切り替えたときは、以前のシェルで設定した環境変数やkubectlのコンテキストを引き継いでいると決めつけない。確認用コマンドの例は次のとおり。これらは状態を表示するためのもので、クラスタの作成や権限の変更は行わない。
gcloud config get-value project
gke-gcloud-auth-plugin --version
kubectl config current-context
認証プラグインの導入方法は、OSとGoogle Cloud CLIの導入方法によって異なるため、その環境向けの公式手順を確認する。
アプリの確認範囲を決める
クラスタ上でテスト用のワークロードを動かす場合は、「デプロイできた」「Podが起動した」「利用者からアクセスできた」を別々の確認項目として扱う。起動確認だけが目的なら、外部公開を前提にしない。公開の要否、通信経路、利用するイメージの出所を確認してから次の設定に進む。
まとめ
今回の学習で整理できたのは、IAMの権限、ネットワークの到達性、Kubernetesの認証・認可は別の確認事項だという点。接続できないときにアクセス制限を広げるのではなく、どの段階で失敗しているかを切り分ける。
※ このメモは教材の利用条件や画像の権利について判断するものではありません。公開する場合は、教材の転載やスクリーンショットの扱いを別途確認してください。