 gs://zenml-core_cloudbuild                      ┃┃                       │ gs://zenml-datasets                             ┃

┃                       │ gs://zenml-internal-artifact-store              ┃

┃                       │ gs://zenml-kubeflow-artifact-store              ┃

┃                       │ gs://zenml-project-time-series-bucket           ┃

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

┃ 🌀 kubernetes-cluster │ zenml-test-cluster                              ┃

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

┃  🐳 docker-registry   │ gcr.io/zenml-core                               ┃

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

Long-lived credentials (API keys, account keys)

This is the magic formula of authentication methods. When paired with another ability, such as automatically generating short-lived API tokens, or impersonating accounts or assuming roles, this is the ideal authentication mechanism to use, particularly when using ZenML in production and when sharing results with other members of your ZenML team.

As a general best practice, but implemented particularly well for cloud platforms, account passwords are never directly used as a credential when authenticating to the cloud platform APIs. There is always a process in place that exchanges the account/password credential for another type of long-lived credential:

AWS uses the aws configure CLI command

GCP offers the gcloud auth application-default login CLI commands

Azure provides the az login CLI command

None of your original login information is stored on your local machine or used to access workloads. Instead, an API key, account key or some other form of intermediate credential is generated and stored on the local host and used to authenticate to remote cloud service APIs.