Workflow authorization

The privileges used to authorize a workflow run depend on whether the workflow has an assigned service account:

• No service account assigned (default): The run uses a user's privileges, determined by how the workflow starts.
• Service account assigned: The run uses the privileges of that account.

Use this page to configure who runs your workflows, diagnose privileges errors, and keep your workflows' access current.

When a workflow doesn't run as a service account, the trigger type determines which user's privileges authorize a run.

When you assign a service account with settings.run_as, every run uses that account's privileges. The trigger type and the user who last saved or started the workflow don't change its privileges.

The workflow stores a reference to the account. When a run starts, Kibana obtains a short-lived credential and renews it as needed. Changes to an assigned role affect the account's privileges without saving the workflow again.

On Serverless, the account's privileges are also limited by its creator's access when the account was created. Refer to Roles and privileges in Serverless.

If the account is deleted or lacks a required privilege, the run fails without falling back to a user.

When a workflow run starts, Kibana records the execution identity so you can audit which privileges it used. Refer to Context variables > execution.* for execution context variables.

For workflows assigned to service accounts, Triggered by shows the identity associated with the start of the run. This can be a user or a service account. Run as shows the assigned service account whose privileges authorize the workflow's actions.

The Created By filter on the Workflows page reflects who last saved the workflow, not necessarily who originally created it.

A workflow can call a child workflow with workflow.execute. When neither workflow is assigned a service account, the child runs with the same execution identity as the parent.

When service accounts are involved, each workflow uses its own assignment by default. A child doesn't automatically inherit its parent's service account. If only the parent is assigned a service account, the child uses the identity associated with the parent run's trigger. For example, if a user manually starts the parent, the child uses that user's privileges even when the parent runs as a service account.

All kibana.* and elasticsearch.* steps in a workflow share the same execution identity. There's no separate identity per step type. A step fails with a privileges error if the user or service account lacks the required privilege for that step. For example, a createCase step fails if the execution identity doesn't have Cases privileges.

For a workflow that isn't assigned a service account, credentials belong to the user identified in Whose privileges authorize a run. For a workflow assigned to a service account, refer to Workflows assigned a service account.

Connector steps are an exception. The connector authenticates to the third-party system using its own stored credentials, not the workflow's credential. However, Kibana still records the connector step as having executed under the workflow's execution identity for auditability. Refer to Connector-based actions for details.

For a workflow that isn't assigned a service account, the following actions refresh the stored API key for future runs:

• Saving the workflow again with the desired user.
• Toggling the workflow's Enabled setting off, then back on.

The following authorization errors can cause a workflow step to fail: