 up the authentication resources, this is for you.These authentication methods deliver another way of configuring long-lived credentials in your Service Connectors without exposing them to clients. They are especially useful as an alternative to cloud provider Service Connectors authentication methods that do not support automatically downscoping the permissions of issued temporary tokens.

The processes of account impersonation and role assumption are very similar and can be summarized as follows:

you configure a Service Connector with long-lived credentials associated with a primary user account or primary service account (preferable). As a best practice, it is common to attach a reduced set of permissions or even no permissions to these credentials other than those that allow the account impersonation or role assumption operation. This makes it more difficult to do any damage if the primary credentials are accidentally leaked.

in addition to the primary account and its long-lived credentials, you also need to provision one or more secondary access entities in the cloud platform bearing the effective permissions that will be needed to access the target resource(s):one or more IAM roles (to be assumed)one or more service accounts (to be impersonated)

the Service Connector configuration also needs to contain the name of a target IAM role to be assumed or a service account to be impersonated.

upon request, the Service Connector will exchange the long-lived credentials associated with the primary account for short-lived API tokens that only have the permissions associated with the target IAM role or service account. These temporary credentials are issued to clients and used to access the target resource, while the long-lived credentials are kept safe and never have to leave the ZenML server boundary.

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