ials by impersonating another GCP service account.The connector needs to be configured with the email address of the target GCP service account to be impersonated, accompanied by a GCP service account key JSON for the primary service account. The primary service account must have permission to generate tokens for the target service account (i.e. the Service Account Token Creator role). The connector will generate temporary OAuth 2.0 tokens upon request by using GCP direct service account impersonation. The tokens have a configurable limited lifetime of up to 1 hour.

The best practice implemented with this authentication scheme is to keep the set of permissions associated with the primary service account down to the bare minimum and grant permissions to the privilege-bearing service account instead.

A GCP project is required and the connector may only be used to access GCP resources in the specified project.

If you already have the GOOGLE_APPLICATION_CREDENTIALS environment variable configured to point to the primary service account key JSON file, it will be automatically picked up when auto-configuration is used.

For this example, we have the following set up in GCP:

a primary empty-connectors@zenml-core.iam.gserviceaccount.com GCP service account with no permissions whatsoever aside from the "Service Account Token Creator" role that allows it to impersonate the secondary service account below. We also generate a service account key for this account.

a secondary zenml-bucket-sl@zenml-core.iam.gserviceaccount.com GCP service account that only has permission to access the zenml-bucket-sl GCS bucket

First, let's show that the empty-connectors service account has no permission to access any GCS buckets or any other resources for that matter. We'll register a regular GCP Service Connector that uses the service account key (long-lived credentials) directly: