From 733a1c61727bbbe47b1509d962a67c06b537543d Mon Sep 17 00:00:00 2001 From: Anna Nosek Date: Tue, 3 Dec 2024 12:13:01 +0100 Subject: [PATCH 1/4] Improve GCP integration quota option description --- gdi/get-data-in/connect/gcp/gcp-connect.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gdi/get-data-in/connect/gcp/gcp-connect.rst b/gdi/get-data-in/connect/gcp/gcp-connect.rst index c7f0b6a46..697161595 100644 --- a/gdi/get-data-in/connect/gcp/gcp-connect.rst +++ b/gdi/get-data-in/connect/gcp/gcp-connect.rst @@ -111,7 +111,7 @@ Optionally you can: * If you select Compute Engine as one of the services to monitor, you can enter a comma-separated list of Compute Engine Instance metadata keys to send as properties. These metadata keys are sent as properties named ``gcp_metadata_``. -* Select :strong:`Use quota from the project where metrics are stored` to use a quota from the project where metrics are stored. The service account provided for the project needs either the ``serviceusage.services.use`` permission, or the `Service Usage Consumer` role. +* If you are using a single principal for multiple projects (a single Service Account or a single Workload Identity Federation provider), GCP tracks all API usage quota in the project where the principal originates from. This can result in throttling in your integration. To mitigate this, select :strong:`Use quota from the project where metrics are stored`. The principal provided for the project needs either the ``serviceusage.services.use`` permission, or the `Service Usage Consumer` role. Alternatives to connect to GCP ============================================ From 4f8eb4627c50bd4861fa7a872f8af762dcd0c248 Mon Sep 17 00:00:00 2001 From: Anna U <104845867+aurbiztondo-splunk@users.noreply.github.com> Date: Tue, 3 Dec 2024 12:38:32 +0100 Subject: [PATCH 2/4] Update gcp-connect.rst Edits, description --- gdi/get-data-in/connect/gcp/gcp-connect.rst | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/gdi/get-data-in/connect/gcp/gcp-connect.rst b/gdi/get-data-in/connect/gcp/gcp-connect.rst index 697161595..6aa80e134 100644 --- a/gdi/get-data-in/connect/gcp/gcp-connect.rst +++ b/gdi/get-data-in/connect/gcp/gcp-connect.rst @@ -98,8 +98,17 @@ Your GCP integration is now complete. .. note:: Splunk is not responsible for data availability, and it can take up to several minutes (or longer, depending on your configuration) from the time you connect until you start seeing valid data from your account. -Options -++++++++ +Using a single principal for your resources +++++++++++++++++++++++++++++++++++++++++++++++++ + +In IAM you can grant access to your resources to one or more entities called principals. The principal provided for the project needs either the ``serviceusage.services.use`` permission or the `Service Usage Consumer` role. + +Regardless of the authentication method (single Service Account or Workload Identity Federation), if you're using a single principal for multiple projects, GCP tracks all API usage quota in the project where the principal originates from. This can result in throttling in your integration. To mitigate this, select :strong:`Use quota from the project where metrics are stored`. + +For a more detailed description see :new-page:`Principals ` in GCP's docs. + +Other options +++++++++++++++++ Optionally you can: @@ -111,8 +120,6 @@ Optionally you can: * If you select Compute Engine as one of the services to monitor, you can enter a comma-separated list of Compute Engine Instance metadata keys to send as properties. These metadata keys are sent as properties named ``gcp_metadata_``. -* If you are using a single principal for multiple projects (a single Service Account or a single Workload Identity Federation provider), GCP tracks all API usage quota in the project where the principal originates from. This can result in throttling in your integration. To mitigate this, select :strong:`Use quota from the project where metrics are stored`. The principal provided for the project needs either the ``serviceusage.services.use`` permission, or the `Service Usage Consumer` role. - Alternatives to connect to GCP ============================================ From c6931ddbb188a30bf1d83aa1dc54bd2f70870827 Mon Sep 17 00:00:00 2001 From: Anna U <104845867+aurbiztondo-splunk@users.noreply.github.com> Date: Tue, 3 Dec 2024 12:39:10 +0100 Subject: [PATCH 3/4] Update gcp-connect.rst Fix --- gdi/get-data-in/connect/gcp/gcp-connect.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gdi/get-data-in/connect/gcp/gcp-connect.rst b/gdi/get-data-in/connect/gcp/gcp-connect.rst index 6aa80e134..7283426f0 100644 --- a/gdi/get-data-in/connect/gcp/gcp-connect.rst +++ b/gdi/get-data-in/connect/gcp/gcp-connect.rst @@ -101,7 +101,7 @@ Your GCP integration is now complete. Using a single principal for your resources ++++++++++++++++++++++++++++++++++++++++++++++++ -In IAM you can grant access to your resources to one or more entities called principals. The principal provided for the project needs either the ``serviceusage.services.use`` permission or the `Service Usage Consumer` role. +In IAM you can grant access to your resources to one or more entities called principals. The principal provided for the project needs either the ``serviceusage.services.use`` permission or the Service Usage Consumer role. Regardless of the authentication method (single Service Account or Workload Identity Federation), if you're using a single principal for multiple projects, GCP tracks all API usage quota in the project where the principal originates from. This can result in throttling in your integration. To mitigate this, select :strong:`Use quota from the project where metrics are stored`. From f3e3c74b83c2e887b41734043e1b5ea10b04a222 Mon Sep 17 00:00:00 2001 From: Anna U <104845867+aurbiztondo-splunk@users.noreply.github.com> Date: Tue, 3 Dec 2024 14:37:56 +0100 Subject: [PATCH 4/4] Update gcp-connect.rst Fix --- gdi/get-data-in/connect/gcp/gcp-connect.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gdi/get-data-in/connect/gcp/gcp-connect.rst b/gdi/get-data-in/connect/gcp/gcp-connect.rst index 7283426f0..3d3514ddd 100644 --- a/gdi/get-data-in/connect/gcp/gcp-connect.rst +++ b/gdi/get-data-in/connect/gcp/gcp-connect.rst @@ -101,9 +101,9 @@ Your GCP integration is now complete. Using a single principal for your resources ++++++++++++++++++++++++++++++++++++++++++++++++ -In IAM you can grant access to your resources to one or more entities called principals. The principal provided for the project needs either the ``serviceusage.services.use`` permission or the Service Usage Consumer role. +In IAM you can grant access to your resources to one or more entities called principals, regardless of the authentication method (single Service Account or Workload Identity Federation). -Regardless of the authentication method (single Service Account or Workload Identity Federation), if you're using a single principal for multiple projects, GCP tracks all API usage quota in the project where the principal originates from. This can result in throttling in your integration. To mitigate this, select :strong:`Use quota from the project where metrics are stored`. +If you're using a single principal for multiple projects, GCP tracks all API usage quota in the project where the principal originates from, which can result in throttling in your integration. To mitigate this, select :strong:`Use quota from the project where metrics are stored`. To use this option the principal provided for the project needs either the ``serviceusage.services.use`` permission or the Service Usage Consumer role. For a more detailed description see :new-page:`Principals ` in GCP's docs.