aspyre/src/zenml/empty-connectors@zenml-core.json.Successfully registered service connector `gcp-impersonate-sa` with access to the following resources:

┏━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━┓

┃ RESOURCE TYPE │ RESOURCE NAMES       ┃

┠───────────────┼──────────────────────┨

┃ 📦 gcs-bucket │ gs://zenml-bucket-sl ┃

┗━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━━━━━━━┛

Short-lived credentials

This category of authentication methods uses temporary credentials explicitly configured in the Service Connector or generated by the Service Connector during auto-configuration. Of all available authentication methods, this is probably the least useful and you will likely never have to use it because it is terribly impractical: when short-lived credentials expire, Service Connectors become unusable and need to either be manually updated or replaced.

On the other hand, this authentication method is ideal if you're looking to grant someone else in your team temporary access to some resources without exposing your long-lived credentials.

A previous section described how temporary credentials can be automatically generated from other, long-lived credentials by most cloud provider Service Connectors. It only stands to reason that temporary credentials can also be generated manually by external means such as cloud provider CLIs and used directly to configure Service Connectors, or automatically generated during Service Connector auto-configuration.

This may be used as a way to grant an external party temporary access to some resources and have the Service Connector automatically become unusable (i.e. expire) after some time. Your long-lived credentials are kept safe, while the Service Connector only stores a short-lived credential.

The following is an example of using Service Connector auto-configuration to automatically generate a short-lived token from long-lived credentials configured for the local cloud provider CLI (AWS in this case):