diff --git a/deploy-manage/deploy/elastic-cloud/serverless-faq.md b/deploy-manage/deploy/elastic-cloud/serverless-faq.md
index 74727e2ab1d..642e73e2447 100644
--- a/deploy-manage/deploy/elastic-cloud/serverless-faq.md
+++ b/deploy-manage/deploy/elastic-cloud/serverless-faq.md
@@ -32,8 +32,8 @@ User-initiated data recovery is anticipated in a future release. You can follow
## Security, compliance, and access
-**Q: How can I create {{serverless-full}} service accounts?**
-A: Create API keys for service accounts in your {{serverless-short}} projects. You can create them in {{kib}}, with the {{es}} API, or as code with Terraform. Refer to [](/deploy-manage/api-keys/serverless-project-api-keys.md) for details.
+**Q: How can I create {{serverless-full}} service accounts?**
+A: You can [create user-managed service accounts in {{kib}}](/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md) for use within {{kib}} applications, such as [Workflows](/explore-analyze/workflows.md). For programmatic access from external applications, use [API keys](/deploy-manage/api-keys/serverless-project-api-keys.md).
**Q: Can I configure {{es}} authentication realms (for example, native realm) in {{serverless-short}} projects?**
A: No. {{serverless-short}} uses a different authentication model and does not support [{{es}} authentication realms](/deploy-manage/users-roles/cluster-or-deployment-auth/authentication-realms.md). Project-level access is handled through [Serverless project API keys](/deploy-manage/api-keys/serverless-project-api-keys.md), and user authentication is managed at the [{{ecloud}} organization level](/deploy-manage/users-roles/cloud-organization.md) (including SAML SSO).
diff --git a/deploy-manage/toc.yml b/deploy-manage/toc.yml
index 692577bcd10..133e8314a5a 100644
--- a/deploy-manage/toc.yml
+++ b/deploy-manage/toc.yml
@@ -625,6 +625,9 @@ toc:
- file: users-roles/cluster-or-deployment-auth/anonymous-access.md
- file: users-roles/cluster-or-deployment-auth/token-based-authentication-services.md
- file: users-roles/cluster-or-deployment-auth/service-accounts.md
+ children:
+ - file: users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md
+ - file: users-roles/cluster-or-deployment-auth/authenticate-kibana-api-with-service-account.md
- file: users-roles/cluster-or-deployment-auth/internal-users.md
- file: users-roles/cluster-or-deployment-auth/operator-privileges.md
children:
diff --git a/deploy-manage/users-roles/cloud-organization.md b/deploy-manage/users-roles/cloud-organization.md
index b440c0f4e1f..1100b8f1e06 100644
--- a/deploy-manage/users-roles/cloud-organization.md
+++ b/deploy-manage/users-roles/cloud-organization.md
@@ -24,6 +24,8 @@ You can perform the following tasks to control access to your Cloud organization
You can also control programmatic access to {{ecloud}}, your deployments, and your projects using [API keys](/deploy-manage/api-keys.md).
+For workloads that run within {{kib}} applications in {{serverless-short}} projects, you can also use [user-managed service accounts](/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md).
+
:::{tip}
If you're using {{ech}}, then you can also manage users and control access [at the deployment level](/deploy-manage/users-roles/cluster-or-deployment-auth.md).
:::
diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/authenticate-kibana-api-with-service-account.md b/deploy-manage/users-roles/cluster-or-deployment-auth/authenticate-kibana-api-with-service-account.md
new file mode 100644
index 00000000000..6b78e1084c5
--- /dev/null
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/authenticate-kibana-api-with-service-account.md
@@ -0,0 +1,72 @@
+---
+navigation_title: Authenticate to Kibana APIs
+applies_to:
+ stack: ga 9.6+
+ serverless: unavailable
+description: Create a service token and use a user-managed service account to authenticate to Kibana APIs.
+products:
+ - id: kibana
+ - id: elasticsearch
+ - id: cloud-hosted
+ - id: cloud-enterprise
+ - id: cloud-kubernetes
+ - id: elastic-stack
+---
+
+# Authenticate to the {{kib}} API with a service account [authenticate-kibana-api-service-account]
+
+Use a service token to authenticate programmatic requests to {{kib}} as a user-managed service account. The account provides a non-human identity whose privileges come from its assigned roles.
+
+Service accounts can't be used with external applications on {{serverless-full}}. For programmatic access from external applications, use [API keys](/deploy-manage/api-keys.md).
+
+## Before you begin [authenticate-kibana-api-service-account-prerequisites]
+
+Before you create a service token, make sure you have the following:
+
+- You need an existing user-managed service account. If you don't have one, [create a service account in {{kib}}](manage-service-accounts-in-kibana.md#create-service-account-kibana).
+- You need the `manage_security` cluster privilege to create a service token for a user-managed account. The `manage_service_account` privilege permits token management only for built-in accounts in the `elastic` namespace.
+
+## Create a service token for your application [create-service-account-api-token]
+
+{{kib}} creates and stores a credential when you create an account in the UI. That credential is used for workload integrations and isn't displayed. For your application, create an additional service token. The following example uses an existing account with the principal `kibana/automation-client`:
+
+1. Use the [create service account token API]({{es-apis}}operation/operation-security-create-service-token) to create a token for the account:
+
+ ```console
+ POST /_security/service/kibana/automation-client/credential/token/production
+ ```
+
+2. Copy the `token.value` from the response and store it securely, such as in a secrets manager. Service tokens don't expire, and you can't retrieve this value again.
+
+## Call a {{kib}} API [call-kibana-api-service-account]
+
+To call the {{kib}} API using the service account identity, send the token with the `Bearer` authentication scheme:
+
+```shell
+curl --request GET "$KIBANA_URL/api/spaces/space" \
+ --header "Authorization: Bearer $SERVICE_ACCOUNT_TOKEN"
+```
+
+
+For requests that change data, also include the headers required by that API, such as `kbn-xsrf`.
+
+## Call an {{es}} API [call-elasticsearch-api-service-account]
+
+You can use the same token to authenticate to {{es}}. For example, verify the account's identity with the authenticate API:
+
+```shell
+curl --request GET "$ELASTICSEARCH_URL/_security/_authenticate" \
+ --header "Authorization: Bearer $SERVICE_ACCOUNT_TOKEN"
+```
+
+## Remove access [remove-service-account-api-access]
+
+Service tokens don't expire. When an application no longer needs access, use the [delete service account token API]({{es-apis}}operation/operation-security-delete-service-token) to delete only its token:
+
+```console
+DELETE /_security/service/kibana/automation-client/credential/token/production
+```
+
+Deleting the token stops requests that use it without affecting the account or its other service tokens.
+
+To prevent new authentications with any of the account's service tokens, [deactivate the account](manage-service-accounts-in-kibana.md#disable-service-account). To permanently remove the identity and its associated credentials, [delete the account in {{kib}}](manage-service-accounts-in-kibana.md#delete-service-account-kibana).
diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md b/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md
index 431fa115996..3ee6d6c0f3a 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md
@@ -416,6 +416,7 @@ xpack.security.authc.http.schemes: [apikey, bearer, basic, something-custom]
With this configuration, you can send requests to {{kib}} with the `Authorization` header using `ApiKey`, `Bearer`, `Basic` or `Something-Custom` HTTP schemes (case insensitive). Under the hood, {{kib}} relays this header to {{es}}, then {{es}} authenticates the request using the credentials in the header.
+{applies_to}`{stack: ga 9.6+, serverless: unavailable}` User-managed service accounts provide another option for programmatic access to {{kib}} APIs. Their service tokens use the `Bearer` scheme, but they can't be used to log in to the {{kib}} UI. To create a token and authenticate a request, refer to [Authenticate to the {{kib}} API with a service account](authenticate-kibana-api-with-service-account.md).
### Embedded content authentication [embedded-content-authentication]
diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md b/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md
index 8c22a8a00cd..082c23ae042 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md
@@ -225,6 +225,13 @@ These privileges control specific actions on workflows. Selecting **All** includ
| **Update managed workflows** {applies_to}`stack: ga 9.5+` | Edit the workflows that Elastic provides. |
:::
+:::{warning}
+:applies_to: {"stack": "ga 9.6+", "serverless": "ga"}
+When you edit a workflow that runs as a service account, subsequent runs continue to use that account's privileges. Your changes can therefore use privileges you don't personally have. Grant workflow edit access only to users you trust to use those privileges.
+
+Adding, changing, or removing a service account assignment, and editing or deleting a workflow assigned to a service account, also require the `manage_security` cluster privilege. For account assignment instructions and required privileges, refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
+:::
+
## Privileges in the Management group [kibana-privileges-management]
Each of the following privileges controls access to a different feature.
diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md b/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md
new file mode 100644
index 00000000000..9de01a8dc2f
--- /dev/null
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md
@@ -0,0 +1,142 @@
+---
+navigation_title: Manage service accounts
+applies_to:
+ stack: ga 9.6+
+ serverless: ga
+description: Create, review, take out of service, and delete user-managed service accounts for Kibana workloads.
+products:
+ - id: kibana
+ - id: elasticsearch
+ - id: cloud-serverless
+ - id: cloud-hosted
+ - id: cloud-enterprise
+ - id: cloud-kubernetes
+ - id: elastic-stack
+---
+
+# Create and manage service accounts in {{kib}} [manage-service-accounts-kibana]
+
+Create user-managed service accounts and assign roles to control programmatic access to {{es}} and {{kib}} APIs. Accounts created in {{kib}} are ready to use with {{kib}} applications such as [Workflows](/explore-analyze/workflows.md). On {{stack}} deployments, you can also use them with your own applications by [creating a service token](authenticate-kibana-api-with-service-account.md#create-service-account-api-token).
+
+:::{note}
+:applies_to: serverless: ga
+On {{serverless-short}}, user-managed service accounts can only be used within {{kib}} applications. For programmatic access from external applications, use [API keys](/deploy-manage/api-keys.md).
+:::
+
+{applies_to}`serverless: unavailable` You can also create service accounts for external applications through the [{{es}} API]({{es-apis}}operation/operation-security-put-user-managed-service-account), although accounts created this way can't be assigned to workloads in {{kib}} applications.
+
+## Before you begin [manage-service-accounts-before-you-begin]
+
+Before you create or manage service accounts, check these requirements:
+
+- Sign in to {{kib}} as a user with the `manage_security` cluster privilege. Without it, the **Service accounts** page isn't available.
+- {applies_to}`self: ga` Set [`xpack.encryptedSavedObjects.encryptionKey`](kibana://reference/configuration-reference/security-settings.md#xpack-encryptedsavedobjects-encryptionkey) in `kibana.yml`. {{kib}} uses this key to encrypt the stored credential.
+- On {{stack}} deployments, service accounts must be enabled in {{kib}}. This is the default. If your deployment turns them off, set [`xpack.security.serviceAccounts.enabled`](kibana://reference/configuration-reference/security-settings.md#service-account-settings) to `true` to re-enable them.
+
+## Create a service account [create-service-account-kibana]
+
+Create a service account with the roles your workloads need:
+
+1. Find **Service accounts** in the navigation menu or use the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md).
+2. Click **Create account**.
+3. In the **Name** field, enter a unique name of up to 128 characters. The name must start with a letter or number and can contain letters, numbers, hyphens, and underscores.
+4. Optional: In the **Description** field, describe what the account is used for.
+5. Under **Set privileges**, select one or more predefined or custom roles that grant the privileges the account needs. To create a role, click **Create new role**.
+
+ For details on predefined roles and how to create custom roles, refer to:
+
+ - {{stack}} deployments: [Built-in roles](elasticsearch://reference/elasticsearch/roles.md) and [role management in {{kib}}](kibana-role-management.md).
+ - {{serverless-short}} projects: [Predefined roles](/deploy-manage/users-roles/cloud-organization/user-roles.md#general-assign-user-roles-table) and [custom roles](/deploy-manage/users-roles/serverless-custom-roles.md). Before you assign roles, review the [role limits in {{serverless-short}}](#service-account-serverless-roles).
+
+6. Review the selected roles, and click **Create account**.
+7. Confirm that the account appears in the **Service accounts** table with the roles you selected. On {{stack}} deployments, the account uses the principal `kibana/`.
+
+Your service account is now ready to use in {{kib}} applications such as [Workflows](/explore-analyze/workflows.md). {{kib}} manages the credential for you. You don't need to copy a secret, and no token is displayed.
+
+{applies_to}`serverless: unavailable` To use the account from an external API client, [create a separate named service token](authenticate-kibana-api-with-service-account.md#create-service-account-api-token).
+
+### Roles and privileges in {{serverless-short}} [service-account-serverless-roles]
+```{applies_to}
+serverless: ga
+```
+
+A service account can have up to 50 roles. Its privileges come from its assigned roles and cannot exceed the access its creator had when the account was created.
+
+When a workload uses [cross-project search](/explore-analyze/cross-project-search.md), its service account's predefined roles apply across linked projects. For a custom role to grant access to a linked project, that project must define a role with the same name. Custom roles aren't copied between projects.
+
+
+## Review service accounts [review-service-accounts-kibana]
+
+The **Service accounts** table shows each account's name, description, roles, creator, and number of bound workloads. A **Disabled** badge identifies accounts that can't authenticate. Use the **Role** filter to find accounts assigned to specific roles.
+
+When an account has bound workloads, click **View** in the **Workloads** column to review them.
+
+## Update a service account [update-service-account-kibana]
+
+You can't update service accounts in the {{kib}} UI. On {{serverless-short}}, to change an account's assigned roles or description, [delete the account](#delete-service-account-kibana) and [create a new one](#create-service-account-kibana). On {{stack}} deployments, you can update accounts through the {{es}} API.
+
+:::{tip}
+To change a service account's privileges, you can edit a role already assigned to it without changing the account's role assignments. Changes to a role also affect other users and service accounts assigned that role.
+:::
+
+### Update or deactivate an account through the {{es}} API [disable-service-account]
+```{applies_to}
+serverless: unavailable
+```
+
+Use the [create or replace user-managed service account API]({{es-apis}}operation/operation-security-put-user-managed-service-account) to update an account's roles or description, or to deactivate it by setting `enabled` to `false`.
+
+The PUT request replaces the complete account definition. Send the full definition, including every role, the description, and the `enabled` value you want to preserve. A role left out of the `roles` list is no longer assigned, and an omitted `description` is cleared. If you omit `enabled`, it defaults to `true`. The `roles` field itself is required.
+
+For example, this request deactivates an account by sending its full definition with `enabled` set to `false`:
+
+```console
+PUT /_security/service/kibana/workflow-runner
+{
+ "roles": [ "workflow_runner" ],
+ "description": "Runs incident response workflows",
+ "enabled": false
+}
+```
+
+Setting `enabled: false` prevents authentication with the account's service tokens without deleting the account. It doesn't invalidate [short-lived access tokens](token-based-authentication-services.md#token-authentication-access-token) already issued to run workloads as the account. API keys already issued to the account also remain valid.
+
+To reactivate the account, send the complete definition again with `enabled` set to `true`.
+
+[Workflows assigned to an account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md#assign-workflow-service-account) that has `enabled: false` fail the next time they run. They don't fall back to the user who starts or edits the workflow.
+
+## Delete a service account [delete-service-account-kibana]
+
+Deleting a service account is permanent. On {{stack}} deployments, if you only need to temporarily prevent the account from authenticating, [deactivate it](#disable-service-account) instead.
+
+To delete a service account:
+
+1. On the **Service accounts** page, find the account.
+2. From the **Actions** column, click **Delete**.
+3. Review the confirmation:
+ - If no workloads are bound, click **Delete account**.
+ - If workloads are bound, review the list. To delete the account without removing the bindings, click **Force delete account**.
+
+If you force delete an account, workloads assigned to it fail on their next run. To restore access, assign each affected workload a valid service account. This reassignment is required even if you recreate the deleted account with the same name. For Workflows, [assign a service account to each affected workflow](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md#assign-workflow-service-account).
+
+
+### Credentials after deletion in {{stack}} deployments [delete-service-account-stack-credentials]
+```{applies_to}
+serverless: unavailable
+```
+
+Deleting an account through {{kib}} attempts to remove every service token, including the credential it stores for workloads and tokens created outside {{kib}}. It also attempts to invalidate any short-lived access tokens used to run workloads as the account. If any credential cleanup fails, {{kib}} completes the deletion and reports a warning.
+
+A service token left behind after deletion can't authenticate, but it prevents you from creating another account with the same name until you delete the token.
+
+:::{important}
+API keys owned by the account aren't invalidated when you delete the account. {{rules-ui}} and tasks that obtained an API key while authenticated as the account can continue to run with that key. To revoke this access, [invalidate the API keys]({{es-apis}}operation/operation-security-invalidate-api-key) explicitly.
+:::
+
+## Next steps [manage-service-accounts-next-steps]
+
+Use these guides to work with service accounts and learn more about their credentials:
+
+- [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
+- {applies_to}`serverless: unavailable` [Authenticate to the {{kib}} API with a service account](authenticate-kibana-api-with-service-account.md).
+- Learn more about [service account types and credentials](service-accounts.md).
diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md b/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
index 86233b3b72e..64a66da9db7 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
@@ -3,32 +3,41 @@ mapped_pages:
- https://www.elastic.co/guide/en/elasticsearch/reference/current/service-accounts.html
applies_to:
stack: all
+ serverless: ga
+description: Learn how built-in and user-managed service accounts provide non-human identities for Elastic services and workloads.
products:
- id: elasticsearch
+ - id: kibana
+ - id: cloud-serverless
---
# Service accounts [service-accounts]
-The {{stack-security-features}} provide *service accounts* specifically for integration with external services that connect to {{es}}, such as {{fleet}} server. Service accounts have a fixed set of privileges and cannot authenticate until you create a service account token for them. Additionally, service accounts are predefined in code, and are always enabled.
+A service account is a non-human identity for a service or workload. Unlike a user, a service account isn't associated with a person and can't log in to the {{kib}} UI.
-A service account corresponds to a specific external service. You create service account tokens for a service account. The service can then authenticate with the token and perform relevant actions. For example, {{fleet}} server can use its service token to authenticate with {{es}} and then manage its own API keys.
+Service accounts authenticate with tokens. The account defines the identity and privileges, while the token is a credential for that identity.
-You can create multiple service tokens for the same service account, which prevents credential sharing between multiple instances of the same external service. Each instance can assume the same identity while using their own distinct service token for authentication.
+::::{important}
+Don't use service accounts to authenticate individual users. Service account credentials are for software and workloads, not people.
+::::
-Service accounts provide flexibility over [built-in users](built-in-users.md) because they:
+This page refers to {{ech}}, {{ece}}, {{eck}}, and self-managed deployments as {{stack}} deployments. In these environments, {{es}} stores and manages user-managed service accounts. In {{serverless-full}} projects, {{ecloud}} manages these accounts at the organization level. These differences affect account identifiers, credentials, and the available management APIs.
-* Do not rely on the [internal `native` realm](native.md), and aren’t always required to rely on the `.security` index
-* Use a [role descriptor]({{es-apis}}operation/operation-security-create-api-key) named after the service account principal instead of traditional roles
-* Support multiple credentials through service account tokens
+$$$service-accounts-explanation$$$
-Service accounts are not included in the response of the [get users API]({{es-apis}}operation/operation-security-get-user). To retrieve a service account, use the [get service accounts API]({{es-apis}}operation/operation-security-get-service-accounts). Use the [get service account credentials API]({{es-apis}}operation/operation-security-get-service-credentials) to retrieve all service credentials for a service account.
+Each service account has a unique identifier, called a principal. In {{stack}} deployments, the principal has the form `/`. The `namespace` groups related accounts, and the `service` name must be unique within that namespace.
+
+## Service account types [service-account-types]
+Service accounts can be built-in, with privileges defined by Elastic, or user-managed, with privileges determined by the roles you assign.
-## Service accounts usage [service-accounts-explanation]
+### Built-in service accounts [built-in-service-accounts]
-Service accounts have a [unique principal]({{es-apis}}operation/operation-security-get-service-accounts#security-api-get-service-accounts-path-params) that takes the format of `/`, where the `namespace` is a top-level grouping of service accounts, and `service` is the name of the service and must be unique within its namespace.
+Built-in service accounts are predefined in code, always enabled, and have fixed privileges.
-Service accounts are predefined in code. The following service accounts are available:
+A built-in service account corresponds to a specific service.
+
+The following built-in accounts are available:
`elastic/fleet-server`
: The service account used by the {{fleet}} server to communicate with {{es}}.
@@ -36,54 +45,101 @@ Service accounts are predefined in code. The following service accounts are avai
`elastic/kibana`
: The service account used by {{kib}} to communicate with {{es}}.
-::::{important}
-Do not attempt to use service accounts for authenticating individual users. Service accounts can only be authenticated with service tokens, which are not applicable to regular users.
-::::
+The `elastic` namespace is reserved for built-in accounts.
+
+In {{stack}}, you can create and delete service tokens for these accounts, but you can't change their predefined privileges. On {{serverless-short}}, Elastic manages their credentials.
+
+### User-managed service accounts [user-managed-service-accounts]
+```{applies_to}
+stack: ga 9.6+
+serverless: ga
+```
+
+You create user-managed service accounts and assign roles to control their privileges. These accounts belong to the deployment on {{stack}} or to the Cloud organization on {{serverless-short}}, rather than to the user who created them.
+
+In {{stack}}, accounts created in {{kib}} use the `kibana` namespace, and their principals have the form `kibana/`. On {{serverless-short}}, accounts have a generated identifier that is independent of the name you enter in {{kib}}.
+
+Use a user-managed service account when your workload needs its own identity to access {{es}} or {{kib}} APIs. Assign the roles required by the workload.
+
+[Workflows](/explore-analyze/workflows.md) is the only {{kib}} application that supports directly assigning a service account as the execution identity of a workload. To use this integration, create the service account in {{kib}}, which manages the credential for you.
+
+:::{note}
+:applies_to: serverless: ga
+On {{serverless-short}}, user-managed service accounts can only be used within {{kib}} applications. The {{es}} service account APIs aren't available for these accounts. For programmatic access from external applications, use [API keys](/deploy-manage/api-keys.md).
+:::
+To manage service accounts and use them in your workloads:
+- [Create and manage service accounts in {{kib}}](manage-service-accounts-in-kibana.md).
+- {applies_to}`serverless: unavailable` [Authenticate to the {{kib}} API with a service account](authenticate-kibana-api-with-service-account.md).
+
+To use service accounts with {{kib}} Workflows, refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
+
+On {{stack}}, the {{es}} API reference also documents these operations:
+
+- [Create or replace an account]({{es-apis}}operation/operation-security-put-user-managed-service-account).
+- [Delete an account]({{es-apis}}operation/operation-security-delete-user-managed-service-account).
## Service account tokens [service-accounts-tokens]
+```{applies_to}
+stack: all
+serverless: unavailable
+```
-A service account token, or service token, is a unique string that a service uses to authenticate with {{es}}. For a given service account, each token must have a unique name. Because tokens include access credentials, they should always be kept secret by whichever client is using them.
+A service account token, or service token, is a credential that a service or workload uses to authenticate requests to {{es}} or {{kib}} APIs. Treat service tokens as secrets: anyone who has a valid token can authenticate as the service account.
-Service tokens can be backed by either the `.security` index (recommended) or the `service_tokens` file. You can create multiple service tokens for a single service account, which enables multiple instances of the same service to run with different credentials.
+For example, {{fleet}} server uses a service token to authenticate with {{es}} and manage its own API keys. You can create multiple service tokens for the same service account. This lets multiple instances of a service use the same identity without sharing credentials.
-You must create a service token to use a service account. You can create a service token using either:
+:::{note}
+:applies_to: stack: ga 9.6+
+When you [create a user-managed service account in {{kib}}](manage-service-accounts-in-kibana.md), {{kib}} creates and stores a service token named `kibana-managed` so applications such as Workflows can run on behalf of the account. This token isn't displayed. To authenticate requests from your own application, create an additional service token with the API.
+:::
-* The [create service account token API]({{es-apis}}operation/operation-security-create-service-token), which saves the new service token in the `.security` index and returns the bearer token in the HTTP response.
-* Self-managed and {{eck}} deployments only: The [elasticsearch-service-tokens](elasticsearch://reference/elasticsearch/command-line-tools/service-tokens-command.md) CLI tool, which saves the new service token in the `$ES_HOME/config/service_tokens` file and outputs the bearer token to your terminal
+You can create a service token using the following methods:
-We recommend that you create service tokens via the REST API rather than the CLI. The API stores service tokens within the `.security` index which means that the tokens are available for authentication on all nodes, and will be backed up within cluster snapshots. The use of the CLI is intended for cases where there is an external orchestration process (such as [{{ece}}](/deploy-manage/deploy/cloud-enterprise.md) or [{{eck}}](/deploy-manage/deploy/cloud-on-k8s.md)) that will manage the creation and distribution of the `service_tokens` file.
+* The [create service account token API]({{es-apis}}operation/operation-security-create-service-token) (recommended). The API stores the token in the `.security` index and returns the bearer token in the HTTP response. Tokens are available for authentication on all nodes and are included in cluster snapshots.
+* The [elasticsearch-service-tokens](elasticsearch://reference/elasticsearch/command-line-tools/service-tokens-command.md) CLI tool, for built-in accounts on self-managed and {{eck}} deployments. The tool stores the token in the [`$ES_HOME/config/service_tokens` file](elasticsearch://reference/elasticsearch/command-line-tools/service-tokens-command.md) and outputs the bearer token to your terminal. This method is intended for environments where an external orchestration process, such as [{{ece}}](/deploy-manage/deploy/cloud-enterprise.md) or [{{eck}}](/deploy-manage/deploy/cloud-on-k8s.md), manages and distributes the file.
+* The {{fleet}} UI in {{kib}}, for the built-in `elastic/fleet-server` account. Click **Generate service token** when [adding a {{fleet-server}}](/reference/fleet/add-fleet-server-on-prem.md#add-fleet-server-on-prem-add-server).
-Both of these methods (API and CLI) create a service token with a guaranteed secret string length of `22`. The minimal, acceptable length of a secret string for a service token is `10`. If the secret string doesn’t meet this minimal length, authentication with {{es}} will fail without even checking the value of the service token.
+Both the API and CLI generate service tokens with a 22-character secret. {{es}} requires a secret of at least 10 characters and rejects shorter secrets without checking their value.
Service tokens never expire. You must actively [delete]({{es-apis}}operation/operation-security-delete-service-token) them if they are no longer needed.
+Service tokens are different from short-lived access tokens, which expire automatically. For an overview of these credential types and API keys, refer to [Token-based authentication services](token-based-authentication-services.md).
-## Authenticate with service tokens [authenticate-with-service-account-token]
-::::{note}
-Service accounts currently do not support basic authentication.
-::::
+### Authenticate with service tokens [authenticate-with-service-account-token]
+
+To authenticate requests to {{es}}, include the service token in the `Authorization: Bearer` header of each request. Service accounts don't support basic authentication.
+
+### Verify a service token [verify-service-account-token]
+You can verify a service token, for example, by calling the [authenticate API]({{es-apis}}operation/operation-security-authenticate) (`GET /_security/_authenticate`). This API returns information about the authenticated identity, including its principal, assigned roles, and authentication details.
-To use a service account token, include the generated token value in a request with an `Authorization: Bearer` header:
+Set `ELASTICSEARCH_URL` to your deployment's HTTPS endpoint and `SERVICE_ACCOUNT_TOKEN` to your service token:
-```shell
-curl -H "Authorization: Bearer AAEAAWVsYXN0aWM...vZmxlZXQtc2VydmVyL3Rva2VuMTo3TFdaSDZ" http://localhost:9200/_security/_authenticate
+```bash
+curl --request GET "$ELASTICSEARCH_URL/_security/_authenticate" \
+ --header "Authorization: Bearer $SERVICE_ACCOUNT_TOKEN"
```
-A successful authentication response includes a `token` field, which contains a `name` field for the name of the service token and a `type` field for the type of the service token:
+The following examples show the response for each type of service account:
-```js
+::::{tab-set}
+
+:::{tab-item} Built-in service account
+
+This example uses the `elastic/fleet-server` account, which has predefined privileges:
+
+```json
{
"username": "elastic/fleet-server",
"roles": [],
"full_name": "Service account - elastic/fleet-server",
"email": null,
"token": {
- "name": "token1", <1>
- "type": "_service_account_index" <2>
+ "name": "production",
+ "type": "_service_account_index"
},
"metadata": {
"_elastic_service_account": true
@@ -101,7 +157,69 @@ A successful authentication response includes a `token` field, which contains a
}
```
-1. Name of the service account token.
-2. Type of service account token. The value always begins with `_service_account_` and is followed by a string that indicates the service token backend in use (can be either `file` or `index`).
+:::
+
+:::{tab-item} User-managed service account
+{applies_to}`stack: ga 9.6+`
+
+This example uses the `kibana/automation-client` account with the `automation_client` role:
+
+```json
+{
+ "username": "kibana/automation-client",
+ "roles": [
+ "automation_client"
+ ],
+ "full_name": "User-managed service account - kibana/automation-client",
+ "email": null,
+ "token": {
+ "name": "production",
+ "type": "_service_account_index"
+ },
+ "metadata": {
+ "_user_managed_service_account": true
+ },
+ "enabled": true,
+ "authentication_realm": {
+ "name": "_service_account",
+ "type": "_service_account"
+ },
+ "lookup_realm": {
+ "name": "_service_account",
+ "type": "_service_account"
+ },
+ "authentication_type": "token"
+}
+```
+
+:::
+
+::::
+
+In both responses:
+
+- `username` is the principal of the authenticated account.
+- `roles` lists the assigned role names. Built-in accounts return an empty array because their privileges are predefined.
+- `token` describes the credential used for the request. Its `name` is the service token's name, and its `type` identifies the storage backend: `_service_account_index` for tokens stored in the `.security` index, or `_service_account_file` for file-backed tokens used by built-in accounts.
+- `metadata` identifies the account type: `_elastic_service_account` for built-in accounts or `_user_managed_service_account` for user-managed accounts.
+
+:::{note}
+Service accounts are not included in the response of the [get users API]({{es-apis}}operation/operation-security-get-user). To retrieve a service account, use the [get service accounts API]({{es-apis}}operation/operation-security-get-service-accounts). Use the [get service account credentials API]({{es-apis}}operation/operation-security-get-service-credentials) to retrieve all service credentials for a service account.
+:::
+
+{applies_to}`stack: ga 9.6+` To authenticate calls to {{kib}} with a user-managed service account, refer to [Authenticate to the {{kib}} API with a service account](authenticate-kibana-api-with-service-account.md).
+
+## Audit user-managed service account activity [audit-service-account-activity]
+```{applies_to}
+stack: ga 9.6+
+serverless: ga
+```
+
+{{kib}} [audit events](kibana://reference/kibana-audit-events.md) record account creation and deletion, changes to workload assignments, and attempts to run a workload as an account. The `service_account_assume` event identifies the account and workload execution. Events caused by that workload identify the service account as the acting principal.
+
+In {{stack}}, {{es}} [audit events](elasticsearch://reference/elasticsearch/elasticsearch-audit-events.md) also attribute requests that use a service account credential to the account.
+On {{serverless-short}}, configure [audit trail log delivery](/deploy-manage/monitor/log-delivery/audit-trail.md) to collect audit logs from your project.
+% Follow-up in elastic/kibana: Update all five service account audit events from preview to GA for 9.6 and document their Serverless availability.
+% Serverless verification: Confirm Elasticsearch audit attribution for UIAM-backed service accounts.
diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/token-based-authentication-services.md b/deploy-manage/users-roles/cluster-or-deployment-auth/token-based-authentication-services.md
index db39f1520b1..5ac20a3d3fc 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/token-based-authentication-services.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/token-based-authentication-services.md
@@ -9,24 +9,23 @@ products:
# Token-based authentication services [token-authentication-services]
-The {{stack-security-features}} authenticate users by using realms and one or more token-based authentication services. The token-based authentication services are used for authenticating and managing tokens. You can attach these tokens to requests that are sent to {{es}} and use them as credentials. When {{es}} receives a request that must be authenticated, it consults the token-based authentication services first, and then the realm chain.
+The {{stack-security-features}} authenticate requests by using realms and one or more token-based authentication services. The token-based authentication services are used for authenticating and managing tokens. You can attach these tokens to requests that are sent to {{es}} and use them as credentials. When {{es}} receives a request that must be authenticated, it consults the token-based authentication services first, and then the realm chain.
The {{security-features}} provide the following built-in token-based authentication services, which are listed in the order they are consulted:
*service-accounts*
-: The [service accounts](service-accounts.md) use either the [create service account token API]({{es-apis}}operation/operation-security-create-service-token) or the [elasticsearch-service-tokens](elasticsearch://reference/elasticsearch/command-line-tools/service-tokens-command.md) CLI tool to generate service account tokens.
+: [Service accounts](service-accounts.md) use service tokens to authenticate as non-human identities. For details about token creation, storage, and deletion, refer to [Service account tokens](service-accounts.md#service-accounts-tokens).
-To use a service account token, include the generated token value in a request with an `Authorization: Bearer` header:
-
-```shell
-curl -H "Authorization: Bearer AAEAAWVsYXN0aWMvZ...mXQtc2VydmMTpyNXdkYmRib1FTZTl2R09Ld2FKR0F3" http://localhost:9200/_cluster/health
-```
-
-::::{important}
-Do not attempt to use service accounts for authenticating individual users. Service accounts can only be authenticated with service tokens, which are not applicable to regular users.
-::::
+ To use a service account token, include the generated token value in a request with an `Authorization: Bearer` header:
+ ```shell
+ curl -H "Authorization: Bearer AAEAAWVsYXN0aWMvZ...mXQtc2VydmMTpyNXdkYmRib1FTZTl2R09Ld2FKR0F3" \
+ "$ELASTICSEARCH_URL/_cluster/health"
+ ```
+ ::::{important}
+ Don't use service accounts to authenticate individual users. Service tokens and credentials derived from them are for software and workloads, not people.
+ ::::
$$$token-authentication-access-token$$$
diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md b/deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md
index 4ef7ea53013..34cc09d70ea 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md
@@ -53,7 +53,7 @@ If you use {{serverless-full}}, then you can only manage authentication at the [
### Advanced topics
* Learn about [internal users](/deploy-manage/users-roles/cluster-or-deployment-auth/internal-users.md), which are responsible for the operations that take place inside an {{es}} cluster.
-* Learn about [service accounts](/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md), which are used for integration with external services that connect to {{es}}.
+* Learn about [service accounts](/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md), which provide non-human identities for services and workloads.
* Learn about the [services used for token-based authentication](/deploy-manage/users-roles/cluster-or-deployment-auth/token-based-authentication-services.md).
* Learn about the [services used by orchestrators](/deploy-manage/users-roles/cluster-or-deployment-auth/operator-privileges.md).
* Manage [user profiles](/deploy-manage/users-roles/cluster-or-deployment-auth/user-profiles.md).
diff --git a/explore-analyze/toc.yml b/explore-analyze/toc.yml
index c583f988508..60868d490a8 100644
--- a/explore-analyze/toc.yml
+++ b/explore-analyze/toc.yml
@@ -704,6 +704,7 @@ toc:
- file: workflows/authoring-techniques/use-yaml-editor.md
- file: workflows/authoring-techniques/anatomy.md
- file: workflows/authoring-techniques/settings.md
+ - file: workflows/authoring-techniques/run-workflow-as-service-account.md
- file: workflows/authoring-techniques/choose-the-right-step.md
- file: workflows/authoring-techniques/pass-data-handle-errors.md
- file: workflows/authoring-techniques/compose-workflows.md
diff --git a/explore-analyze/workflows/authoring-techniques.md b/explore-analyze/workflows/authoring-techniques.md
index a224208f8f7..f6e64a58284 100644
--- a/explore-analyze/workflows/authoring-techniques.md
+++ b/explore-analyze/workflows/authoring-techniques.md
@@ -21,6 +21,7 @@ Techniques that apply across workflow types, regardless of which outcome you're
- [Use the YAML editor](/explore-analyze/workflows/authoring-techniques/use-yaml-editor.md): Author and run workflows in the YAML editor in {{kib}}.
- [Anatomy of a workflow](/explore-analyze/workflows/authoring-techniques/anatomy.md): Every top-level field in a workflow definition and the execution lifecycle.
- [Workflow settings](/explore-analyze/workflows/authoring-techniques/settings.md): Workflow-wide settings reference, including timeout, timezone, concurrency, max step size, and global on-failure.
+- {applies_to}`stack: ga 9.6+` [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md): Give every run a stable, least-privilege identity.
- [Choose the right step](/explore-analyze/workflows/authoring-techniques/choose-the-right-step.md): Decision aid for picking the right step type. Keyed by intent.
- [Pass data and handle errors](/explore-analyze/workflows/authoring-techniques/pass-data-handle-errors.md): Move data between steps, use dynamic templating, and make workflows resilient with `on-failure`.
- [Compose workflows from reusable parts](/explore-analyze/workflows/authoring-techniques/compose-workflows.md): Decompose long workflows into reusable child workflows, design the input and output contract, and fan out with asynchronous composition.
diff --git a/explore-analyze/workflows/authoring-techniques/anatomy.md b/explore-analyze/workflows/authoring-techniques/anatomy.md
index 9a669f35fd4..8908864c76a 100644
--- a/explore-analyze/workflows/authoring-techniques/anatomy.md
+++ b/explore-analyze/workflows/authoring-techniques/anatomy.md
@@ -15,7 +15,7 @@ products:
# Anatomy of a workflow [workflows-anatomy]
-A workflow definition has eleven top-level fields. Most of them are optional. This page is the reference for all of them.
+A workflow definition combines identity, triggers, settings, and steps in top-level fields. Most fields are optional. This page is the reference for all fields.
## The complete workflow shape [workflows-anatomy-shape]
@@ -115,7 +115,7 @@ steps: # what it does
| [`inputs`](#workflows-anatomy-inputs) | object or `Input[]` | No | Runtime parameters the workflow accepts. Values provided at invocation time become `{{ inputs. }}` inside the workflow. On 9.5+, defined under the `manual` trigger. |
| [`consts`](#workflows-anatomy-consts) | object | No | Constant values reusable as `{{ consts. }}`. Use for thresholds, index names, or other values you want to name. |
| [`outputs`](#workflows-anatomy-outputs) | object or `Output[]` | No | Declared output schema. Required for workflows invoked through [composition](/explore-analyze/workflows/steps/composition.md) — the parent needs to know the child's output shape. |
-| [`settings`](#workflows-anatomy-settings) | object | No | Global behavior: timeout, timezone, concurrency, global error handling, output-size cap. Refer to [Workflow settings](/explore-analyze/workflows/authoring-techniques/settings.md). |
+| [`settings`](#workflows-anatomy-settings) | object | No | Global behavior: execution identity, timeout, timezone, concurrency, global error handling, and output-size cap. Refer to [Workflow settings](/explore-analyze/workflows/authoring-techniques/settings.md). |
| [`steps`](#workflows-anatomy-steps) | `Step[]` | Yes | Ordered list of steps to execute. Refer to [Steps](/explore-analyze/workflows/steps.md). |
## `name` — workflow identity [workflows-anatomy-name]
@@ -274,10 +274,11 @@ A workflow that doesn't declare outputs can still complete successfully. `output
## `settings` — global behavior [workflows-anatomy-settings]
-`settings` is the grab bag for workflow-wide behavior: timeout, timezone, concurrency, and global error handling.
+`settings` controls workflow-wide behavior, such as execution identity, timeout, timezone, concurrency, and global error handling.
```yaml
settings:
+ run_as: "" <1>
timeout: "10m"
timezone: "America/Los_Angeles"
max-step-size: "10mb"
@@ -290,8 +291,9 @@ settings:
max-attempts: 2
delay: "10s"
```
+1. {applies_to}`stack: ga 9.6+` Runs every execution with the specified user-managed service account. Replace `` with the account's ID. Refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
-Every field in `settings` is optional. The full reference with per-field semantics lives on the [Workflow settings page](/explore-analyze/workflows/authoring-techniques/settings.md).
+Every field in `settings` is optional. The full reference with per-field semantics is available in [](/explore-analyze/workflows/authoring-techniques/settings.md).
## `steps` — the body of the workflow [workflows-anatomy-steps]
@@ -336,6 +338,7 @@ Five states are terminal: `completed`, `failed`, `cancelled`, `timed_out`, and `
## Related [workflows-anatomy-related]
- [Workflow settings](/explore-analyze/workflows/authoring-techniques/settings.md): The full `settings` reference.
+- {applies_to}`stack: ga 9.6+` [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md): Assign a stable, least-privilege execution identity.
- [Choose the right step](/explore-analyze/workflows/authoring-techniques/choose-the-right-step.md): Decision aid for picking step types.
- [Steps overview](/explore-analyze/workflows/steps.md): The step catalog.
- [Triggers overview](/explore-analyze/workflows/triggers.md): The trigger catalog.
diff --git a/explore-analyze/workflows/authoring-techniques/manage-workflows.md b/explore-analyze/workflows/authoring-techniques/manage-workflows.md
index 123a9384a45..1affc298eb5 100644
--- a/explore-analyze/workflows/authoring-techniques/manage-workflows.md
+++ b/explore-analyze/workflows/authoring-techniques/manage-workflows.md
@@ -20,6 +20,8 @@ The **Workflows** page allows you to view and manage all your workflows. From th
::::{admonition} Requirements
To use workflows, you must turn on the feature and ensure your role has the appropriate privileges. Refer to [](/explore-analyze/workflows/get-started/setup.md) for more information.
+{applies_to}`stack: ga 9.6+` Updating or deleting a workflow [assigned to a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md) also requires the `manage_security` cluster privilege.
+
You must also have the appropriate subscription. Refer to the subscription page for [Elastic Cloud](https://www.elastic.co/subscriptions/cloud) and [Elastic Stack/self-managed](https://www.elastic.co/subscriptions) for the breakdown of available features and their associated subscription tiers.
::::
diff --git a/explore-analyze/workflows/authoring-techniques/monitor-workflows.md b/explore-analyze/workflows/authoring-techniques/monitor-workflows.md
index af831bc4c57..67ef08ed1ac 100644
--- a/explore-analyze/workflows/authoring-techniques/monitor-workflows.md
+++ b/explore-analyze/workflows/authoring-techniques/monitor-workflows.md
@@ -57,6 +57,8 @@ serverless: ga
Every execution begins with a trigger entry that shows how the run started, such as a manual run, a schedule, an alert, or an event. Expand this entry to see the input the workflow received, including the full event payload for [event-driven](/explore-analyze/workflows/triggers/event-driven-triggers.md) runs. This lets you trace an execution back to the event or action that started it, which is especially useful when workflows react to one another through event-driven triggers.
+{applies_to}`stack: ga 9.6+` For workflows assigned to a service account, **Triggered by** shows the identity associated with the start of the run, which can be a user or a service account. **Run as** shows the assigned service account used for authorization. For details, refer to [](/explore-analyze/workflows/authorization.md#workflows-authorization-audit).
+
## View execution history [workflows-execution-history]
To review past runs, select the **Executions** tab, then select each run to see detailed logs. Workflow runs can have the following statuses:
diff --git a/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md b/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
new file mode 100644
index 00000000000..2da433c417f
--- /dev/null
+++ b/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
@@ -0,0 +1,83 @@
+---
+navigation_title: Run as a service account
+applies_to:
+ stack: ga 9.6+
+ serverless: ga
+description: Assign a user-managed service account to a workflow, verify its execution identity, and troubleshoot permission errors.
+products:
+ - id: kibana
+ - id: cloud-serverless
+ - id: cloud-hosted
+ - id: cloud-enterprise
+ - id: cloud-kubernetes
+ - id: elastic-stack
+---
+
+# Run a workflow as a service account [run-workflow-as-service-account]
+
+By default, workflows run with a user's privileges. As an alternative, you can run a workflow as a [user-managed service account](/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md#user-managed-service-accounts).
+
+The workflow then uses the account's privileges for every run, regardless of who starts or last edits it. This gives shared workflows a stable identity, even if their creator leaves your organization. You can also give the account only the privileges the workflow needs, even if the people who manage it have broader access.
+
+This guide shows you how to assign a service account to a workflow and verify its execution identity.
+
+## Before you begin [run-workflow-as-service-account-prerequisites]
+
+Before you assign a service account to a workflow, make sure you meet these requirements:
+
+- You need the **Update** [Workflows privilege](/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md#kibana-privileges-workflows-subfeatures) to assign an account. To run the workflow and review its execution, you also need **Execute** and **Read Workflow Execution**.
+- You need the `manage_security` cluster privilege to add, change, or remove the workflow's service account assignment. Editing or deleting a workflow assigned to a service account also requires this privilege, in addition to the corresponding Workflows privilege.
+
+## Assign a service account [assign-workflow-service-account]
+
+The `settings.run_as` field specifies the ID of the account that runs the workflow. On {{stack}} deployments, this is the account's principal, such as `kibana/incident-response`. On {{serverless-short}}, it is a generated identifier independent of the account's name.
+
+You can assign an existing account or create one without leaving the workflow editor. In both cases, the account must be [created in {{kib}}](/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md) and have the privileges required by the workflow steps.
+
+1. Open the workflow in the {{kib}} workflow editor.
+2. In the `settings` block, add `run_as`:
+
+ - To use an existing account, select it from the picker or enter its ID.
+ - To create and assign an account, select **Create account** and configure its roles.
+
+ For example:
+
+ ```yaml
+ settings:
+ run_as: ""
+ ```
+
+ Replace `` with the account's ID.
+
+3. Save the workflow.
+
+The saved assignment applies to manual, scheduled, alert, and event-driven runs. Users who have permission to run the workflow don't need `manage_security` to start it.
+
+## Verify the execution identity [verify-workflow-execution-identity]
+
+[Test the complete workflow](/explore-analyze/workflows/authoring-techniques/use-yaml-editor.md#workflows-supply-test-input). The test uses the saved definition and the service account's privileges. You can't test individual steps or unsaved definitions when `run_as` is set.
+
+After the test completes, open its execution details. The overview identifies both identities:
+
+- **Triggered by** shows the identity associated with the start of the run, which can be a user or a service account.
+- **Run as** shows the assigned service account whose privileges authorize the workflow's actions.
+
+Steps that call {{es}} or {{kib}} (`elasticsearch.*` and `kibana.*`) use the service account's privileges. {{connectors-ui}} use their own stored credentials to authenticate to external systems. For details about credentials and child workflows, refer to [Workflow authorization](/explore-analyze/workflows/authorization.md).
+
+% TBD: Confirm agent credential propagation with Workflows and Agent Builder after https://github.com/elastic/kibana/issues/293019 is resolved before adding a claim about agents invoked by a workflow assigned to a service account.
+
+## Handle permission and identity failures [handle-workflow-service-account-failures]
+
+A workflow assigned to a service account never falls back to the triggering user's privileges. If a run fails, check the account and its roles:
+
+- If the account is deactivated or deleted, the next run fails.
+- If the account lacks a privilege required by a step, that step fails with a privileges error.
+- If the account was deleted and recreated with the same name, the old assignment no longer matches it. Remove the assignment, save the workflow, then assign the recreated account.
+
+[Update the account or its roles](/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md#update-service-account-kibana), or assign a different account, then run the workflow again.
+
+## Remove the assignment [remove-workflow-service-account]
+
+To remove the service account assignment from a workflow, remove `run_as` from the workflow's `settings` block and save the workflow. Future runs return to the default [workflow authorization model](/explore-analyze/workflows/authorization.md), in which the trigger type determines whose privileges are used.
+
+Changing or removing the assignment doesn't switch the identity of a run already in progress. That run fails if it needs to renew its credential or resumes after a pause.
diff --git a/explore-analyze/workflows/authoring-techniques/settings.md b/explore-analyze/workflows/authoring-techniques/settings.md
index f3b8ea40800..cf9c84daf29 100644
--- a/explore-analyze/workflows/authoring-techniques/settings.md
+++ b/explore-analyze/workflows/authoring-techniques/settings.md
@@ -3,7 +3,7 @@ navigation_title: Workflow settings
applies_to:
stack: ga 9.4+
serverless: ga
-description: Reference for workflow-wide settings. Timeout, timezone, concurrency, max step size, and global on-failure.
+description: Reference for workflow-wide settings, including execution identity, timeout, timezone, concurrency, output size, and failure handling.
products:
- id: kibana
- id: cloud-serverless
@@ -26,6 +26,7 @@ The top-level `settings` block configures workflow-wide behavior. Every field is
| `concurrency` | object | Controls what happens when a new execution would exceed the concurrency limit for its group. Refer to [Concurrency control](#workflows-settings-concurrency). |
| `max-step-size` | byte size | Cap on per-step output size (for example `10mb`). |
| `on-failure` | object | Global failure handling applied to every step. Same shape as per-step `on-failure`. Refer to [Pass data and handle errors](/explore-analyze/workflows/authoring-techniques/pass-data-handle-errors.md). |
+| `run_as` {applies_to}`stack: ga 9.6+` | string | User-managed service account ID that authorizes every workflow run. Refer to [](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md). |
Fields not set take the engine defaults.
@@ -38,6 +39,7 @@ Fields not set take the engine defaults.
| Prevent overlapping runs from colliding on shared state | `concurrency` |
| Keep a single step from producing 100 MB of output that bogs down the UI | `max-step-size` |
| Apply a default retry policy to every step | `on-failure` |
+| Run with a stable, least-privilege identity {applies_to}`stack: ga 9.6+` | `run_as` |
## `timeout` [workflows-settings-timeout]
@@ -79,6 +81,22 @@ settings:
Steps that produce outputs exceeding this limit fail with a clear error. Useful to catch runaway {{es}} queries before they push the whole execution past the deployment limit.
+## `run_as` [workflows-settings-run-as]
+```{applies_to}
+stack: ga 9.6+
+```
+
+Assigns a user-managed service account to the workflow. Every trigger type runs the workflow with the account's privileges:
+
+```yaml
+settings:
+ run_as: ""
+```
+
+Replace `` with the ID of the service account you want to assign.
+
+Setting, changing, or removing `run_as` requires the `manage_security` cluster privilege. Refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md) for setup instructions, permissions, and testing restrictions.
+
## Concurrency control [workflows-settings-concurrency]
Use `settings.concurrency` to prevent overlapping executions from colliding. This is important for:
diff --git a/explore-analyze/workflows/authorization.md b/explore-analyze/workflows/authorization.md
index 42a9c917244..3b3c2750e4d 100644
--- a/explore-analyze/workflows/authorization.md
+++ b/explore-analyze/workflows/authorization.md
@@ -15,11 +15,16 @@ products:
# Workflow authorization [workflows-authorization]
-Every workflow run is authorized by a specific user's privileges. Use this page to configure who runs your workflows, diagnose privileges errors, and keep your workflows' access current.
+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.
+* {applies_to}`stack: ga 9.6+` **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.
## Whose privileges authorize a run [workflows-authorization-user]
-The trigger type determines which user's privileges authorize a run.
+When a workflow doesn't run as a service account, the trigger type determines which user's privileges authorize a run.
| Trigger type | Whose privileges are used |
|---|---|
@@ -29,23 +34,44 @@ The trigger type determines which user's privileges authorize a run.
| Event-based | The user whose action produced the event. For example, a `cases.commentsAdded` event uses the privileges of the user who added the comment. |
| `workflows.failed` (error handler trigger) | The same privileges the failed workflow ran with. |
+### Workflows that run as a service account [workflows-authorization-service-account]
+```{applies_to}
+stack: ga 9.6+
+```
+
+When you [assign a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md) 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, {{kib}} 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-short}}, the account's privileges are also limited by its creator's access when the account was created. Refer to [Roles and privileges in {{serverless-short}}](/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md#service-account-serverless-roles).
+
+If the account is deleted or lacks a required privilege, the run fails without falling back to a user.
+
## How {{kib}} records execution identity [workflows-authorization-audit]
-When a workflow run starts, {{kib}} records the execution identity so you can audit which privileges a run used. For a composed workflow ([`workflow.execute`](/explore-analyze/workflows/steps/composition.md#workflow-execute)), the child execution runs with the same execution identity as the parent, though the **Executions** tab doesn't visually indicate this inheritance. Refer to [](/explore-analyze/workflows/reference/context-variables.md#workflows-ctx-execution) for more information about execution context variables.
+When a workflow run starts, {{kib}} records the execution identity so you can audit which privileges it used. Refer to [](/explore-analyze/workflows/reference/context-variables.md#workflows-ctx-execution) for execution context variables.
+
+{applies_to}`stack: ga 9.6+` 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.
-:::{note}
The **Created By** filter on the **Workflows** page reflects who last saved the workflow, not necessarily who originally created it.
-:::
-## How steps use the API key [workflows-authorization-scope]
+### Execution identity in child workflows [workflows-authorization-child-identity]
+
+A workflow can call a child workflow with [`workflow.execute`](/explore-analyze/workflows/steps/composition.md#workflow-execute). When neither workflow is assigned a service account, the child runs with the same execution identity as the parent.
+
+{applies_to}`stack: ga 9.6+` 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](#workflows-authorization-user). 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.
+
+## How steps use the execution identity [workflows-authorization-scope]
+
+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.
-All `kibana.*` and `elasticsearch.*` steps in a workflow share a single API key. There's no separate credential per step type. The key's privileges determine what each step can do. A step fails with a privileges error if the executing user lacks the required privilege for that step. For example, a `createCase` step fails if the user 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](#workflows-authorization-user). For a workflow assigned to a service account, refer to [Workflows assigned a service account](#workflows-authorization-service-account).
-_Connector steps are an exception._ The connector authenticates to the third-party system using its own stored credentials, not the workflow's API key. However, {{kib}} still records the connector step as having executed under the workflow's API key for auditability. Refer to [Connector-based actions](/explore-analyze/workflows/steps/external-systems-apps.md#connector-based-actions) for details.
+_Connector steps are an exception._ The connector authenticates to the third-party system using its own stored credentials, not the workflow's credential. However, {{kib}} still records the connector step as having executed under the workflow's execution identity for auditability. Refer to [Connector-based actions](/explore-analyze/workflows/steps/external-systems-apps.md#connector-based-actions) for details.
-## How to keep a workflow's privileges current [workflows-authorization-updates]
+## How to keep a user's privileges current [workflows-authorization-updates]
-The following actions refresh the stored API key for future runs:
+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.
@@ -56,11 +82,12 @@ Deactivating a user or changing their role doesn't automatically update the stor
## Check and fix errors [workflows-authorization-troubleshoot]
-Two types of authorization errors can cause a workflow step to fail:
+The following authorization errors can cause a workflow step to fail:
| Error type | Cause | Where it appears | How to resolve it |
|---|---|---|---|
-| Step-level privileges error | The executing user lacks a required privilege for the step. | On the failing step in the run's **Executions** tab. | Save the workflow as a user who has the required privilege, or update the user's role and save again. |
+| Step-level privileges error | The execution identity lacks a required privilege for the step. | On the failing step in the run's **Executions** tab. | For a user identity, update the user's role and save the workflow again. For a service account, update one of its assigned roles. |
| Stale or not-valid API key | The stored key is no longer valid, for example because an administrator deleted a role it depended on. There's no dedicated status or list-level indicator for this condition. | As an API key error on the individual `elasticsearch` or `kibana` step in the run's **Executions** tab. | Refresh the API key by saving the workflow again or toggling **Enabled** off and back on. |
+| Service account identity error {applies_to}`stack: ga 9.6+` | The assigned account is deleted, deactivated, or no longer matches the saved assignment. | In the run's execution details. | Assign an available account or, on {{stack}} deployments, [reactivate the account](/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md#disable-service-account). Then start a new run. |
diff --git a/explore-analyze/workflows/concepts.md b/explore-analyze/workflows/concepts.md
index 016d09ed486..e01f4b725f4 100644
--- a/explore-analyze/workflows/concepts.md
+++ b/explore-analyze/workflows/concepts.md
@@ -18,7 +18,7 @@ products:
Concept and reference material for Elastic Workflows, including the components that make up a workflow definition. Use this section when you need to know what a specific trigger or step accepts, what its output looks like, or how templating expressions are evaluated.
- [Managed workflows](/explore-analyze/workflows/managed-workflows.md): Elastic-shipped workflows that install automatically and power product features.
-- [Authorization](/explore-analyze/workflows/authorization.md): Whose privileges authorize a workflow run and what the run's API key can access.
+- [Authorization](/explore-analyze/workflows/authorization.md): How a user or service account's privileges authorize a workflow run and determine what it can access.
- [Triggers](/explore-analyze/workflows/triggers.md): Manual, scheduled, alert, and event-driven triggers.
- [Steps](/explore-analyze/workflows/steps.md): Action, flow control, AI, data, and composition steps.
- [Templating engine](/explore-analyze/workflows/templating.md): Liquid templating syntax and custom filters.
diff --git a/explore-analyze/workflows/get-started/setup.md b/explore-analyze/workflows/get-started/setup.md
index d0f6188be1b..95f5aa211c8 100644
--- a/explore-analyze/workflows/get-started/setup.md
+++ b/explore-analyze/workflows/get-started/setup.md
@@ -51,6 +51,8 @@ Access to workflows is controlled by [{{kib}} privileges](/deploy-manage/users-r
| Access the **Workflows** page | `All` or `Read` for **Analytics → Workflows** |
| Fully manage workflows | `All` for **Analytics → Workflows** |
| Grant access to specific workflow actions | [Set sub-feature privileges](/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md#kibana-privileges-workflows-subfeatures) for **Analytics → Workflows** |
+| Add, change, or remove a [service account assignment](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md#assign-workflow-service-account) {applies_to}`stack: ga 9.6+` | The **Update** Workflows privilege and the `manage_security` cluster privilege |
+| Edit or delete a workflow assigned to a service account {applies_to}`stack: ga 9.6+` | The corresponding Workflows privilege and the `manage_security` cluster privilege |
## Show managed workflows [workflows-managed-visibility]
diff --git a/explore-analyze/workflows/reference/context-variables.md b/explore-analyze/workflows/reference/context-variables.md
index 1586ab4cdc8..f8d03a02108 100644
--- a/explore-analyze/workflows/reference/context-variables.md
+++ b/explore-analyze/workflows/reference/context-variables.md
@@ -124,12 +124,18 @@ Metadata about the current workflow execution.
| `execution.id` | Execution ID. |
| `execution.startedAt` | ISO timestamp of start. |
| `execution.isTestRun` | `true` if run from the editor's **Test** button. |
-| `execution.executedBy` | UID of the user or system that invoked the workflow. |
+| `execution.executedBy` | Identifier of the user or service account associated with the run. |
+| `execution.effectiveIdentity.type` {applies_to}`stack: ga 9.6+` | Identity type. Set to `service_account` when the workflow runs as a user-managed service account. |
+| `execution.effectiveIdentity.id` {applies_to}`stack: ga 9.6+` | ID of the user-managed service account that authorizes the workflow. |
| `execution.triggeredBy` | Which trigger initiated this execution, such as `manual` or `scheduled`. For more values, refer to [the list after this table](#workflows-ctx-execution-triggeredby). |
| `execution.url` | Deep link to the execution view in {{kib}}. |
| `execution.compositionDepth` | 0 for a top-level invocation. Increments by 1 for each [`workflow.execute`](/explore-analyze/workflows/steps/composition.md#workflow-execute) level. |
| `execution.parentWorkflowId` | ID of the parent workflow, if this is a composed child execution. |
+:::{note}
+In {{kib}} execution details, the **Triggered by** field displays `execution.executedBy`. The `execution.triggeredBy` variable identifies the trigger type.
+:::
+
$$$workflows-ctx-execution-triggeredby$$$
`execution.triggeredBy` values include:
diff --git a/explore-analyze/workflows/steps/elasticsearch.md b/explore-analyze/workflows/steps/elasticsearch.md
index 588662f0aa8..e0db03f264b 100644
--- a/explore-analyze/workflows/steps/elasticsearch.md
+++ b/explore-analyze/workflows/steps/elasticsearch.md
@@ -18,7 +18,7 @@ products:
{{es}} actions are built-in steps that allow your workflows to interact directly with {{es}} APIs. You can search, index, update, and delete documents, manage indices, and perform any other operation supported by the {{es}} REST API.
-All {{es}} actions are automatically authenticated using the permissions or API key of the user executing the workflow.
+All {{es}} actions are automatically authenticated as the workflow's execution identity. Refer to [Workflow authorization](/explore-analyze/workflows/authorization.md) to understand which privileges each run uses.
There are two ways to use {{es}} actions:
diff --git a/explore-analyze/workflows/steps/kibana.md b/explore-analyze/workflows/steps/kibana.md
index e1eca51c19c..5663ba356ec 100644
--- a/explore-analyze/workflows/steps/kibana.md
+++ b/explore-analyze/workflows/steps/kibana.md
@@ -19,7 +19,7 @@ products:
For Cases operations, always use the dedicated [Cases action steps](/explore-analyze/workflows/steps/cases.md). For Observability Streams, use the [Streams action steps](/explore-analyze/workflows/steps/streams.md). Everything else lives here.
-All {{kib}} actions are automatically authenticated using the permissions or API key of the user executing the workflow.
+All {{kib}} actions are automatically authenticated as the workflow's execution identity. Refer to [](/explore-analyze/workflows/authorization.md) to understand which privileges each run uses.
:::{important}
The detection alert step type IDs use **PascalCase**, not lowercase or snake_case: `kibana.SetAlertsStatus`, `kibana.SetAlertTags`. The editor rejects lowercase variants. This is the most common authoring surprise on the {{kib}} namespace.
diff --git a/explore-analyze/workflows/triggers.md b/explore-analyze/workflows/triggers.md
index beec0521683..6ed3daed235 100644
--- a/explore-analyze/workflows/triggers.md
+++ b/explore-analyze/workflows/triggers.md
@@ -20,6 +20,8 @@ A trigger is an event or condition that initiates a workflow. Without a trigger,
Triggers also provide initial context to the workflow. For example, a workflow triggered by an alert carries the alert's metadata, entities, and source events. This context shapes how the workflow executes.
+To understand whose privileges authorize a triggered run, refer to [Workflow authorization](/explore-analyze/workflows/authorization.md).
+
## Trigger types
The following types of triggers are available:
@@ -152,4 +154,4 @@ steps:
with:
message: "Workflow started at {{ execution.startedAt }}"
details: "Event data: {{ event | json:2 }}"
-```
\ No newline at end of file
+```
diff --git a/explore-analyze/workflows/triggers/alert-triggers.md b/explore-analyze/workflows/triggers/alert-triggers.md
index 0d5e82bf467..01573c848b8 100644
--- a/explore-analyze/workflows/triggers/alert-triggers.md
+++ b/explore-analyze/workflows/triggers/alert-triggers.md
@@ -16,8 +16,6 @@ products:
Alert triggers run workflows automatically when detection or alerting rules generate an alert. Use alert triggers for alert enrichment, automated incident response, case creation, or notification routing.
-Alert-triggered workflows run with the privileges of the user who last saved the rule. For details, refer to [Workflow authorization](/explore-analyze/workflows/authorization.md).
-
When a rule generates an alert that triggers your workflow, the trigger provides rich context data to the workflow through the `event` field.
Alert triggers are different from [alert lifecycle triggers](/explore-analyze/workflows/triggers/event-driven-triggers.md#alert-episode-lifecycle-triggers-event-driven). An alert trigger (`type: alert`) runs a workflow when a detection rule or a {{alerting-v1-system}} rule generates an alert, and only when you add the workflow to that rule as an action. Alert lifecycle triggers are [event-driven triggers](/explore-analyze/workflows/triggers/event-driven-triggers.md) that run automatically when a user acts on an alert in {{alerting-v2-system}}, such as assigning or acknowledging it, with no rule action to configure.
@@ -26,6 +24,15 @@ Alert triggers are different from [alert lifecycle triggers](/explore-analyze/wo
Declaring `type: alert` on a workflow isn't enough to run the workflow when alerts fire. You also have to attach the workflow to the rule's **Actions** using a **Run Workflow** action. Without the attachment, the rule fires alerts but the workflow is never invoked. This is the single most common setup mistake.
:::
+## Authorization
+
+The privileges used for each alert-triggered run depend on whether the workflow has an assigned service account:
+
+* **No service account assigned (default):** The run uses the privileges of the user who last saved the rule.
+* {applies_to}`stack: ga 9.6+` **Service account assigned:** The run uses the privileges of that account.
+
+For details, refer to [](/explore-analyze/workflows/authorization.md).
+
## Schema [workflows-alert-trigger-schema]
| Parameter | Type | Required | Description |
diff --git a/explore-analyze/workflows/triggers/event-driven-triggers.md b/explore-analyze/workflows/triggers/event-driven-triggers.md
index 49190db2e67..3960095f572 100644
--- a/explore-analyze/workflows/triggers/event-driven-triggers.md
+++ b/explore-analyze/workflows/triggers/event-driven-triggers.md
@@ -24,9 +24,14 @@ Event-driven triggers let workflows react to events elsewhere in {{kib}}. The fo
- {applies_to}`serverless: preview` {applies_to}`stack: preview 9.6+` **Rule lifecycle triggers in {{alerting-v2-system}}**: Fire when someone creates, updates, deletes, enables, or disables a rule.
- {applies_to}`serverless: preview` {applies_to}`stack: preview 9.6+` **{{agent-builder}} triggers**: Fire when a conversation attachment is added, updated, or deleted, or when conversation metadata changes. `ai.conversation.updated` also fires for other conversation changes, but only for conversation templates that have it turned on.
+## Authorization
-:::{include} ../_snippets/schema-location-legend.md
-:::
+The privileges used for each event-driven run depend on whether the workflow has an assigned service account:
+
+* **No service account assigned (default):** The run uses the privileges of the user whose action produced the event. For `workflows.failed`, it uses the same privileges as the failed workflow.
+* {applies_to}`stack: ga 9.6+` **Service account assigned:** The run uses the privileges of that account.
+
+For details, refer to [](/explore-analyze/workflows/authorization.md).
## `workflows.failed`
@@ -34,6 +39,9 @@ Fires when any workflow execution reaches the `failed` terminal state. Use this
### Schema
+:::{include} ../_snippets/schema-location-legend.md
+:::
+
| Parameter | Location | Type | Required | Description |
|---|---|---|---|---|
| `type` | top level | string | Yes | Must be `workflows.failed`. |
diff --git a/explore-analyze/workflows/triggers/manual-triggers.md b/explore-analyze/workflows/triggers/manual-triggers.md
index 9da3562c215..0eddccb59f5 100644
--- a/explore-analyze/workflows/triggers/manual-triggers.md
+++ b/explore-analyze/workflows/triggers/manual-triggers.md
@@ -16,8 +16,6 @@ products:
Manual triggers run workflows on-demand through the UI or API. They require explicit user action to start a workflow. Use manual triggers for testing, one-off tasks, administrative actions, or workflows that require a human decision to start.
-Manual runs use the privileges of the user who starts the run. For details, refer to [Workflow authorization](/explore-analyze/workflows/authorization.md).
-
To define a manual trigger, use the following syntax:
```yaml
@@ -30,6 +28,15 @@ This allows you to run a workflow manually by:
* Clicking **Run** in the Workflows UI
* Calling the workflow execution API, either directly or from an external system
+## Authorization
+
+The privileges used for each manual run depend on whether the workflow has an assigned service account:
+
+* **No service account assigned (default):** The run uses the privileges of the user who starts it.
+* {applies_to}`stack: ga 9.6+` **Service account assigned:** The run uses the privileges of that account.
+
+For details, refer to [](/explore-analyze/workflows/authorization.md).
+
## Input parameters
Manual triggers can accept input parameters, which you can reference in any step. When you define inputs at the workflow level, users are prompted to provide values when they run the workflow.
diff --git a/explore-analyze/workflows/triggers/scheduled-triggers.md b/explore-analyze/workflows/triggers/scheduled-triggers.md
index b57d15e1e91..b67c8a571fe 100644
--- a/explore-analyze/workflows/triggers/scheduled-triggers.md
+++ b/explore-analyze/workflows/triggers/scheduled-triggers.md
@@ -16,13 +16,20 @@ products:
Scheduled triggers run workflows automatically at specific times or intervals, without requiring manual intervention. Use scheduled triggers for recurring tasks like reports, data cleanup, or periodic health checks.
-Scheduled workflows run with the privileges of the user who last saved the workflow. For details, refer to [Workflow authorization](/explore-analyze/workflows/authorization.md).
-
You can configure scheduled triggers using:
* **Interval-based scheduling**: Run on a recurring interval (every _x_ minutes, hours, or days)
* **Recurrence rule (RRule) expressions**: Run at specific times in the specified timezone (for example, daily at 2 AM EST)
+## Authorization
+
+The privileges used for each scheduled run depend on whether the workflow has an assigned service account:
+
+* **No service account assigned (default):** The run uses the privileges of the user who last saved the workflow.
+* {applies_to}`stack: ga 9.6+` **Service account assigned:** The run uses the privileges of that account.
+
+For details, refer to [](/explore-analyze/workflows/authorization.md).
+
## Interval-based scheduling
Interval-based scheduling runs a workflow repeatedly at a fixed interval.