Mission-Street.

2023-10-09

「AWSではじめるインフラ構築入門」をGCPに読み替えてやってみる その3

前回の続き
勉強メモなので間違ったことが書かれている可能性があります 🙏

第 5 章

踏み台サーバーの構築のお話なので割愛
パブリックなサブネットにスペック低めで配置して ssh できればいいのでそんなに書くことがないが、多少作業したことがあるので書いておく

VM を作ったら「ブラウザウィンドウで開く」から ssh できることを確認したが、現時点では外部からの接続に関して何も許可されていないので、VPC のファイアウォールに以下の設定を追加して VM に ssh できるようにする

  • 方向
    • Ingress(上り)
    • ややこしいけどここにわかりやすい図がある
  • 一致した時のアクション
    • Allow(許可)
    • ターゲット
      • タグの設定などはまだしてないので「ネットワーク上の全てのインスタンス」
    • ソースフィルタ
      • IPv4 範囲
      • 送信元 IPv4 範囲
        • 35.235.240.0/20
          • ブラウザウィンドウから ssh した場合、いろいろプロキシされて、最終的に Google が管理しているこの IP 範囲の IP を使って接続される
          • 本運用する場合は会社の固定 IP とかに設定しましょう
    • ターゲットフィルタ
      • 送信先 IPv4 範囲
        • 10.0.0.2
          • パブリックなサブネットに置いた踏み台 VM の IP だけを指定した
          • 謎なんだけど、停止して VM に 10.0.0.3 という IP を付与しようとしたらエラーになる(指定できる IP の範囲に入ってるはずだし、原因がわからん)
            • 新規に 10.0.0.3 を付与した VM を作成すると作れるので、編集でローカルの IP 変えられないっぽい
        • なお、VM を作成するとサービスアカウントも作成される？(自分で作成した覚えがないので、どのタイミングで作成されたのか不明)のでそれを指定してもよい
          • が、デフォルトで付与されるサービスアカウント名だとめっちゃ判別し辛いので、ちゃんと IAM のサービスアカウントのページから変更しておくとよい
        • さらに、VPC のファイアウォールルール作成時に指定できるネットワークタグでも指定できる
          • その場合 VM 側でも、ファイアウォールルールで指定したネットワークタグを指定しなければならない
          • これ微妙なのが、ネットワークタグはどこかに保存されて管理されているわけではなく、ファイアウォールルールとか VM とかで自由記述で入力するので、候補とかから選択できないところ(typo とかあると死ぬ)
      • サービスアカウントとネットワークタグのどちらで管理するのが良いのか？という話はここに判断基準が書いてあって、サービスアカウントがおすすめっぽい
        • まぁネットワークタグはいろいろ微妙な雰囲気があるので納得
    • 外部 IPv4 アドレス
      • 外部 IP 持ってないと ssh できないので、エフェメラルを選択
    • 指定したプロトコルとポート
      • TCP で 22 番ポートを指定

ちなみに GCP プロジェクトを作成した時に存在する、default VPC にはこの辺の設定が最初から存在するので、特に自分で設定を追加しなくても ssh できたりする

あと、VM を起動しっぱなしにしておくとお金がかかるので、実験終わったら停止するのを忘れないようにしましょう

スキップした第 4 章のセキュリティグループ

踏み台サーバーの用意もできたので、そろそろスキップしたセキュリティグループについても見ていく
読み進めると AWS のセキュリティグループでは

  • ポート番号
  • IP アドレス

で制御することができると書かれているので、GCP では ↑ で少し書いたファイアウォールルールがそれに相当しそうな雰囲気を感じる
AWS で言うところのインバウンドは、GCP で言うところの Ingress で、アウトバウンドが Egress となる

本では ssh 用のセキュリティグループとロードバランサ用のセキュリティグループの 2 つを作成していて、↑ で ssh 用のファイアウォールルールは作成したので、ロードバランサ用のファイアウォールルールを作れば良さそう
ただ、それもサーバー立てて接続できないことを確認した後にルールを追加したいので、一旦ここではスルーする

第 6 章

踏み台サーバーと同じノリで Web サーバーを立てていく
web サーバーは private なサブネットに配置し、外部 IP は持たせない(踏み台サーバーを経由して接続する)

どうやら GCP の場合、本に書いてあるような config ファイルを用意してあれこれ書かなくても、踏み台サーバーに ssh した後 gcloud コマンドで、ローカル IP を使ってプライベートなサブネットに配置した VM にアクセスできる模様

ということでこんな感じ ↓ でやってみたところ

gcloud compute ssh VM_NAME --internal-ip

以下のエラーで接続できなかった

ERROR: (gcloud.compute.ssh) Could not fetch resource:
 - Request had insufficient authentication scopes.

これはどうやら踏み台サーバーが、接続しようとした VM に対して権限が足りていないために発生するエラーっぽい
https://blog.g-gen.co.jp/entry/vm-api-iam

なので、一旦踏み台サーバーを停止して、踏み台サーバー設定の「アクセス スコープ」を「API ごとにアクセス権を設定」にし、「Compute Engine」に対して読み書きを許可した
ssh キーを読んだり書いたりするので、読み書き両方の権限がないとダメ(↓ のようなエラーが出る)

ERROR: (gcloud.compute.ssh) Could not add SSH key to instance metadata:
 - Request had insufficient authentication scopes.

ということでもう一度やってみたけど、まだダメらしい

ssh: connect to host ローカルIP port 22: Connection timed out
ERROR: (gcloud.compute.ssh) Could not SSH into the instance.  It is possible that your SSH key has not propagated to the instance yet. Try running this command again.  If you still cannot connect, verify that the firewall and instance are set to accept ssh traffic.

ファイアウォールルールが怪しいので見ていくと、↓ の設定で弾かれていそうだった

  • ターゲットフィルタで踏み台サーバーのサービスアカウントが指定されている
    • これだと踏み台サーバー以外への ssh は全部弾かれるのでダメそう
    • ということでターゲットフィルタには、今回接続したいプライベートなサブネットに配置したサーバー 2 台のローカル IP と、踏み台サーバーのローカル IP を追加した
  • ソースフィルタ
    • Google のパブリック IP である 35.235.240.0/20 を指定していたけど、踏み台サーバーまではいいけど、踏み台から別のサーバーに接続する際にこの IP ではなくなるので、弾かれていそう
    • ということでソースフィルタの IP を 0.0.0.0/0 にして全ての接続元を許可するようにした

↑ の設定を調整したところ、無事踏み台サーバーと同じ zone に配置されている VM には接続することができた
別の zone に配置した VM にはこの方法では接続できなかったので、別の方法を考える必要があるが、多分以下のどちらかの方法になりそう

ここでも言及されているように、GCP では踏み台サーバーを用意しないのがベストプラクティスかもしれない

IAP は是非とも試してみたいので、次回はそこからやろうと思います

ここまでの構成図

踏み台サーバーが sample-subnet-public01 に増えたくらいなので図は略