Cloud DNS ピアリングを使って、アプリケーション チームに DNS レコードの管理権限を与える

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

共有 VPC とは、共通の Virtual Private Cloud（VPC）ネットワークに複数のプロジェクトのリソースを接続し、内部 IP を使って安全かつ効率的に相互通信できるようにする仕組みです。スケーラビリティに優れたネットワーク設計であるため、大規模な Google Cloud 環境で特に便利です。共有 VPC は通常、複数のアプリケーション チームによって使用され、中央チーム（プラットフォーム チーム）がネットワーク構成の管理を行い、アプリケーション チームはそのネットワーク リソースを使って各自のサービス プロジェクト内でアプリケーション開発を行います。

しかし、アプリケーション チームが DNS レコードを自己管理する必要があるケースもあります（サービスを公開するために新しい DNS レコードを作成したい場合や、既存のレコードを更新したい場合など）。Cloud DNS ピアリングを使えば、こうしたニーズに応えながら、詳細な IAM ポリシーを適用することが可能です。この記事では、Cloud DNS ピアリングを使ってアプリケーション チームに DNS レコードの自己管理を許可しながら、中央ネットワーク チームが環境全体をきめ細かく管理する方法を見ていきます。

Cloud DNS ピアリング ソリューションを理解する

たとえば、あなたはアプリケーション チーム（サービス プロジェクト）の所有者で、他のチームやアプリケーションに影響を与えることなく、アプリケーション（サービス プロジェクト）の DNS レコードを自己管理できるようにしたいと考えているとします。DNS ピアリングとは、Cloud DNS 内のゾーンの一種であり、特定のサブドメインからの DNS リクエストを、別の VPC 内に構成された Cloud DNS ゾーンに対して送信する働きをします。

ここで、Cloud DNS ピアリングと VPC ピアリングを混同しないようにしてください。Cloud DNS ピアリングでは、送信元と宛先の VPC 間で通信するための構成は不要です。DNS フローはすべて、Cloud DNS のバックエンドで直接処理されます。つまり、双方の VPC はそれぞれ Cloud DNS とやりとりし、Cloud DNS を介して互いのクエリを送受信することになります。

DNS ピアリングを使えば、アプリケーション チームによる DNS レコードの自己管理を許可できます。具体的には、共有 VPC と、アプリケーション チームによって管理されている Cloud DNS ゾーンの間で、DNS ピアリングを使用します。

DNS レコードの自己管理を希望するアプリケーション チームに、以下を提供します。

• 専用のプライベート DNS のサブドメイン（例: <applicationteam>.<env>.<customer>.gcp.com）

• 専用の Cloud DNS ゾーン（専用プロジェクト内）と、スタンドアロンの VPC（IAM のフル権限付き）

そのうえで、上記の DNS サブドメインから、専用の Cloud DNS ゾーンへの DNS ピアリングを構成します。この VPC 内で、アプリケーション チームは自らの Cloud DNS インスタンスに対してのみ Cloud DNS の IAM 権限をもち、自らの DNS レコードだけを管理できます。

一方、中央チームが DNS ピアリングの管理を担当し、どの Cloud DNS インスタンスがどのサブドメインに対して権限をもつのかを判断して、アプリケーション チームが各自のサブドメインのみを管理するように制限します。

デフォルトでは、共有 VPC 内の VM はすべて、その共有 VPC 内の Cloud DNS をローカルの DNS リゾルバとして使用します。この Cloud DNS インスタンスは、共有 VPC に含まれるすべての DNS レコードに対する責任を担い、アプリケーション チームの Cloud DNS インスタンスに対しては DNS ピアリングを使用し、オンプレミスのレコードに対しては VPC ピアリング（またはオンプレミスへの転送）を使用します。

ここまでの説明をまとめると、以下のようなフローになります。

• 共有 VPC 内のプロジェクトの VM はどれも Cloud DNS をローカルの DNS リゾルバとして使用する。

• この VM がチーム B が所有する DNS レコード、app1.team-b.gcp.com の解決を試みる。チーム B はローカル アプリケーション（Compute Engine インスタンスまたは Cloud ロードバランサ）を公開している。

• この VM が、共有 VPC の Cloud DNS に対して DNS リクエストを送信する。この Cloud DNS には DNS ピアリングが構成されており、「team-b.gcp.com」サブドメイン配下のものはすべてチーム B 用の DNS プロジェクト内の Cloud DNS に送信される。

• チーム B は、専用の DNS プロジェクト内でのみ DNS レコードを管理できる。同チームはこのプロジェクト内に「*.team-b.gcp.com」用のプライベート ゾーンを所有し、「app1.team-b.gcp.com」の A レコードをもっている（このレコードは「10.128.0.10」に解決される）。

• VM は、DNS の回答を受け、VPC ルーティング テーブルを使って 10.128.0.10 への到達を試行する。対応するファイアウォール ルールがオープンである場合、このリクエストは成功する。

Terraform コード

ここで紹介したソリューションをお試しになりたい場合は、Terraform でエンドツーエンドのサンプルをご覧ください。このサンプルは以下のような構成になっています。

この Terraform コードを使えば、DNS ピアリングの利用を簡単に開始できます。また、独自の Infrastructure as Code デプロイメントでこのコードを流用することも可能です。

その他の考慮事項

上記の例では、アプリケーション チームごとに DNS 専用のスタンドアロン プロジェクトを使用しました。

アプリケーション チームのサービス プロジェクトを使用することも可能です。そのためには、アプリケーション プロジェクト内にローカル VPC を作成し、このローカル DNS プロジェクトに DNS ピアリングを構成してください。

それぞれの方式の特徴は以下のとおりです。

セキュリティと自己管理

共有 VPC は、多くの組織が求めているセキュリティや一元管理を提供します。そのうえ、Cloud DNS ピアリングをベースにした共有 VPC を利用することで、アプリケーション チームに DNS レコードを自己管理する権限を与えることもできるので、中央ネットワーク チームの管理作業軽減につながります。複雑なネットワーク環境の管理について詳しくは、DNS のベスト プラクティスをご覧ください。

-戦略的クラウド エンジニア Aurelien Legrand

-プロダクト マネージャー Karthik Balakrishnan