お疲れ様です。インフラチームの山口です。 この記事は Enigmo Advent Calendar 2020の18日目の記事となります。
2020年はコロナ禍でほぼ全社的にリモートワークになったこともあり、 前職のネットワークエンジニアだった頃のWANやビデオ会議の思い出を思い返す機会が多い一年でした。 強く思い出に残っているのは大概、障害と機器の不具合などのトラブル系しかなく、それだけでお腹いっぱいになる感じです。
話は変わりますが、アドベントカレンダーは業務から少しずらした内容で書くポリシーなので、現行の業務とはあまり関係ない、リモートワークに伴ってよく起こりがちなネットワークのごまかしの話をします。 今年、私の業務何やってたかなというとEKSの運用サポートとオンプレの保守対応が多かったので、業務からずれた内容をエイヤで書き下します。
1.はじめに
本記事はオフィスおよびオンプレミスのDCのPublicIPのみをホワイトリストに登録したS3バケット上の画像を、リモートワーク下の各ご自宅から閲覧する方法を考えた際の検討事項を整理したものです。
IAP Connectorをタイトルに入れていますが、本記事内ではZero Trust的な機能は使用しません。 IAP ConnectorはGKEに簡単にデプロイできるNAT箱として使っています。 そのため、Beyond Corp Remote AccessやCloud IAPについても本記事では特に触れません。
2.問題設定と前提条件
問題設定とその問題を解くにあたっての前提条件(おもに弊社のVPN関連の構成など)を説明します。 まず、何をやりたいかの問題設定を概説し、その後に付随する前提条件を説明します。
2-1.問題設定
解きたい問題を以下に記載します。
2-2. 前提条件
2-1で説明した問題設定に加えて方法検討の際の制約になりうるNW構成などを思いつく限りに記載します。以降の節でなんやかんや本節の理由を参照して、対応案を絞っていきます。
- オンプレミスのDCにあるVPNサーバでL2TP/IPSecを終端する
- VPN接続後のクライアントPCの経路はスプリットトンネリング(トンネルインタフェースにはデフォルトルート向けてない)
- クライアントPCは、エンジニアはMacだが非エンジニアはWindows
- VPNサーバからクライアントに経路をpushすることは可能
- オンプレミス環境はパブリッククラウドに移行中のため余計なリソースを増やしたくない
また、概要を簡単に記載した図を以下に示します。
3.方法検討
検討した方法を以下表と図に記載します。 方法は3種類に大別されます。タイトルにIAP Connectorを試してみたと記載しているタイトルの通り最終的には、3bを選択することになるのは明白ですが、建前として各案のPros/Consを考えていきます。
| 案 | 小項目 | 方法 |
|---|---|---|
| 案1.愚直案 | S3バケットのIPアクセス制限に各自の自宅のPublicIPを登録する | |
| 案2.ルーティングでごまかし案 | 2a | VPNサーバでS3向けの経路をPushしDC経由にする |
| 2b | sshuttleなどを使用しクライアント側でルーティングを調整する | |
| 案3.Proxy建てる案 | 3a | DCにProxyを建てる |
| 3b | IAP ConnectorをProxyとして建てる&S3バケット側のホワイトリストに追加 |
案1.愚直案
S3バケット側で愚直に各ご自宅のPublicIPをホワイトリスト登録すればいいだけというのは、そのとおりでそれで済むならこの記事をグダグダ書いてる意味ないじゃんという形になってしまうので、半ば無理矢理感はありますが一旦は却下します。 これは人によって意見分かれそうですが、プライベートで契約しているPublicIPの情報をCloudFormationのテンプレートなどに書いて、Gitの履歴に残したくなさがあるので個人的には微妙かなという印象が強いです。
- pros
- 一番シンプル
- cons
- アクセスする社員の数増えたら運用手間かもしれない。
- そもそも、ご自宅が固定IPとは限らないケースもある。
- 現状はCloudFormationでS3バケット管理しているが、個人の自宅のPublicIPをテンプレートに残してしまうのって良いのか? なんか嫌じゃない?
案2. ルーティングでごまかし案
ルーティングでごまかし案は2a、2bに分かれます。 2aと2bの違いはルーティングの調整をVPNサーバ側で行うか、クライアントのPC側で行うかの違いです。
案2での基本方針は以下からS3で使用されるPublicIPのレンジを確認してそのIPレンジ向けの通信をDC経由にします。
2a、2bのpros/consを記載します。 正直自分しか使わないのなら他の環境に影響少なくて手軽な2bでローカルのPCでルーティングいじってごまかすぞ、となるのですが、 今回の要件的には他メンバーにも展開する可能性があるので却下します。 記事まとめている途中で、わざわざS3のPublicIPのレンジ全部経路切らなくてもDNS引いた結果をhostsに追加&それ向けのホストルートをトンネルインタフェースに切れば良いんじゃないかと思いましたが他の人に展開するという観点ではやっぱり却下です。
2a: VPNサーバでS3向けの経路をPushしDC経由にする
- pros
- クライアントPC側の作業は楽
- cons
- この要件のためだけにVPNサーバの経路調整したくない
- S3のPublicIPのレンジをすべてDC経由にした場合に意図しない影響って本当に出ないんだっけ?
- pros
2b: sshuttleなどを使用しクライアント側でルーティングを調整する
案3. Proxy建てる案
Proxy建てる案はどこにProxyを建てるかどうかで3a、3bに分かれます。 3aはDCにProxyを建てる案です。DCにnginxのProxy建ててアクセスしている実績はあるのですが、オンプレのリソースは極力減らしていっている状況なので却下します。
- 3a: DCにProxyを建てる
- pros
- VPNのルーティングは調整しなくて済む
- 同様のProxyはDCにも何台かすでにある
- cons
- DCに余計なリソースが増える
- 運用手間
- pros
- 3b: IAP ConnectorをProxyとして建てる&S3バケット側のホワイトリストに追加
方法決定
一旦案をまとめます。 5案だしましたが、以下の3案が確度高く現実的には行けそうな感じがします。 案1、案2bはこの検討時点では動作することが分かっていたので、案3bの構成の検討を次節で行います。 案3bの検討事項ではコスト面と動作確認がconsとして上がっていますが、本記事ではとりあえず動作確認だけを行います。
- 案1.愚直案
- とりあえずはこれできるけど面白みはない
- 案2b: sshuttleなどを使用しクライアント側でルーティングを調整する
- エンジニアは拾えるかつ楽だけど非エンジニアは拾えない
- 案3b: IAP ConnectorをProxyとして建てる&S3バケット側のホワイトリストに追加
- 検証はした方が良いが意外と楽にできそう
4.リソース作成・動作確認
本節では 案3b: IAP ConnectorをProxyとして建てる&S3バケット側のホワイトリストに追加 の説明を簡潔に行います。
IAP Connectorのデプロイは基本的には以下公式の手順に従います。
最終的な構成図を以下に示します。 構成上、Deployment Managerのテンプレートでは、IAP ConnectorのNAT後のPublicIPとGCLBにアサインするPublicIPも同じテンプレートでデプロイされてしまうようですが、以下の理由から、PublicIPはコンソールでリソースを作成しそれをテンプレートから参照するように修正しました。また、とりあえずぱっとデプロイできて動きだけ確認できればいいので、Terraformで作成する選択肢は取らず、雑にDeployment Managerのテンプレート一枚で作成しました。
- GKEクラスタはなにか問題が出たら潰して再構築する程度の温度感の運用を想定
- ambassadorのPodの問題判別やクラスタ運用は極力しない手抜き前提
- PublicIPはGKEクラスタと合わせて潰れてしまうとS3バケットのホワイトリスト設定やDNS設定が手間
- 所謂ライフサイクル異なるリソースは別テンプレートにというやつ(今回PublicIPはCLIでリソース作ったけれど)
5.まとめ
本記事では、IAP Connectorを容易にデプロイできるNAT箱として利用しました。 Cloud IAP側でZero Trust的な制御を入れたとしても、IAP ConnectorからS3バケットのアクセス制御は昔ながらのIP制限方式になってしまっているなど、ツッコミどころや深堀りする余地はありますが、 S3バケットの前段に設置する構成については、一応当初の目的通りの動作を確認できました。
また、この記事とは関係ない半ば余談の愚痴ですが、2020年の夏頃にIAP Connectorを検証したのですが、プロキシ先からのレスポンスの書き換えができなくて困って、IAP Connectorに対する熱が下がったという個人的な経緯もあり、VPNもしくは既存のProxyの置き換え手段として手放しで愚直に推せる仕組みではないなというのが率直な印象でした。ただ、活用できる局面は多そうなので、引き続き継続的にキャッチアップしていきたいなと思います。
しかしながら、面倒でもGKEにnginxのProxyを建ててそれをCloud IAPで守った方がIAP Connectorより融通聞くのではという気持ちもあり、目的とそれにかける手間のバランスを見極めるのは難しいなと思いました。結論は毒にも薬にもならない感じなのですが終わります。
明日の記事の担当は、データテクノロジーグループの竹田さんです。お楽しみに。
株式会社エニグモ 正社員の求人一覧
