Add Support For Google Cloud Service Account Impersonation

[TigerC10]

What is it?

Google recommends that Service Account Tokens should always be paired with Service Account Impersonation for security best practices. Service account impersonation is similar to Amazon Web Services (AWS) Security Token Service API methods like AssumeRole.

Why do it?

If a Service Account Token is compromised, it is useless to act on Google Cloud APIs without the associated service account to impersonate included in each API call (adding an additional layer of obfuscation, separating the lock from the key).

How does it function?

Two different service accounts are involved:

1. Service Provider Service Account (🕵️)
2. Privileged Service Account (🧑‍🔧)

The Service Provider Service Account (🕵️) has no privileges in GCP, with the exception of the Token Creator Role. This is the service account that a Service Account Token is generated for, and that token is provided to the service provider (Grafana, in this case).

The Privileged Service Account (🧑‍🔧) has the minimum privileges required to make the API calls required by the service provider. This service account should never have a Service Account Token generated for it. Google Cloud IAM permissions must grant the Service Provider Service Account (🕵️) Token Creator access to the Privileged Service Account (🧑‍🔧).

flowchart LR
    Grafana["Grafana<br/>Service Account Token<br/>(As 🕵️ Service Account)"] -->|"Impersonate<br/>🧑‍🔧 Service Account"| Impersonation([Make API Call])
    Impersonation --> API[Google Cloud]

Loading

When making API calls, set the impersonate-service-account property in the API call to the email address of the Privileged Service Account to impersonate. It's that easy! 😄

See Also:

Google Cloud has already baked Service Account Impersonation to the data source plugins they've authored

• GoogleCloudPlatform/cloud-logging-data-source-plugin#service-account-impersonation
• GoogleCloudPlatform/cloud-trace-data-source-plugin#service-account-impersonation