What is a ZenML secret
ZenML secrets are groupings of key-value pairs which are securely stored by your ZenML secrets manager. Additionally, a secret always has a name which allows you to fetch or reference them in your pipelines and stacks.How to register a secret
To register a secret, you’ll need a secrets
manager in your active stack.
<SECRET_NAME>
and a key-value pair, you can then run the following CLI command:
--interactive/-i
parameter:
@
syntax to indicate to ZenML that the value needs to be read from a file:
Interactively register missing secrets for your stack
If you’re using components with secret references in your stack, you need to make sure that the stack contains a secrets manager and all the referenced secrets exist in this secrets manager. To make this process easier, you can use the following CLI command to interactively register all secrets for a stack:How to use registered secrets
Reference secrets in stack component attributes and settings
Some of the components in your stack require you to configure them with sensitive information like passwords or tokens so they can connect to the underlying infrastructure. Secret references allow you to configure these components in a secure way by not specifying the value directly but instead referencing a secret by providing the secret name and key. Referencing a secret for the value of any string attribute of your stack components, simply specify the attribute using the following syntax:{{<SECRET_NAME>.<SECRET_KEY>}}
For example:
ZENML_SECRET_VALIDATION_LEVEL
to disable or control the degree to which ZenML validates your secrets:
- Setting it to
NONE
disables any validation. - Setting it to
SECRET_EXISTS
only validates the existence of secrets. This might be useful if the machine you’re running on only has permissions to list secrets but not actually read their values. - Setting it to
SECRET_AND_KEY_EXISTS
(the default) validates both the secret existence as well as the existence of the exact key-value pair.
Fetch secret values in a step
You can access the secrets manager directly from within your steps through theStepContext
. This allows you to use your secrets for querying APIs from within your step without hard-coding your access keys. Don’t forget to make the appropriate decision regarding caching as it will be disabled by default when the StepContext
is passed into the step.
This will only work if the environment that your orchestrator uses to execute
steps has access to the secrets manager. For example a local secrets manager
will not work in combination with a remote orchestrator.