Configure workflow execution

When using Self-deployed Runtime for extraction, source system credentials (secrets) required for workflow execution are retrieved from your configured secret store. This guide provides steps to configure workflows with Self-deployed Runtime and specify the secret details it uses during workflow execution.

Before you begin

Before configuring Self-deployed Runtime for workflow execution, make sure you have:

• A deployed and active Self-deployed Runtime instance (see Install on Docker Compose or Install on Kubernetes)
• Access to one of the supported secret stores: AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, HashiCorp Vault, Kubernetes Secrets, or environment variables

Did you know?

Your secret store was configured during Self-deployed Runtime deployment. The configuration specified in your deployment determines how secrets are retrieved during workflow execution.

Configure secrets retrieval for workflow execution

Follow these steps to configure Self-deployed Runtime to retrieve secrets from your secret store required for workflow execution. This configuration happens in the Atlan UI when you set up or edit connector workflows.

💪 Did you know?

For each field, you can enter either the name of a secret stored in your secret manager or the actual value. Use secret names when using a secret store with Self-deployed Runtime, or enter values directly if no secret is required.

AWS Secrets Manager

Self-deployed Runtime retrieves the required secrets from AWS Secrets Manager during workflow execution. Follow these steps to configure retrieval under the Self-deployed Runtime configuration section:

• Secret path in Secret Manager: Provide the Amazon Resource Name (ARN) or the path of the secret that contains the sensitive configuration details required for the connector. These details may include credentials such as username, password, or other sensitive information needed by the Self-deployed Runtime to securely access data during workflow execution.
• AWS region: Select the region where your AWS Secrets Manager is located.
• AWS authentication method: Select how you want the Self-deployed Runtime to authenticate when executing the workflow. Choose one:
  • IAM (Recommended): Use this method if the Self-deployed Runtime was configured to use the AWS IAM permissions to access secrets.
  • IAM Assume Role: Use this method if the runtime was configured to access secrets via cross-account roles.
  • AWS Assume Role ARN: Provide the IAM Role ARN that grants the Self-deployed Runtime permission to retrieve secrets.
  • Access Key & Secret Key: Use this method if the runtime was configured to use the AWS Access Key ID and Secret Access Key via environment variables or Kubernetes secrets.

For more information on configuring AWS Secrets Manager during deployment, see the secret storage configuration section in Install on Docker Compose or Install on Kubernetes.

Azure Key Vault

Self-deployed Runtime retrieves secrets from Azure Key Vault during workflow execution. Follow these steps to configure retrieval under the Self-deployed Runtime configuration section:

• Secret path in Secret Manager: Provide the URL of the Azure Key Vault secret that contains the sensitive configuration details required for the connector. These details may include credentials such as username, password, or other sensitive information needed by the Self-deployed Runtime to securely access data during workflow execution.
• Azure authentication method: Select how you want the Self-deployed Runtime to authenticate when accessing the Azure Key Vault secret. Choose one:
  • Managed Identity (Recommended): Use this method if the runtime was configured to use an Azure-managed identity assigned to the runtime environment for authentication.
  • Service Principal Authentication: Use this method if the runtime was configured to authenticate via a Service Principal using Tenant ID, Client ID, and Client Secret.
• Azure Key Vault Name: Provide the name of your Azure Key Vault that stores your secrets.

Azure Key Vault supports multiple authentication methods including client secret, certificate, and managed identity. For detailed authentication setup, see the Authenticating to Azure documentation.

For more information on configuring Azure Key Vault during deployment, see the secret storage configuration section in Install on Docker Compose or Install on Kubernetes.

GCP Secret Manager

Self-deployed Runtime retrieves secrets from GCP Secret Manager during workflow execution. The secret is uniquely identified by its name in GCP Secret Manager, without requiring additional attributes.

• Secret name or ID: Provide the name or resource ID of the secret stored in GCP Secret Manager that contains the credentials required for the connector.

For more information on configuring GCP Secret Manager during deployment, see the secret storage configuration section in Install on Docker Compose or Install on Kubernetes.

HashiCorp Vault

Self-deployed Runtime retrieves secrets from HashiCorp Vault during workflow execution. Follow these steps to configure retrieval under the Self-deployed Runtime configuration section:

• Vault address: Provide the address of your HashiCorp Vault instance (for example https://vault.example.com:8200).
• Vault authentication: Specify the authentication method configured during deployment. This may include:
  • Token-based authentication (vault token or token file path)
  • Other authentication methods configured in your deployment
• Secret path: Provide the path to the secret within Vault that contains the credentials required for the connector (for example secret/data/myapp/database).
• Engine path: Specify the secrets engine path if different from the default secret.

For more information on configuring HashiCorp Vault during deployment, see the secret storage configuration section in Install on Docker Compose or Install on Kubernetes.

Kubernetes Secrets

Self-deployed Runtime retrieves secrets from Kubernetes native secret storage during workflow execution. This option is available when deploying on Kubernetes.

• Secret name: Provide the name of the Kubernetes secret that contains the credentials required for the connector.
• Namespace: Specify the Kubernetes namespace where the secret is stored (defaults to the namespace configured during deployment).

Native Kubernetes secret store

When Dapr is deployed to a Kubernetes cluster, a secret store with the name kubernetes is automatically provisioned. You can use this native Kubernetes secret store with no need to create, deploy, or maintain additional component configuration files.

For more information on configuring Kubernetes Secrets during deployment, see the secret storage configuration section in Install on Kubernetes.

Environment Variables

Self-deployed Runtime retrieves secrets from environment variables during workflow execution.

• Environment variable name: Provide the name of the environment variable that contains the credential required for the connector (for example DATABASE_PASSWORD).

Environment variables must be set in the Self-deployed Runtime environment before deployment. This method is useful for testing or when integrating with container orchestration systems that inject secrets as environment variables.

For more information on configuring environment variables during deployment, see the secret storage configuration section in Install on Docker Compose or Install on Kubernetes.

Additional secret stores

Dapr supports additional secret stores beyond those listed here. For information on other supported secret stores, see the Dapr secret store documentation.

---

Next steps

After configuring the Self-deployed Runtime for workflow execution, return to your connector's setup guide and continue the workflow setup.

Related topics

• Secret management: Conceptual overview of how Self-deployed Runtime handles secrets
• Install on Docker Compose: Deploy Self-deployed Runtime using Docker Compose
• Install on Kubernetes: Deploy Self-deployed Runtime on Kubernetes