Skip to main content

Masking Parameters

Masking parameters help protect sensitive data by preventing it from being exposed in workflow executions.

You can mask data in a workflow definition using the following parameters:

  • _secrets
  • _masked
  • maskedFields

Masking sensitive data

When a value is masked, it is replaced with ***, ensuring that confidential information is hidden in workflow executions.

For example:

{
"_secrets": {
"my-secret-key": "my-secret-value"
}
}

This is displayed in the workflow execution as:

{
"_secrets": "***"
}

Passing sensitive data between tasks

To pass sensitive data from one task's output to a subsequent task, nest the sensitive fields inside either the _secrets or _masked object in the receiving task’s input parameters as follows:

{
"_secrets": {
"parameter": "${previousTaskRef.output.someOutputParameter}"
}
}

See the complete example in Passing sensitive data between tasks.

Masking secret references and secret values

The system masks fields that reference workflow secrets during execution. To reference a workflow secret, use the following syntax:

${workflow.secrets.<secretName>}

where <secretName> is the name of your secret. When the system resolves these expressions, it replaces their values with *** anywhere they appear, including workflow inputs, task inputs, task outputs, and the execution JSON.

For example,

 "apiKey": "${workflow.secrets.my_api_key}"

is displayed during execution as

"apiKey": "***"

Resolved secret values are always masked, regardless of the context. This ensures that the underlying secret value is never exposed at any point in the workflow execution.

Note

Secrets used within task expressions, such as in INLINE scripts or JSON JQ TRANSFORM expressions, are also masked during execution. When a secret is referenced or resolved inside an expression, its value is replaced with *** in task inputs, task outputs, and the execution details.

Workflow behavior with masked parameters

Behavior on restarting workflows with masked values: When a workflow with masked values reaches a terminal state and is removed from the primary execution:

  • Values with the _masked parameter are retained during archiving. If the workflow is restarted, the original data will remain accessible.
  • Values with the _secrets parameter are permanently replaced with *** during archiving. As a result, restarting the workflow might cause failures if any tasks rely on the masked data.
  • Values within the maskedFields parameter are permanently replaced with *** during archiving. As a result, restarting the workflow might cause failures if any tasks rely on the masked data.

Examples

Using _secrets parameter

Consider a workflow with a task having an input masked using _secrets:

     "inputParameters": {
"_secrets": "${workflow.input.somedata}"
}

Here’s the complete workflow definition:

{
"name": "workflow-with-secrets-param",
"description": "Sample workflow containing _secrets params",
"version": 1,
"tasks": [
{
"name": "simple",
"taskReferenceName": "simple_ref",
"inputParameters": {
"_secrets": "${workflow.input.somedata}"
},
"type": "SIMPLE"
}
],
"inputParameters": [
"somedata"
],
"schemaVersion": 2
}

When you run this workflow, the system masks the parameters in the execution results within the task input and the workflow input.

Masked inputs using the _secrets parameter

Using _masked parameter

Consider a workflow with a task having an input parameter masked using _masked:

     "inputParameters": {
"_masked": "${workflow.input.somedata}"
}

Here’s the complete workflow definition:

{
"name": "workflow-with-masked-param",
"description": "Sample workflow containing _masked params",
"version": 1,
"tasks": [
{
"name": "simple",
"taskReferenceName": "simple_ref",
"inputParameters": {
"_masked": "${workflow.input.somedata}"
},
"type": "SIMPLE"
}
],
"inputParameters": [
"somedata"
],
"schemaVersion": 2
}

When you run this workflow, the system masks the parameters in the execution results within the task input and the workflow input.

Masked inputs using the masked parameter

Using maskedFields parameter

Consider a workflow definition with input parameters input1 and input2, and output parameter output1.

{
"name": "newMaskingParam",
"description": "Workflow for testing new masking params",
"version": 1,
"tasks": [
{
"name": "http",
"taskReferenceName": "http_ref",
"inputParameters": {
"uri": "https://orkes-api-tester.orkesconductor.com/api",
"method": "GET",
"accept": "application/json",
"contentType": "application/json",
"encode": true
},
"type": "HTTP"
}
],
"inputParameters": [
"input1",
"input2"
],
"outputParameters": {
"output1": "${http_ref.output}"
},
"schemaVersion": 2,
"maskedFields": [
"input1",
"input2"
]
}

In this example, both input fields are masked using:

"maskedFields": [
"input1",
"input2"
]

After running the execution, the values for input1 and input2 appear as *** in the workflow input, confirming that the masking is applied successfully.

Execution with fields masked using maskedfields parameter

Next, update the workflow definition to mask the input1 and output1 parameters:

//workflow definition
"maskedFields": [
"input1",
"output1"
]

When you run the execution, input1 and output1 are masked.

Execution with fields masked using maskedfields parameter

Passing sensitive data between tasks

Consider a workflow where a sensitive value from one task’s output needs to be passed to another task. To ensure the data remains masked, nest the parameter under _secrets in the receiving task’s input parameters.

{
"name": "workflow-pass-sensitive-data",
"description": "Workflow passing sensitive parameters between tasks",
"version": 1,
"tasks": [
{
"name": "simple-demo",
"taskReferenceName": "simple_demo_ref",
"type": "SIMPLE"
},
{
"name": "simple",
"taskReferenceName": "simple_ref",
"inputParameters": {
"_secrets": {
"parameter": "${simple_demo_ref.output.result}"
}
},
"type": "SIMPLE"
}
],
"schemaVersion": 2
}
note

You can also use the _masked parameter to mask the data in this scenario.

When you run this workflow, the system masks the sensitive data from simple_demo_ref.output.result in the execution results because you nested it under _secrets as the input parameter to the second task.

Passing data between tasks

Masking secret references in workflow definitions

The following workflow calls an external payments API. The HTTP task sends an Authorization header that uses a secret stored as payment_api_token in the workflow secrets.

Store the API token as a secret in Conductor by navigating to Definitions > Secrets.

Secret stored in Orkes Conductor

Next, create the workflow under Definitions > Workflow using the following definition:

{
"name": "charge_customer",
"description": "Charge a customer using an external payments API",
"version": 1,
"tasks": [
{
"name": "charge_payment",
"taskReferenceName": "charge_payment_ref",
"type": "HTTP",
"inputParameters": {
"uri": "https://orkes-api-tester.orkesconductor.com/api",
"method": "POST",
"headers": {
"Authorization": "Bearer ${workflow.secrets.payment_api_token}",
"Content-Type": "application/json"
},
"body": {
"customerId": "${workflow.input.customerId}",
"amount": "${workflow.input.amount}",
"currency": "USD"
}
}
}
],
"inputParameters": [
"customerId",
"amount"
],
"schemaVersion": 2
}

In this workflow, the Authorization header retrieves its value from the secret using "Authorization": "Bearer ${workflow.secrets.payment_api_token}".

During execution, the task input appears as:

Secret masked in Orkes Conductor

The Authorization header value is masked because it resolves from ${workflow.secrets.payment_api_token}. Any occurrence of this secret value elsewhere is automatically masked as well.