 at the root URL path.

Secret Store configurationUnless explicitly disabled or configured otherwise, the ZenML server will use the SQL database as a secrets store backend where secret values are stored. If you want to use an external secrets management service like the AWS Secrets Manager, GCP Secrets Manager, Azure Key Vault, HashiCorp Vault or even your custom Secrets Store back-end implementation instead, you need to configure it in the Helm values. Depending on where you deploy your ZenML server and how your Kubernetes cluster is configured, you will also need to provide the credentials needed to access the secrets management service API.

Important: If you are updating the configuration of your ZenML Server deployment to use a different secrets store back-end or location, you should follow the documented secrets migration strategy to minimize downtime and to ensure that existing secrets are also properly migrated.

Using the SQL database as a secrets store backend (default)

The SQL database is used as the default location where the ZenML secrets store keeps the secret values. You only need to configure these options if you want to change the default behavior.

It is particularly recommended to enable encryption at rest for the SQL database if you plan on using it as a secrets store backend. You'll have to configure the secret key used to encrypt the secret values. If not set, encryption will not be used and passwords will be stored unencrypted in the database. This value should be set to a random string with a recommended length of at least 32 characters, e.g.:

generate a random string with Python:

from secrets import token_hex

token_hex(32)

or with OpenSSL:

openssl rand -hex 32

then configure it in the Helm values:

zenml:

# ...

# Secrets store settings. This is used to store centralized secrets.

secretsStore:

# The type of the secrets store

type: sql

# Configuration for the SQL secrets store

sql:

encryptionKey: 0f00e4282a3181be32c108819e8a860a429b613e470ad58531f0730afff64545