組織レベルとフォルダレベルのログをサポートされている宛先に照合して転送する

このドキュメントでは、集約シンクを作成する方法について説明します。集約シンクを使用すると、組織またはフォルダの Google Cloud リソースによって生成されたログを組み合わせて、一元管理された場所にルーティングできます。

概要

集約シンクは、組織またはフォルダに含まれているリソースのログを組み合わせてエクスポート先に転送します。

これらのリソースでどのログをクエリできるか、またはこれらのリソースのシンクを介してルーティングできるログを制御する場合は、集約シンクをインターセプトまたはインターセプトしないように構成できます。

  • 非インターセプト集約シンクは、子リソースのシンクを介してログを転送します。このシンクを使用すると、ログが生成されたリソース内のログの可視性を維持できます。非インターセプト シンクは、子リソースに表示されません。

    たとえば、組織に含まれているフォルダから生成されたすべてのログエントリを中央の Cloud Storage バケットにルーティングする非インターセプト 集約シンクを作成できます。ログは、中央の Cloud Storage バケットと、ログが生成されたリソースに保存されます。

  • 集約シンクをインターセプトすると、_Required シンクを除き、子リソースのシンクを介してログが転送されなくなります。このシンクは、ログの重複コピーが複数の場所に保存されるのを防ぐのに役立ちます。

    たとえば、データアクセス監査ログについて考えてみます。このログは、容量が大きく、複数のコピーを保存するとコストがかかる可能性があります。データアクセス監査ログを有効にしている場合は、すべてのデータアクセス監査ログを中央のプロジェクトにルーティングして分析するフォルダレベルのインターセプト シンクを作成できます。このインターセプトにより、子リソースのシンクがログのコピーを別の場所に転送することもできなくなります。

    インターセプトするシンクにより、ログが _Required シンクとも一致する場合を除き、子リソースのログルーターを経由するログが渡されなくなります。ログがインターセプトされるため、ログは子リソースのログベースの指標またはログベースのアラート ポリシーにカウントされません。インターセプト シンクは、子リソースの [ログルーター] ページで表示できます。

シンクの管理については、サポートされている宛先にログを転送する: シンクを管理するをご覧ください。

フォルダまたは組織ごとに最大 200 個のシンクを作成できます。

選択できる宛先

非インターセプト集約シンクを使用して、同じ組織内またはフォルダ間で次の宛先にログを転送できます。

  • Cloud Logging バケット: Cloud Logging のストレージが提供されます。ログバケットには、複数の Google Cloud プロジェクトで受信するログエントリを保存できます。Log Analytics を使用するようにログバケットをアップグレードし、リンクされた BigQuery データセットを作成すると、Cloud Logging データを他のデータと結合できます。ログバケットに保存されているログの表示については、ログのクエリと表示の概要と Cloud Logging バケットにルーティングされたログの表示をご覧ください。
  • BigQuery データセット: BigQuery データセットにログエントリのストレージを提供します。保存されたログエントリに対して、ビッグデータ分析機能を使用できます。Cloud Logging のデータを他のデータソースと組み合わせるには、Log Analytics を使用するようにログバケットをアップグレードし、リンクされた BigQuery データセットを作成することをおすすめします。BigQuery に転送されたログエントリの表示については、BigQuery に転送されたログを表示するをご覧ください。
  • Cloud Storage バケット: Cloud Storage にログエントリを保存します。ログエントリは、JSON ファイルとして保存されます。 Cloud Storage に転送されたログエントリの表示については、Cloud Storage に転送されたログを表示するをご覧ください。
  • Pub/Sub トピック: サードパーティ統合をサポートします。ログエントリは JSON 形式にフォーマットされ、Pub/Sub トピックにルーティングされます。Pub/Sub に転送されたログエントリの表示については、Pub/Sub に転送されたログを表示するをご覧ください。
  • Splunk: Splunk をサポートします。ログエントリを Pub/Sub トピックにルーティングし、Splunk を使用してそのトピックに登録する必要があります。
  • Google Cloud プロジェクト: ログエントリを異なる Google Cloud プロジェクトにルーティングします。ログエントリを別の Google Cloud プロジェクトにルーティングすると、宛先のプロジェクトのログルーターがログエントリを受信し、それらを処理します。宛先プロジェクトのシンクは、受信したログエントリのルーティング方法を決定します。 宛先プロジェクトがログエントリを宛先プロジェクトが所有するログバケットにルーティングすると、Error Reporting によってログエントリを分析できます。
  • その他のリソース: 異なるプロジェクトにあるサポートされている宛先にログエントリを転送します。使用するパスについては、宛先パスの形式をご覧ください。

シンクをインターセプトするためのベスト プラクティス

インターセプト シンクを作成するときは、次のことをおすすめします。

  • 子リソースがログのルーティングを独自に制御する必要があるかどうかを検討します。子リソースが特定のログの独立した制御を必要とする場合は、インターセプト・シンクがそれらのログをルーティングしないようにします。

  • インターセプト シンクの説明に連絡先情報を追加します。これは、インターセプト シンクを管理するユーザーが、ログがインターセプトされているプロジェクトを管理するユーザーと異なる場合に役立ちます。

  • まず、非インターセプト集約シンクを作成して、シンクの構成をテストし、正しいログがルーティングされていることを確認します。

集約シンクと VPC Service Controls

集約シンクと VPC Service Controls を使用する場合は、次の制限が適用されます。

  • 集約シンクは、サービス境界内にあるプロジェクトからデータにアクセスできます。集約シンクが境界内のデータにアクセスするのを制限するには、IAM を使用して Logging 権限を管理することをおすすめします。

  • VPC Service Controls では、フォルダまたは組織のリソースのサービス境界への追加をサポートしていません。したがって、VPC Service Controls を使用してフォルダレベルと組織レベルのログ（集約ログを含む）を保護することはできません。フォルダレベルまたは組織レベルで Logging 権限を管理するには、IAM を使用することをおすすめします。

  • フォルダレベルまたは組織レベルのシンクを使用して、サービス境界で保護されるリソースにログをルーティングする場合は、サービス境界に上り（内向き）ルールを追加する必要があります。上り（内向き）ルールで、集約シンクが使用するサービス アカウントからリソースへのアクセスを許可する必要があります。詳しくは、以下のページをご覧ください。

  • サービス境界に上り（内向き）ポリシーまたは下り（外向き）ポリシーを指定すると、ログシンクを使用して Cloud Storage リソースにログを転送するときに ANY_SERVICE_ACCOUNT と ANY_USER_ACCOUNT を ID タイプとして使用することはできません。ただし、ID タイプとして ANY_IDENTITY を使用できます。

準備

シンクを作成する前に、次のことを確認します。

  • ログ エクスプローラで表示可能なログを含む Google Cloud フォルダまたは組織がある。

  • ログの転送元の Google Cloud の組織またはフォルダに対して、次のいずれかの IAM ロールを付与されている。

    • オーナー（roles/owner）
    • Logging 管理者（roles/logging.admin）
    • ログ構成書き込み（roles/logging.configWriter）

    これらのロールに含まれる権限を使用して、シンクの作成、削除、変更ができます。IAM ロールの設定については、Logging のアクセス制御ガイドをご覧ください。

  • サポート対象の宛先にリソースがあるか、作成できる。

    シンクを作成する前に、Google Cloud CLI、Google Cloud コンソール、または Google Cloud APIs を使用して転送先を作成する必要があります。任意の組織の任意の Google Cloud プロジェクトにエクスポート先を作成できますが、シンクのサービス アカウントに、エクスポート先への書き込み権限があることを確認する必要があります。

集約シンクの作成

非インターセプト集約シンクを作成するには、Google Cloud の組織またはフォルダにシンクを作成し、シンクの includeChildren パラメータを True に設定します。includeChildren パラメータを設定すると、シンクは、組織またはフォルダからだけでなく、それに含まれるすべてのフォルダ、請求先アカウント、Google Cloud プロジェクトからも（再帰的に）ログエントリをルーティングできます。インターセプト シンクを作成するには、includeChildren パラメータと interceptChildren パラメータの両方を True に設定します。

宛先にルーティングするログエントリを指定するには、シンクの包含フィルタと除外フィルタを設定します。

フォルダまたは組織の集約シンクを作成する方法は次のとおりです。

コンソール

  1. Google Cloud コンソールで、[ログルーター] ページに移動します。

    [ログルーター] に移動

    検索バーを使用してこのページを検索する場合は、小見出しが [Logging] である結果を選択します。

  2. 既存のフォルダまたは組織を選択します。

  3. [シンクを作成] を選択します。

  4. [シンクの詳細] パネルで、次の詳細を入力します。

    • シンク名: シンクの識別子を指定します。シンクを作成した後は、シンクの名前は変更できませんが、シンクを削除して新しいシンクを作成することはできます。

    • シンクの説明（省略可）: シンクの目的またはユースケースについて説明します。

  5. [シンクのエクスポート先] パネルで、シンクのサービスとエクスポート先を選択します。

    • シンクサービスの選択: ログを転送するサービスを選択します。 インターセプト シンクを作成する場合は、宛先として Google Cloud プロジェクトのみを選択できます。

    選択したサービスに基づいて、次のエクスポート先から選択できます。

    • Cloud Logging バケット: Logging バケットを選択または作成します。ログバケットを作成する場合は、プロジェクト レベルにする必要があります。フォルダレベルや組織レベルでログバケットを作成することはできません。
    • BigQuery テーブル: エクスポートされたログを受信する特定のデータセットを選択または作成します。パーティション分割テーブルを使用することもできます。
    • Cloud Storage バケット: エクスポートされたログを受信する特定の Cloud Storage バケットを選択または作成します。
    • Pub/Sub トピック: エクスポートされたログを受信する特定のトピックを選択または作成します。
    • Splunk: Splunk サービスの Pub/Sub トピックを選択します。

    • Google Cloud プロジェクト: ルートログを受信する Google Cloud プロジェクトを選択します。

      たとえば、シンク先が BigQuery データセットの場合、シンクのエクスポート先は次のようになります。

      bigquery.googleapis.com/projects/PROJECT_ID/datasets/DATASET_ID

  6. [シンクに含めるログを選択] パネルで、次のいずれかの操作を行います。

    • 非インターセプト集約シンクを作成するには、[このリソースとすべての子リソースによって取り込まれたログを含める] を選択します。

    • インターセプト シンクを作成するには、[この組織によって取り込まれたログとすべての子リソース] を選択します。

  7. 含めるログエントリに一致する [包含フィルタの作成] フィールドにフィルタ式を入力して、ダイアログを完了します。フィルタを設定しない場合は、選択したリソースのすべてのログが宛先に転送されます。

    たとえば、すべてのデータアクセスの監査 ログを 1 つの Logging バケットにルーティングするようにフィルタを作成できます。このフィルタは次のようになります。

    LOG_ID("cloudaudit.googleapis.com/data_access") OR LOG_ID("externalaudit.googleapis.com/data_access")

    フィルタの長さは 20,000 文字までです。

  8. （省略可）正しいフィルタを入力したことを確認するには、[ログをプレビュー] を選択します。フィルタが事前に入力された状態で、ログ エクスプローラが新しいタブで開きます。

  9. （省略可）[Choose logs to exclude from the sink] パネルで、次の操作を行います。

    1. [除外フィルタの名前] フィールドに名前を入力します。

    2. [除外フィルタの作成] セクションで、除外するログエントリに一致するフィルタ式を入力します。また、sample 関数を使用して、除外するログエントリの一部を選択することもできます。

      たとえば、特定のプロジェクトのログを宛先にルーティングしない場合は、次の除外フィルタを追加します。

      logName:projects/PROJECT_ID

      複数のプロジェクトからログを除外するには、論理 OR 演算子を使用して logName 句を結合します。

    シンクごとに最大 50 個の除外フィルタを作成できます。フィルタの長さは 20,000 文字までです。

  10. [シンクを作成] を選択します。

API

シンクを作成するには、Logging API の organizations.sinks.create または folders.sinks.create を使用します。次のように、メソッドの引数を準備します。

  1. parent パラメータを、シンクを作成する Google Cloud 組織またはフォルダに設定します。親は次のいずれかにする必要があります。

    • organizations/ORGANIZATION_ID
    • folders/FOLDER_ID

  2. メソッドのリクエスト本文の LogSink オブジェクトで、次のいずれかを行います。

    • 非インターセプト集約シンクを作成するには、includeChildren を True に設定します。

    • インターセプト シンクを作成するには、includeChildren パラメータと interceptChildren パラメータを True に設定します。

  3. 含めるログエントリに一致するように filter プロパティを設定します。 フィルタの長さは 20,000 文字までです。

    役立つフィルタの例については、集約シンク用のフィルタの作成をご覧ください。

  4. 残りの LogSink フィールドを他のシンクの場合と同様に設定します。詳細については、サポートされている宛先にログをルーティングするをご覧ください。

  5. organizations.sinks.create または folders.sinks.create を呼び出してシンクを作成します。

  6. API レスポンスで返された writer_identity フィールドからサービス アカウント名を取得します。

  7. そのサービス アカウントにシンクのエクスポート先への書き込み権限を付与します。

    シンクのエクスポート先を変更する権限がない場合は、その変更を行うことができるユーザーにサービス アカウント名を送信します。

    リソースに対する権限をサービス アカウントに付与する方法については、エクスポート先の権限の設定セクションをご覧ください。

gcloud

集約シンクを作成するには、logging sinks create コマンドを使用します。非インターセプト集約シンクを作成するには、--include-children フラグを指定します。インターセプト シンクを作成するには、--include-children フラグと --intercept-children フラグの両方を指定します。

  1. シンク名、シンクのエクスポート先、フィルタ、ログの転送元のフォルダまたは組織の ID を指定します。次の例では、非インターセプト集約シンクを作成します。

    gcloud logging sinks create SINK_NAME \
  SINK_DESTINATION  --include-children \
  --folder=FOLDER_ID --log-filter="LOG_FILTER"

    たとえば、フォルダレベルで集約シンクを作成し、宛先が BigQuery データセットの場合、コマンドは次のようになります。

    gcloud logging sinks create SINK_NAME \
  bigquery.googleapis.com/projects/PROJECT_ID/datasets/DATASET_ID --include-children \
  --folder=FOLDER_ID --log-filter="logName:activity"

    注:

    • シンクを組織レベルで作成するには、--folder=FOLDER_ID を --organization=ORGANIZATION_ID に置き換えます。

    • シンクが組織内のすべてのリソースをインクルードするには、--organization フラグが create に渡された場合でも --include-children フラグを設定する必要があります。false（デフォルト）に設定すると、シンクはホストリソースからのログのみを転送します。

    • 役立つフィルタの例については、集約シンク用のフィルタの作成をご覧ください。

  2. コマンド出力から、シンクの作成に使用されたサービス アカウント名を取得します。

  3. そのサービス アカウントにシンクのエクスポート先への書き込み権限を付与します。

    シンクのエクスポート先を変更する権限がない場合は、その変更を行うことができるユーザーにサービス アカウント名を送信します。

    リソースに対する権限をサービス アカウントに付与する方法については、エクスポート先の権限の設定セクションをご覧ください。

シンクに加えたどの変更も、適用されるまで数分かかることがあります。

集約シンクのフィルタを作成する

他のシンクと同様に、集約シンクにも個々のログエントリを選択するフィルタが含まれます。 集約シンクの作成に使用できるフィルタの例については、ログ エクスプローラを使用したサンプルクエリをご覧ください。

以下に、集約シンク機能を使用するときに役立つフィルタの比較例を示します。一部の例で次の表記を使用しています。

  • : は部分文字列演算子です。= 演算子を代わりに使用しないでください。
  • ... はさらにフィルタ比較が続くことを表します。
  • 変数は色付きのテキストで示されます。これらは有効な値に置き換えてください。

フィルタの長さは 20,000 文字までです。

フィルタリング構文の詳細については、Logging のクエリ言語をご覧ください。

ログソースを選択する

集約シンクでは、組織またはフォルダの子リソースごとに、子リソースに送信される各ログエントリにシンクの包含フィルタと除外フィルタが適用されます。包含フィルタに一致し、除外されていないログエントリがルーティングされます。

シンクがすべての子リソースからログをルーティングするようにする場合は、シンクの包含フィルタと除外フィルタでプロジェクト、フォルダ、または組織を指定しないでください。たとえば、次のフィルタを使用して組織の集約シンクを構成するとします。

resource.type="gce_instance"

前に示すフィルタでは、その組織の子に書き込まれたリソースタイプの Compute Engine インスタンスのログが、集約シンクによって宛先にルーティングされます。

しかし、集約シンクを使用して特定の子リソースからのログのみをルーティングしたい場合もありえます。たとえば、コンプライアンス上の理由から、特定のフォルダやプロジェクトの監査ログを、自身の Cloud Storage バケットに格納したい場合などです、このような状況では、包含フィルタを構成して、ログをルーティング対象とする各子リソースを指定します。フォルダとそのフォルダ内のすべてのプロジェクトからログをルーティングする場合、フィルタでフォルダとそのフォルダに含まれる各プロジェクトの一覧を表示し、さらにステートメントを OR 句で結合する必要があります。

次のフィルタを使用すると、特定の Google Cloud プロジェクト、フォルダ、または組織にログを制限できます。

logName:"projects/PROJECT_ID/logs/" AND ... 
logName:("projects/PROJECT_A_ID/logs/" OR "projects/PROJECT_B_ID/logs/") AND ... 
logName:"folders/FOLDER_ID/logs/" AND ... 
logName:"organizations/ORGANIZATION_ID/logs/" AND ...

たとえば、フォルダ my-folder に書き込まれた Compute Engine インスタンスに書き込まれたログのみをルーティングするには、次のフィルタを使用します。

logName:"folders/my-folder/logs/" AND resource.type="gce_instance"

前に示すフィルタでは、my-folder 以外のリソースに書き込まれたログ（my-folder の子である Google Cloud プロジェクトに書き込まれたログを含む）は、宛先にルーティングされません。

モニタリング対象リソースを選択する

Google Cloud プロジェクトの特定のモニタリング対象リソースだけからログを転送するには、複数の比較演算子を使用してリソースを厳密に指定します。

logName:"projects/PROJECT_ID/logs" AND
resource.type=RESOURCE_TYPE AND
resource.labels.instance_id=INSTANCE_ID

リソースタイプの一覧については、モニタリング対象リソースタイプをご覧ください。

ログエントリのサンプルを選択する

ログエントリのランダムなサンプルを転送するには、sample 組み込み関数を追加します。たとえば、現在のフィルタに一致するログエントリの 10% だけを転送するには、次の記述を追加します。

sample(insertId, 0.10) AND ...

詳細については、sample 関数をご覧ください。

Cloud Logging のフィルタの詳細については、Logging のクエリ言語をご覧ください。

エクスポート先の権限を設定する

このセクションでは、シンクの宛先にログを書き込むための Identity and Access Management 権限を Logging に付与する方法について説明します。Logging のロールと権限の完全なリストについては、アクセス制御をご覧ください。

現在のプロジェクト内のログバケット以外の宛先にログを転送するシンクを作成または更新する場合は、そのシンクのサービス アカウントが必要です。Logging は、サービス アカウントを自動的に作成して管理します。

  • 2023 年 5 月 22 日以降、シンクを作成し、基盤となるリソースのサービス アカウントが存在しない場合は、Logging によってサービス アカウントが作成されます。Logging では、基盤となるリソース内のすべてのシンクに同じサービス アカウントが使用されます。リソースには、Google Cloud プロジェクト、組織、フォルダ、請求先アカウントがあります。
  • 2023 年 5 月 22 日より前には、Logging は各シンクのサービス アカウントを作成していました。2023 年 5 月 22 日現在、Logging では基盤となるリソース内のすべてのシンクに共有サービス アカウントを使用しています。

シンクの書き込み ID は、そのシンクに関連付けられているサービス アカウントの識別子です。現在の Google Cloud プロジェクトのログバケットに書き込むシンクを除き、すべてのシンクには書き込み ID があります。

サービス境界で保護されたリソースにログを転送するには、シンクのサービス アカウントをアクセスレベルに追加し、宛先サービス境界に割り当てる必要があります。この操作は、集約されていないシンクには必要ありません。詳細については、VPC Service Controls: Cloud Logging をご覧ください。

シンクをエクスポート先にルーティングするための権限を設定するには、次の手順を行います。

Console

  1. シンクのサービス アカウントに関する情報を取得する手順は次のとおりです。

    1. Google Cloud コンソールで、[ログルーター] ページに移動します。

      [ログルーター] に移動

      検索バーを使用してこのページを検索する場合は、小見出しが [Logging] である結果を選択します。

    2. [ メニュー]、 [シンクの詳細を表示] の順に選択します。

      [シンクの詳細] パネルの [writerIdentity] フィールドには、サービス アカウントの ID が含まれています。serviceAccount: 文字列は、サービス アカウント ID の一部です。次に例を示します。

      serviceAccount:service-123456789012@gcp-sa-logging.iam.gserviceaccount.com

  2. 宛先プロジェクトで、書き込み ID にサービス アカウントがエクスポート先に書き込むために必要なロールを付与します。プリンシパルにロールを付与するには、オーナー（roles/owner）のロールが必要です。

    • Cloud Storage のエクスポート先の場合は、IAM を使用してシンクの書き込み ID をプリンシパルとして追加してから、ストレージ オブジェクト作成者のロール（roles/storage.objectCreator）をそれに付与します。
    • BigQuery のエクスポート先の場合は、IAM を使用してシンクの書き込み ID をプリンシパルとして追加してから、BigQuery データ編集者のロール（roles/bigquery.dataEditor）をそれに付与します。
    • Splunk を含む Cloud Pub/Sub のエクスポート先の場合は、IAM を使用してシンクの書き込み ID をプリンシパルとして追加してから、Pub/Sub パブリッシャーのロール（roles/pubsub.publisher）をそれに付与します。
    • 異なる Google Cloud プロジェクトの Logging バケットのエクスポート先の場合は、IAM を使用して、シンクの書き込み ID をプリンシパルとして追加してから、ログバケット書き込みロール（roles/logging.bucketWriter）をそれに付与します。
    • Google Cloud プロジェクトのエクスポート先の場合は、IAM を使用してシンクの書き込み ID をプリンシパルとして追加してから、ログ書き込みロール（roles/logging.logWriter）をそれに付与します。具体的には、プリンシパルに logging.logEntries.route 権限が必要です。
    シンクのエクスポート先へのオーナー アクセス権がない場合は、書き込み ID をプリンシパルとして追加するようにプロジェクト オーナーに依頼します。

API

  1. シンクのサービス アカウントに関する情報を取得するには、API メソッド organizations.sinks.get または folders.sinks.get を呼び出します。

    writerIdentity フィールドには、サービス アカウントの ID が含まれます。serviceAccount: 文字列は、サービス アカウント ID の一部です。次に例を示します。

    serviceAccount:service-123456789012@gcp-sa-logging.iam.gserviceaccount.com

  2. 宛先プロジェクトで、書き込み ID にサービス アカウントがエクスポート先に書き込むために必要なロールを付与します。プリンシパルにロールを付与するには、オーナー（roles/owner）のロールが必要です。

    • Cloud Storage のエクスポート先の場合は、IAM を使用してシンクの書き込み ID をプリンシパルとして追加してから、ストレージ オブジェクト作成者のロール（roles/storage.objectCreator）をそれに付与します。
    • BigQuery のエクスポート先の場合は、IAM を使用してシンクの書き込み ID をプリンシパルとして追加してから、BigQuery データ編集者のロール（roles/bigquery.dataEditor）をそれに付与します。
    • Splunk を含む Cloud Pub/Sub のエクスポート先の場合は、IAM を使用してシンクの書き込み ID をプリンシパルとして追加してから、Pub/Sub パブリッシャーのロール（roles/pubsub.publisher）をそれに付与します。
    • 異なる Google Cloud プロジェクトの Logging バケットのエクスポート先の場合は、IAM を使用して、シンクの書き込み ID をプリンシパルとして追加してから、ログバケット書き込みロール（roles/logging.bucketWriter）をそれに付与します。
    • Google Cloud プロジェクトのエクスポート先の場合は、IAM を使用してシンクの書き込み ID をプリンシパルとして追加してから、ログ書き込みロール（roles/logging.logWriter）をそれに付与します。具体的には、プリンシパルに logging.logEntries.route 権限が必要です。
    シンクのエクスポート先へのオーナー アクセス権がない場合は、書き込み ID をプリンシパルとして追加するようにプロジェクト オーナーに依頼します。

gcloud

  1. シンクのサービス アカウントに関する情報を取得するには、次のコマンドを実行します。

    gcloud logging sinks describe SINK_NAME

    writerIdentity フィールドには、サービス アカウントの ID が含まれます。serviceAccount: 文字列は、サービス アカウント ID の一部です。次に例を示します。

    serviceAccount:service-123456789012@gcp-sa-logging.iam.gserviceaccount.com

  2. 宛先プロジェクトで、書き込み ID にサービス アカウントがエクスポート先に書き込むために必要なロールを付与します。プリンシパルにロールを付与するには、オーナー（roles/owner）のロールが必要です。

    • Cloud Storage のエクスポート先の場合は、IAM を使用してシンクの書き込み ID をプリンシパルとして追加してから、ストレージ オブジェクト作成者のロール（roles/storage.objectCreator）をそれに付与します。
    • BigQuery のエクスポート先の場合は、IAM を使用してシンクの書き込み ID をプリンシパルとして追加してから、BigQuery データ編集者のロール（roles/bigquery.dataEditor）をそれに付与します。
    • Splunk を含む Cloud Pub/Sub のエクスポート先の場合は、IAM を使用してシンクの書き込み ID をプリンシパルとして追加してから、Pub/Sub パブリッシャーのロール（roles/pubsub.publisher）をそれに付与します。
    • 異なる Google Cloud プロジェクトの Logging バケットのエクスポート先の場合は、IAM を使用して、シンクの書き込み ID をプリンシパルとして追加してから、ログバケット書き込みロール（roles/logging.bucketWriter）をそれに付与します。
    • Google Cloud プロジェクトのエクスポート先の場合は、IAM を使用してシンクの書き込み ID をプリンシパルとして追加してから、ログ書き込みロール（roles/logging.logWriter）をそれに付与します。具体的には、プリンシパルに logging.logEntries.route 権限が必要です。
    シンクのエクスポート先へのオーナー アクセス権がない場合は、書き込み ID をプリンシパルとして追加するようにプロジェクト オーナーに依頼します。

次のステップ