Cloud SQL Auth Proxy とデータベースへの直接 VPN ルートの比較
Auth Proxy と直接 VPN ルートは同じ問題の別々の半分を解きます。まず connector の認可、ポート、データベースへのログインを比較してください。
VPN につないだノート PC からプライベートな Cloud SQL インスタンスに到達する方法は、まともなものが二つあります。一つは、すでにあるルートを使ってインスタンスのプライベートアドレスへ直接接続する方法です。もう一つは Cloud SQL Auth Proxy で、これは loopback で待ち受け、Cloud SQL への接続を自分で開きます。両者は競合する製品というより、資格情報を誰が持つのか、ルートを誰が持つのかという問いへの二つの異なる答えです。選び方を誤ると、たいていはネットワーク障害のように読める認可エラーとして表面化します。
ここでは、チームの前に出すとしたらこの比較を書き、そのうえで実際に判断を決める確認項目を続けます。
同じインスタンスへの二つの経路
直接経路は、自分のネットワークからプロジェクトの VPC へ入る private-services-access ルートを使います。クライアントはインスタンスのプライベートアドレスと PostgreSQL で話し、接続はルーティング、firewall ルール、データベースの資格情報の上で生きたり死んだりします。
proxy 経路は同じルートを使いますが、ローカルなプロセスを一つ追加します。proxy はアプリケーションの default credentials で Google API に対して認証し、connector 経由でインスタンスへの接続を開き、クライアントが PostgreSQL として扱う loopback ポートを提供します。二つのホップが三つになり、真ん中のホップが IAM 認可を担います。VPN ルートは依然として自分の保守対象であり、proxy はそれをこの確認の代わりとは決して見なしません。
それぞれの経路が実際に認可するもの
いちばん重要な違いは、各選択肢が自分の代わりに何を認可できるかです。
| Question | Direct private IP | Auth Proxy |
|---|---|---|
| Who proves identity to the network | Your client, through the VPN and a database login | The proxy, through IAM to Google's API |
| IAM role needed for the connector | None | Cloud SQL Client or equivalent |
| Database user authentication | Always required | Still required unless IAM database authentication is enabled |
| Shape of the local leg | Client to instance | Client to loopback, proxy to instance |
proxy の IAM 確認とデータベースへのログインは別々の関門であり、片方を通ってももう片方は開きません。proxy を有効にして、アプリケーションのアカウントはもう不要だと決めつけたチームは、ネットワークとは何の関係もないパスワード失敗に半日を費やすことになります。
ポートとルートを並べて見る
proxy には API 用の外向き TCP 443 と、インスタンス接続用の TCP 3307 が必要で、どちらも Google の Auth Proxy の概要 に書かれています。自分の VPN ルートが担うのは後者で、前者は通常どおりの経路から出ていきます。
直接接続では、インスタンスの PostgreSQL ポートがプライベートルート越しに届く必要があり、これはまったく別の firewall の話になります。ネットワークチームがクライアントサブネットからの外向き 443 しか許していないなら、proxy はルールを変えずに収まり、直接経路は収まりません。この一つの事実が、どんなアーキテクチャの好みよりも頻繁に選択を決めます。
どちらの経路も、インスタンスにパブリックアドレスがあることを要求しませんし、追加する理由にもなりません。
proxy が役に立たない場面
proxy は欠けたルートを直しません。private-services-access ルートが無い、あるいは VPN がそれを運んでいない場合、ローカルの待ち受けがそこに座ったままなのに connector は失敗します。これが混乱しやすいところです。
アプリケーションと proxy の間の区間も守りません。ノート PC 一つならその区間は loopback で問題ありません。同僚に届かせようとして待ち受けを wildcard アドレスに束ねると、認証のないデータベースゲートウェイを作って、それを便利と呼ぶことになります。loopback に置いたまま、同僚には自分の資格情報を取ってもらいましょう。
また、Private Service Connect と private services access を入れ替え可能にはしません。PSC インスタンスには独自の DNS の取り決めと、--private-ip 形式ではなく --psc の呼び出しが必要です。
選び、どちらの場合でも検証する
経路に IAM を入れたい、短命な資格情報を使いたい、内向きの firewall を変えたくないなら proxy を選びます。
対応しているクライアントがすでに強いデータベース資格情報を持ち、ネットワークチームがポートを開けるなら直接経路を選びます。どちらでも、接続成功ではなく実際のクエリで検証します。接続し、既知のテーブルに対して読み取りを一つ実行し、サーバーが自分のセッションをどう見ているかを確かめます。
VPN の再接続後は、期限切れの資格情報、欠けたプライベートルート、データベースへのログイン拒否を三つの異なる障害として扱います。ネットワークの問題はそのうち一つだけで、firewall ルールの変更につながるべきも一つだけです。