🍕

GCPの開発環境でPrivateなCloud SQLを直接触る為に踏み台を作った

いばらき2022/10/20に公開

今回は、Google Cloud(GCP)のDBの話です。

はじめに

やりたいこと

開発時にGPC上のprivateなCloud SQL(PostgreSQL)のデータを直接操作したい

前提となる状況

開発環境を作る時にセキュリティの教科書的な設定によりDBアクセスはprivate接続のみにしてしまったため、ローカルのPCからDBに直接アクセスができない状況

やること

開発時にDBを直接触れないのはツライので、踏み台を立ててOverSSHでDBを操作できるようにする

必要なもの

GCP側のインフラ構築手順

前提

VPC及びCloud SQLは作成済とし、Cloud SQLはprivate接続のみができる設定とします

GCEのインスタンスの作成及び設定

GCEのVMインスタンス用にサービスアカウントを作る

まずは、GCEのVMインスタンス用のサービスアカウントを作ります。

  • IAM と管理 -> サービスアカウント -> サービス アカウントの作成
  • 適当にロールをつけて作成すればOK

VPCのFirewallの設定

  • VPCのFIrewall設定で、上記で作成したサービスアカウント向けの22ポートを許可します。
    • ターゲットタイプをサービスアカウントにして、ターゲットサービスアカウントに上記で作成したサービスアカウントを指定します
    • 今回作るVMインスタンスのみに対するFirewallのルールを作りたかったので、先ほど個別にサービスアカウントを作成しました

GCEのVMインスタンスを作る

続いて、Cloud SQLと同じVPC上にVMインスタンスを立てます。
先程作成したサービスアカウントを紐付けてください。
普通に作ればいいだけなので詳細は省略しますが、1点だけ注意点として、使用するイメージはContainer Optimized OSにします。Cloud SQL Auth ProxyをDockerで動かす為です。

GCEのVMインスタンス上で、Cloud SQL Auth Proxyのコンテナを動かす

公式手順はこちら
https://cloud.google.com/sql/docs/sqlserver/connect-docker?hl=ja&_ga=2.28750652.-1214863989.1658407222

下記にざっくりとした手順を記載しますが、詳細は公式手順を参照してください

  • ローカルPCから、gcp-cliを使ってVMに接続する
gcloud compute ssh --zone=asia-northeast1-b (インスタンス名)
  • 公式の手順の6を参照し、Cloud SQL Auth Proxy用のサービスアカウントを作成し鍵のjsonをVMのインスタンス上に保存する
  • ブラウザからGCEのVMのインスタンス設定に戻り、自動化の起動スクリプトに鍵のjsonを指定してdockerの起動コマンドを書く
docker run -d \
  -v (VM上の鍵のjsonのpath):/config \
  -p 127.0.0.1:5432:5432 \
  gcr.io/cloudsql-docker/gce-proxy:1.32.0 /cloud_sql_proxy \
  -instances=(cloud SQLインスタンスの接続名) -credential_file=/config

  • 再起動すれば、コンテナーが起動している

以上で設定は完了です

SQLに接続したい開発者がやること

踏み台のIPアドレスを確認する

  • GCPコンソールに入って、GCEのVMのインスタンスのPublic IP(外部IP)を確認する

sshで踏み台へアクセスするための鍵を作る

適当なDBのクライアントツールでsshトンネリングでDBにアクセスする

主な設定情報は、以下のようになります。

  • HOST : 127.0.0.1
  • PORT : 5432
  • SSH Host : GCEのVMのIP
  • SSH PORT : 22
  • SSH Key : 上記の初回ログイン時に自動で作られたsshの鍵

HOSTが127.0.0.1になる点は注意しましょう。

コメント

  • 教科書的には、セキュリティのためにDBはprivateにしましょうなんですけど、開発時はなんだかんだでDBを直接触りたいのでprivateにすると結構面倒くさいなぁと感じました。データの重要性次第では開発環境はpublicでも良いかもしれません。publicでも認証は必要なので最低限のセキュリティはありますし。
    • ただし、何れにしても本番はprivateにするべきであり、ネットワーク的な環境差を作りたくないので開発もprivateにしておきたいという思いもあります。
  • GCPではAWSと違ってサブネットにpublicとprivateの概念がないことに最初混乱しました。AWSとGCPは似ている点が多いけどネットワーク周りはちょっと違いそうですね。勉強しないと。。。
NCDCエンジニアブログ

NCDC株式会社( https://ncdc.co.jp/ )のエンジニアチームです。

Discussion

ログインするとコメントできます