Google Cloud VPC への開発者のリモートアクセス：経路を選ぶ

開発者が必要とするのは SSH セッションが一つ、データベースのポートが一つ、あるいは十数のプライベートサービスへの広いアクセスですが、どの依頼も同じ問いのように見えます。そうではありません。宛先、プロトコル、関与する身元によって、どの Google Cloud のアクセス経路が適切かが決まり、既定で最も広いものを選ぶと、負う必要のなかった作業が生まれます。

宛先とプロトコルを書き出す

作業に本当に必要なプライベートアドレス、ポート、プロトコルを列挙し、その後、別々に認証すべき身元を印付けます。データベースのポートとプライベート DNS ゾーンは別の要件であり、UDP サービスは下の選択肢の一つを完全に除外します。書かれた一覧は、何を与えていないかも示します。レビュー担当者が尋ねるのはそこです。

リスナーを開く前にこれを行います。一覧は後に受け入れテストになり、狭いトンネルと、たまたま動く広いトンネルを見分ける唯一の確実な方法です。

少数の TCP サービスには IAP

Identity-Aware Proxy の TCP 転送は、サービスをインターネットに晒さずに、対象となる VM リソースへの認証済みトンネルを提供します。日常的な形はgcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-aで、単一のポートはgcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-aでローカルに転送できます。

呼び出し元に IAP トンネルのアクセス役割が必要で、ファイアウォールが IAP の送信元範囲を許可し、宛先がインスタンス上で到達可能であるという三つの条件が揃う必要があります。トンネルを作成する権限は、データベースの資格情報でも SSH ログインでも RDP セッションでもないため、アプリケーションの認証は本来の場所に置いてください。

IAP の TCP 転送は第三層の VPN ではありません。TCP を選択した宛先へ運ぶもので、任意の IP トラフィックや UDP は運ばず、アプリケーションが多くのサービスにまたがるプライベート DNS を必要とする場合には向きません。

より広い到達性のためのリモートアクセス VPN

複数の宛先、プロトコル、プライベート DNS ゾーンが必要な場合、VM または対応アプライアンス上で明示的に管理するリモートアクセス VPN のほうが適した形です。その展開は Google 管理の Cloud VPN とは別物で、クライアント身元の登録、ソフトウェア更新、クライアント経路、VPC の戻り経路はあなたが所有します。

公開リスナーだけでなく、一覧全体を計画してください。トンネルプール、そこへの VPC 経路、転送制御、DNS 解決、サービスごとのアクセスポリシーを含めます。接続はできるが内部名を解決できない VPN は、決して接続しない VPN と同じくらい完全に開発者の作業を失敗させます。

Cloud VPN はサイトのゲートウェイであり、ノート PC のプロファイルではない

Google Cloud VPN は IPsec でピアゲートウェイを接続し、そのよくある質問は、そのサイト間の役割をクライアントからゲートウェイへのアクセスから切り分けています。トンネルを作っても、従業員がノート PC に取り込むプロファイルはできません。誰かが Cloud VPN のプロファイルを求めたとき、この区別が重要になります。答えは別の製品です。

ゲートウェイが得意なのは、オフィスネットワークの背後にあるマシンに VPC への経路を与えることです。従業員ごとに認証するわけでも、アプリケーションの権限を与えるわけでもないため、それらのポリシーは身元ごとに適用できるネットワーク層とアプリケーション層に残ります。

検証して記録する

まず最も狭い宛先を試し、次に DNS を必要とする宛先、そして拒否されたままであるべき宛先を試します。管理者のワークステーションでの成功は別のネットワークを持つ開発者のノート PC についてはほとんど何も証明しないため、各テストは本番でその経路を使うのと同じクライアントから実行してください。

選んだモデル、それが対象とする宛先、認証する身元、経路が利用できないときの失敗時の挙動を記録します。その記録が、次の依頼が文書化された設計に宛先を一つ追加するのではなく、トンネルを黙って広げてしまうのを防ぎます。