dvantages over the implicit authentication method:you don't need to install and configure the GCP CLI on your host

you don't need to care about enabling your other stack components (orchestrators, step operators and model deployers) to have access to the artifact store through GCP Service Accounts and Workload Identity

you can combine the GCS artifact store with other stack components that are not running in GCP

For this method, you need to create a user-managed GCP service account, grant it privileges to read and write to your GCS bucket (i.e. use the Storage Object Admin role) and then create a service account key.

With the service account key downloaded to a local file, you can register a ZenML secret and reference it in the GCS Artifact Store configuration as follows:

# Store the GCP credentials in a ZenML

zenml secret create gcp_secret \

--token=@path/to/service_account_key.json

# Register the GCS artifact store and reference the ZenML secret

zenml artifact-store register gcs_store -f gcp \

--path='gs://your-bucket' \

--authentication_secret=gcp_secret

# Register and set a stack with the new artifact store

zenml stack register custom_stack -a gs_store ... --set

For more, up-to-date information on the GCS Artifact Store implementation and its configuration, you can have a look at the SDK docs .

How do you use it?

Aside from the fact that the artifacts are stored in GCP Cloud Storage, using the GCS Artifact Store is no different from using any other flavor of Artifact Store.

PreviousAmazon Simple Cloud Storage (S3)

NextAzure Blob Storage

Last updated 19 days ago