Using Secrets in Workflows

You can configure a secret to access an S3 bucket by first configuring a volume for your workflow. The image below has configured persistent volume test-volume for the workflow. Clicking Add Ingress will bring up a menu where you can configure data ingress for your workflow.

The image below has set up an ingress configuration which pulls my-input.tgz from s3://my-bucket using my-user-s3-secret and stages the file at the root of the ephemeral volume via URI file://my-input.tgz. You can save this configuration by clicking OK at the bottom right of the menu.

After configuring the ingress for your volume, you can return to editing the remainder of your workflow.

You can also configure a secret to access a container in a private registry by first selecting a job’s configuration to edit. In the image below, we have selected job hello to edit.

You can specify your container from a private registry and secret to access it by navigating to the Environment tab of your job and inputting the URI of the private container you’d like to use, the container name, and tag. You can configure the secret to access this container by using the drop down and selecting the OCI secret you’d like to use. In the image below, we would like to use a container at URI docker://privaterepo/alpine-extra:latest. To access this container, we use OCI secret my-oci-secret.

Image Pull Secrets: When editing a workflow job or service, you can specify an image pull secret using the Secret dropdown in the image configuration section. This dropdown is filtered to show only secrets of type SECRET_TYPE_IMAGE that are visible to your user account.

Migration from legacy workflows: If you open an existing workflow draft that used the unsupported image.secrets (plural map) field, the Web UI will automatically convert the first entry to the singular image.secret field. If the legacy workflow had multiple secrets listed, only the first one will be preserved. You should verify that your workflow uses only one image pull secret.

Inside of the YAML workflow specification, secrets are referenced via a URI of the form secret://<scope>/<secret name> where scope is user, group, organization, or cluster. The account scope is also accepted as a legacy alias for group. For instance, consider the following for an S3 secret called my-user-s3-secret with user scope:

[snip...]
    ingress:
      - source:
          uri: s3://my-bucket/my-input.tgz
          secret: secret://user/my-user-s3-secret

Of course a secret with the group scope would necessitate the following change in the URI reference.

[snip...]
    ingress:
      - source:
          uri: s3://my-bucket/my-input.tgz
          secret: secret://group/my-user-s3-secret

For an image registry secret for a user:

[snip...]
    image:
      uri: docker://privaterepo/alpine-extra:latest
      secret: secret://user/my-oci-secret

For an image registry secret for a group:

[snip...]
    image:
      uri: docker://privaterepo/alpine-extra:latest
      secret: secret://group/my-oci-secret

Complete details of secret usage with various storage locations and OCI registries can be found in the Fuzzfile Syntax Guide.