🐕

Datadog に Google Cloud のログをセキュアに送信する

2024/01/18に公開

Google Cloud

TL;DR

この記事は、Datadog の Google Cloud Dataflow を用いた Google Cloud のログ収集をもとに、Public IP アドレスを利用せずセキュアにログを Google Cloud から Datadog に連携する方法をまとめたものです。この構成は、エンタープライズレベルのセキュリティ・コンプライアンスに準拠する必要がある場合に有効です。

最新の手順は、Datadog の公式ドキュメントである Google Cloud Platform ページのログ収集をご覧ください。

概要

2023年10末以降 Datadog は Google Cloud のログ収集に Google Cloud Dataflow を用いる方法を発表し、推奨の方法へと変更しました。

これまでは、Datadog は Google Cloud Pub/Sub サブスクリプションを利用した Push 形式でのログ転送を公式にサポートしていました。この方法は依然としてサポートされ、日本語版のドキュメントではこの方法が案内されています(2024/1/16 現在)。ですが、以下の理由により Pub/Sub の Push サブスクリプションを利用したログ収集は非推奨となりつつあります。

VPC Service Controls で保護されたプロジェクトの場合、Push サブスクリプションは外部のエンドポイントにアクセスできない
Push サブスクリプションはイベントの圧縮やバッチ処理を提供せず、大量のログ送信の場合にデータ転送のコストが増大する

Dataflow はデータ処理をするワーカー VM として、バックエンドに Virtual Private Cloud(VPC) ネットワーク内の Google Compute Engine(GCE) を利用しています。デフォルトではこのワーカー VM に利用される GCE は Public IP アドレスが割り当てられますが、オプションにより Private IP アドレスのみを割り当てるように変更できます。

企業のセキュリティ基準などで、Google Cloud プロジェクト上で GCE に Public IP アドレスを割り当てることが禁止されている場合があります。この場合、Datadog の公式ドキュメントの手順に加えて、Private IP アドレスのみを構成して Pub/Sub からのログを限定公開の Google アクセスと VPC ファイアウォールを構成する必要があります。この記事では、Public IP アドレスを利用せずにセキュアに Datadog へ Google Cloud ログを構成する方法を検証します。

Pub/Sub と Dataflow を構成する

公式ドキュメントから Pub/Sub と Dataflow の作成手順を引用すると、以下の通りです。

Pub/Sub トピックを作成し、Pull サブスクリプションを作成する
Dataflow ワーカー用のカスタムサービスアカウントを作成する
Google Cloud Logging で ログシンクを作成し、Pub/Sub トピックに公開する
Dataflow の「Pub/Sub to Datadog テンプレート」を使用して Dataflow ジョブを作成し、Pub/Sub サブスクリプションからログを Pull して Datadog にストリーミングする

ポイントとしてはそれぞれ、①Pub/Sub は Push ではなく Pull サブスクリプションを作成すること、②最小権限を付与するためカスタムサービスアカウントを作成すること、③ログシンクで送信するログを絞り込むこと、④Datadog が用意した公式の Dataflow テンプレートを利用すること、の4点です。

Dataflow ジョブの作成が成功すると、GCE コンソールから指定されたインスタンスタイプのマシンが複数台稼働している様子が確認できます。

セキュアに構成する

公式の手順では、デフォルトの設定が反映されワーカー VM には Public IP と Private IP の両方が付与されます。
Dataflow ジョブを作成する際のオプションで「ワーカー IP アドレスの構成」を[プライベート]とすると、Public IP アドレスを利用せずに Private IP のみでワーカー VM を起動できます。

この構成を行う上では、VPC ネットワーク内の Private IP のみを持つワーカー VM がログデータを VPC ネットワーク外へ受け渡すため、このような構成のアーキテクチャを想定できます。

この構成のポイントは、Public IP を持つワーカー VM と比較して、Cloud DNS, Cloud NAT が構成されている点です。

Pub/Sub は VPC ネットワーク外で稼働するフルマネージドなサービスであるため、VPC ネットワークの内部にリソースを配置できません。そのため、Private IP のみを持つ Dataflow のワーカー VM がログを受け取るためには、Pub/Sub 用の限定公開の Google アクセスをサブネットに構成します。加えて Cloud NAT を構成すると、Public エンドポイントを持つ Datadog へログを送信できます。

さらに、VPC ネットワークを超えて通信を行うためには、VPC ファイアウォールルールを適切に構成する必要があります。Dataflow のファイアウォールルールはワーカー VM が 12345/tcp と 12346/tcp で通信を行うため、これらのルールを送受信で設定します。

これらの条件を踏まえると、以下の手順で Pub/Sub と Dataflow を構成します。

Pub/Sub トピックを作成し、Pull サブスクリプションを作成する
Dataflow ワーカー用のカスタムサービスアカウントを作成する
Google Cloud Logging でログシンクを作成し、Pub/Sub トピックに公開する
Dataflow ジョブのワーカー VM が稼働する VPC とファイアウォールルール(12345-123456/tcp) を構成する
上記の VPC ネットワーク内に Pub/Sub 用の限定公開の Google アクセスを構成する
ワーカー VM が稼働するリージョンのサブネットに Cloud NAT を構成する
Dataflow の「Pub/Sub to Datadog テンプレート」を使用して Dataflow ジョブをワーカー IP をプライベートに設定した上で作成し、Pub/Sub サブスクリプションからログを Pull して Datadog にストリーミングする

ここからは、Datadog の公式ドキュメントで触れられていない、Dataflow ジョブのワーカー VM/IP をプライベートに設定する上で必要なリソースの構成方法について解説します。

限定公開の Google アクセスを構成する

Public IP を持たない VPC ネットワーク内のVMが VPC ネットワーク外の Google Cloud サービスにアクセスする選択肢には、Private Service Connect と限定公開の Google アクセスが挙げられます。

ここでは両サービスの詳細な違いは割愛しますが、本目的の Dataflow 専用に VPC を作成する場合は、VPC ネットワーク内に追加のリソースを作成しない限定公開の Google アクセスを選択し、最小限の構成を実現します。

限定公開の Google アクセスは対象のサブネットの設定から有効化できますが、Google API とサービスに関する DNS、ルーティング、ファイアウォールネットワークの要件を満たす必要があります。

Google API とサービスのデフォルトのドメイン名で接続する場合、0.0.0.0/0 への ①下り(外向き)の通信を許可し、②インターネットゲートウェイにルーティングする
private.googleapis.com を利用する場合、199.36.153.8/30 の ①DNS レコードを構成し、199.36.153.8/30, 34.126.0.0/18 への ②下り(外向き)の通信を許可し、③インターネットゲートウェイにルーティングする
restricted.googleapis.com を利用する場合 199.36.153.4/30 の ①DNS レコードを構成し、199.36.153.4/30, 34.126.0.0/18 への ②下り(外向き)の通信を許可し、③インターネットゲートウェイにルーティングする

どの方法で VPC ネットワーク外の Google API やサービスに接続するかは、以下のような順序で考えます。

この構成では、よりセキュアにPub/Sub の API にアクセスできる restricted.googleapis.com の利用を想定し、Cloud DNS での名前解決と VPC ファイアウォールの構成を行います。

Cloud DNS を構成する

前述の通り、Cloud DNS は private.googleapis.com または restricted.googleapis.com を利用する場合のみ名前解決を行うため構成します。

Pub/Sub は VPC Service Controles でサポートされるサービスであるため、restricted.googleapis.com を利用できます。

名前解決をする対象は VPC ネットワーク内のワーカー VM のため、限定公開ゾーンを選択し、対象のサブネットに構成します。この場合、Cloud DNS で構成する DNS レコードは以下のようになります。

Name	Type	Value
restricted.googleapis.com	A	199.36.153.4
restricted.googleapis.com	A	199.36.153.5
restricted.googleapis.com	A	199.36.153.6
restricted.googleapis.com	A	199.36.153.7
*.googleapis.com	CNAME	restricted.googleapis.com

VPC ファイアウォールを構成する

Dataflow ジョブのワーカー VM は、Pub/Sub サブスクリプションからログを取得する際と、Datadog の Send Logs API へログを送信する際に VPC ネットワークの外に通信を行います。

Pub/Sub への通信は restricted.googleapis.com を利用して行われるため、199.36.153.4/30　と 34.126.0.0/18 の下り(外向き)の通信許可をします。
Datadog への通信は、Network Traffic からその IP アドレス範囲を特定できます。Datadog Logs に利用される API エンドポイントの IP アドレス範囲は JSON 形式で公開されており、利用する Datadog サイトにより異なります。US5 の場合は、34.149.66.128/26が利用されていることがわかります。(2024/1/16 現在)

さらに、ワーカー VM が利用するポートは 12345/tcp と 12346/tcp であるため、こちらに基づいて VPC ファイアウォールルールを構成し、最小限のネットワークのみを許可できます。

Filters	Protocols / ports	Action
IP ranges: `199.36.153.4/30`, `34.126.0.0/18`, `34.149.66.128/26`	tcp:12345-12346	Allow

この許可ポリシーは、同一の IP アドレス範囲に対する拒否ポリシーよりも優先度を高く設定しする必要があります。

Cloud NAT を構成する

Dataflow ジョブのワーカー VM は Public IP アドレスを持たないため、Datadog のようなインターネット上のエンドポイントと通信を行うために、Cloud NAT などによる Public アドレス変換を行います。

Cloud NAT の Public NAT は VPC とリージョンを選択して適用し、対象のインスタンスからのネクストホップがインターネットゲートウェイであるルートに使用されます。今回の場合は、ワーカー VM はデフォルトでオートスケールするため、対象のIP アドレス範囲やサブネットにを指定することもできます。

Cloud NAT　作成時に併せて Cloud Router を作成するため、インスタンスから NAT・NAT からインターネットゲートウェイへのルーティングが適切に構成されます。

ここまでの構成により、Dataflow ジョブのワーカー VM が Public IP を持たない場合でも、Cloud Logging → Pub/Sub → Dataflow → Datadog のようなログの送信が可能になります。

補足

本記事で説明している　Pub/Sub とプライベートな Dataflow の連携は、Datadog へのログ送信に限らない内容です。

本番環境で導入される際は、企業のセキュリティ・コンプライアンスを参照して最適な構成となるよう、ご留意ください。また、一般的な Dataflow のネットワーク構成は Google Cloud の公式ドキュメント「インターネットアクセスとファイアウォールルールの構成」をご参照ください。

GitHubで編集を提案