ネットワーキング

開発速度に対応可能な開発者向けのネットワーキング

2023年12月7日

Google Cloud Japan Team

※この投稿は米国時間 2023 年 11 月 30 日に、Google Cloud blog に投稿されたものの抄訳です。

共有 VPC では、最小特権の原則に従い、一元化されたネットワークチームとセキュリティチームのみがホストプロジェクトでネットワークインフラストラクチャを作成および管理する権限を持ちます。一方、開発者には、コンピューティング、ストレージ、その他のリソースをサービスプロジェクトにデプロイする権限のみが与えられます。

このアプローチは、アプリケーションが Google Cloud、オンプレミス、または他のクラウドプロバイダで実行されている他のリソースにアクセスする必要があるシナリオでうまく機能します。ただし、すべてのユースケースでそのようなアクセスが必要なわけではありません。たとえば、ジョブ実行用のコンピューティングマシンを作成する目的でローカルネットワークへのアクセスのみを必要とする、BigQuery（BQ）や Google Cloud Storage（GCS）のデータに基づいて動作するデータフローパイプラインを考えてみましょう。

もう一つのわかりやすい例は、一連の内部アプリケーションをホストするために使用する Google Kubernetes Engine（GKE）自動パイロットクラスタを備え、クラスタを超えた拡張接続を必要としない開発チームです。

外部接続を必要としないユースケースの場合、一元化された共有 VPC へのアクセスに依存する必要はありません。柔軟性を高めるには、接続要件ごとにアプリケーションを分類します。オンプレミスまたは他のネットワークへの接続が必要なアプリケーションを共有 VPC に配置し、外部接続を必要としないアプリケーションをサービスプロジェクトで作成された VPC にデプロイします。サービスプロジェクトは、ホストプロジェクトの共有 VPC と、サービスプロジェクトで作成および管理されるローカル VPC の両方を使用できることに注意することが重要です。

このブログ投稿では、分類された VPC を介してネットワーク接続を管理するための設計上の考慮事項と、それらを使用してセキュリティを維持しながら開発者中心のネットワーキングを提供する方法について説明します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_x4zMFa7.max-800x800.png

図: ネットワークアクセス管理

柔軟性、セキュリティ、スケーラビリティ

目的は、セキュリティとスケーラビリティを犠牲にすることなく、ネットワークチームとともにサービスプロジェクトのローカル VPC を設計する際の柔軟性と自主性を開発者に提供することです。これにより、開発者は、ファイアウォールルール、IAM アクセス、VPC の変更リクエストなどの中央のネットワーク制御によってブロックされることなく、Google Cloud でアプリケーションを簡単かつ迅速にオンボーディングすることができます。これは、分離されており外部接続を必要としないワークロードの場合に特に重要です。

開発者が VPC ネットワークを作成できるようにするのは良い考えですが、セキュリティガードレールを維持することが重要です。そのため、VPC の作成は、プロジェクト作成の Infrastructure as Code （IaC）の一部として自動化することをおすすめします。ネットワークチームは VPC 作成 IaC のガイドラインを監督し、開発者には事前に作成された VPC へのアクセスが与えられます。ローカル VPC への変更は、github pull request タイプのワークフローを通過します。このワークフローでは、中央ネットワーク管理者や Google Cloud プラットフォーム管理チームが、これらのプロジェクトでローカル VPC のアプリケーションチームが主導する構成のレビュー担当者になります。

開発者がサービスプロジェクト VPC にデプロイできるネットワークコンポーネントを制限するには、組織のポリシーを参照してください。たとえば、組織のポリシーを使用して、VM へのパブリック IP アドレスの割り当て、外部ロードバランサ、VPC ピアリング、VPN、NAT ゲートウェイなどの作成をブロックできます。より高いレベルでネットワークアクセスを制御するには、フォルダまたは組織レベルで階層型ファイアウォールポリシーを使用することを検討してください。

一部の VPC 割り当てと上限は、ネットワークごとに適用されます。分離されたワークロードをローカルサービスプロジェクト VPC に移動することで、中央の共有 VPC 割り当ての消費量を削減できます。

理解すべきデザインの側面

これらのリファレンス設計をベースラインとして使用して、ニーズを満たすものを構築することができます。

1.VPC の分類

プロジェクトのローカルおよび共有 VPC アクセストポロジ

この設計では、プロジェクトのローカル VPC と共有 VPC の両方にアクセスできるサービスプロジェクトを提供できます。このアイデアは、プロジェクト内部のアプリケーションやサービスがローカル VPC を利用し、必要に応じて拡張接続のために共有 VPC またはその他の接続メカニズムを使用するというものです。

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_23LyPtY.max-1100x1100.png

図: 両方の VPC へのアクセス

たとえば、Cloud Run アプリは企業のプロキシを通じてパブリックアーティファクトにアクセスすることが想定されています。同様に、SharedVPC に接続されたプライベートワーカープールで実行されている Cloud Build は、パブリックレジストリからビルド時の依存関係をダウンロードできます。もう一つの例は、ローカル VPC にデプロイされたプライベート GKE クラスタが、クラスタ内でローカルに通信するアプリケーションをホストできることです。

VPC 間にデフォルトの接続はなく、共有 VPC 設計への変更は提案されていないことを理解することが重要です。

https://storage.googleapis.com/gweb-cloudblog-publish/images/3_pwb4lCN.max-1100x1100.png

図: ネットワーク設計の詳細図

2. Google マネージドサービスへの接続

プロジェクトには共有 VPC へのアクセスが必須ではなく、プロジェクト内にローカル VPC のみを含めることができます。ローカル VPC 内のクライアントは、Filestore や Cloud SQL などの PSA サービス、または Google Cloud API を使用するサービスにアクセスできます。この設計は、Google のマネージドサービスや API へのアクセスを許可しながら、迅速な市場投入、プライベートのみのデプロイをサポートします。多くの場合、ユーザーは Google Cloud API へのアクセスのみが必要になります。

一元管理される共有 VPC へのアクセスは、必要な場合にのみ選択的に許可される必要があります。ネットワーク管理者や SRE は、未使用のプロジェクトの共有 VPC の使用状況を監査し、共有 VPC へのアクセスを必要とするアクティブなプロジェクトに制限する必要があります。VPC アクセスログは、分析のために BigQuery に送信できます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/4_bFpW7ZQ.max-1000x1000.png

図: localVPC を使用したプロジェクト

デフォルトでは、この設計はオンプレミスやその他のネットワークとの接続を提供しません。

3. プロジェクト / 組織横断的なネットワーク接続

VPC 外部のエンドポイントへのアクセスは、Private Service Connect（PSC）、VPC ネットワークピアリング、または内向き用の適切なロードバランサ LB スタックを通じて選択的に公開できます。PSC マネージドサービスは、同じ Google Cloud 組織内または組織間でローカルまたは共有 VPC 接続を拡張するメカニズムです。代替として、VPC ピアリングは、内向きと外向きの両方に広範な接続を提供します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/5_lrw0eJf.max-700x700.png

図: PSC を介した拡張接続

まとめると、このブログ投稿では、セキュリティと柔軟性のバランスを提供する開発者指向のネットワーク設計の観点を示しました。この設計には、プロジェクト固有のローカル VPC と、一元管理される共有 VPC への選択的アクセスが含まれています。この設計により、企業はネットワークアクセスを分類し、不正アクセスのリスクを最小限に抑えることができます。