Repository navigation
Conversation
AI-Assisted: OpenAI Codex
Elastic Docs AI PR menuCheck the box to run an AI review for this pull request.
Powered by GitHub Agentic Workflows and docs-actions. For more information, reach out to the docs team. |
Elastic Docs Style Checker (Vale)Summary: 1 warning, 1 suggestion found
|
| File | Line | Rule | Message |
|---|---|---|---|
| explore-analyze/workflows/authorization.md | 70 | Elastic.Spelling | 'auditability' is a possible misspelling. |
💡 Suggestions (1): Optional style improvements. Apply when helpful.
| File | Line | Rule | Message |
|---|---|---|---|
| explore-analyze/workflows/steps/kibana.md | 22 | Elastic.Repetition | "to" is repeated. |
The Vale linter checks documentation changes against the Elastic Docs style guide. To use Vale locally or report issues, refer to Elastic style guide for Vale.
AI-Assisted: OpenAI Codex
AI-Assisted: OpenAI Codex
AI-Assisted: OpenAI Codex
AI-Assisted: OpenAI Codex
AI-Assisted: OpenAI Codex
AI-Assisted: OpenAI Codex
| **Q: How can I create {{serverless-full}} service accounts?**<br> | ||
| A: User-managed service accounts aren't available on {{serverless-short}}. To authenticate applications and automated processes, create a project API key. You can create project API keys in {{kib}}, with the {{es}} API, or as code with Terraform. Refer to [](/deploy-manage/api-keys/serverless-project-api-keys.md) for details. |
There was a problem hiding this comment.
is this true? i don't get it. on one hand in the faq right now we say you can create service accounts, now we change it to you can't although service accounts will be available in serverless?
There was a problem hiding this comment.
As soon as service accounts are available in serverless we will change this and we will point to the new docs about SAs. But this PR still considers the stack:9.6 introduction of SAs, not serverless.
The change highlights what IMO is a bug in the original question. Now that user-managed service account really exist at stack level we should improve the response IMO.
|
|
||
| :::{note} | ||
| :applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"} | ||
| For a workflow bound to a service account, **Triggered by** identifies the user who starts the workflow or last saved it, depending on the trigger. **Run as** identifies the service account used for authorization. Refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md). |
There was a problem hiding this comment.
also not sure about this but @shahargl probably knows best - i think triggered by will have the SA shown in triggered by..
There was a problem hiding this comment.
I've updated it after further reviewing of the code. I think you are right, in certain cases (depending on the type of trigger and the identity used to initiate the run), the triggered by could identify a SA (it doesn't need to be the same SA shown in run_as).
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.
But of course if @shahargl is able to confirm it, that would be great.
shainaraskas
left a comment
shainaraskas
left a comment
There was a problem hiding this comment.
did a quick review of the core service account docs. will keep going tomorrow
shainaraskas
left a comment
shainaraskas
left a comment
There was a problem hiding this comment.
last major page. more tomorrow 🐌
Co-authored-by: Cursor <cursoragent@cursor.com>
MERGE TOGETHER WITH 9.6 RELEASE ## Summary Documents `xpack.security.serviceAccounts.enabled` in the generated Kibana security settings reference. The entry covers its default behavior and availability for Stack 9.6, ECE, ECK, self-managed deployments, Elastic Cloud Hosted, and Serverless. Elastic Cloud Hosted is marked unavailable because the setting is not present in the `elastic/cloud` Kibana user-settings allowlist. Relates to elastic/docs-content#8921 Closes elastic/docs-content-internal#1733 ## Validation - `vale --output=line docs/reference/configuration-reference/security-settings.yml` - YAML parsing - `git diff --check` ## Release note N/A: documentation-only change. --------- Co-authored-by: Cursor <cursoragent@cursor.com> Co-authored-by: Larry Gregory <larry.gregory@elastic.co>
AI-Assisted: Codex
Tier-2 update and remaining technical checksThis PR now includes the Serverless (Tier-2) changes alongside Elastic Stack 9.6. The shared procedures stay common; Elasticsearch service-token management and direct API access remain Stack-only. This update supersedes the Tier-1-only scope described in the current PR summary. Publication still needs to align with the 9.6 release and Serverless enablement. The remaining technical checks (cc: @legrego ) are:
|
AI-Assisted: Codex
AI-Assisted: Codex
AI-Assisted: Codex
AI-Assisted: Codex
AI-Assisted: Codex
| **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?**<br> | ||
| 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.md). |
There was a problem hiding this comment.
@talboren : I've updated the PR to show serverless availability.
It would be great to get a final review if possible.
AI-Assisted: Codex
Preserve service account execution identities and the expanded trigger documentation from main. AI-Assisted: Codex
shainaraskas
left a comment
shainaraskas
left a comment
There was a problem hiding this comment.
still wip on reviewing the smaller changes on other pages but here are the main pages
| # 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. | ||
| 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 applications such as [Workflows](/explore-analyze/workflows.md), and {{kib}} automatically manages the credentials needed to run workloads as those accounts. |
There was a problem hiding this comment.
this feels like too much detail here + misses the custom case
| 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 applications such as [Workflows](/explore-analyze/workflows.md), and {{kib}} automatically manages the credentials needed to run workloads as those accounts. | |
| 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). |
| Create user-managed service accounts and assign roles to control programmatic access to {{es}} and {{kib}} APIs. | ||
| 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 applications such as [Workflows](/explore-analyze/workflows.md), and {{kib}} automatically manages the credentials needed to run workloads as those accounts. | ||
|
|
||
| Some service account capabilities differ between [{{serverless-full}}](/deploy-manage/deploy/elastic-cloud/serverless.md) and other [deployment types](/deploy-manage/deploy.md#choosing-your-deployment-type). This guide uses {{stack}} deployments to refer to {{ech}}, {{ece}}, {{eck}}, and self-managed deployments. |
There was a problem hiding this comment.
I'd kill this paragraph altogether:
- we are just stating the differences in the opening right now - likely enough
- we don't define stack inline like this elsewhere. remember this page has an applies tag that provides deployment availability context
|
|
||
| % TBD: pending to add link to the setting reference as soon as the kibana PR is created and merged | ||
| Service accounts are enabled by default on {{ech}}, {{ece}}, {{eck}}, and self-managed deployments. Set the {{kib}} `xpack.security.serviceAccounts.enabled` setting to `false` to turn off the **Service accounts** page and workload integration. | ||
| - On {{stack}} deployments, make sure service accounts are enabled in {{kib}}. They're enabled by default. If they've been turned off, set [`xpack.security.serviceAccounts.enabled`](kibana://reference/configuration-reference/security-settings.md#service-account-settings) to `true` before continuing. |
There was a problem hiding this comment.
structure of this one reads a little circuitous. consider
| - On {{stack}} deployments, make sure service accounts are enabled in {{kib}}. They're enabled by default. If they've been turned off, set [`xpack.security.serviceAccounts.enabled`](kibana://reference/configuration-reference/security-settings.md#service-account-settings) to `true` before continuing. | |
| - 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. |
| 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). |
There was a problem hiding this comment.
this is important to consider in the context of the procedure. currently it arrives as a surprise after the config is done
| - {{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). | |
| - {{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). |
|
|
||
| {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] |
There was a problem hiding this comment.
could bump this to an h2 as it's important context not limited to the creation flow
| :::: | ||
|
|
||
| $$$service-accounts-explanation$$$ | ||
| 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. |
There was a problem hiding this comment.
same note about defining stack inline.
also we now have a problem with overall page placement. cluster user auth is a purely stack concept
don't think we will be able to fix this for 9.6 perhaps, but we need to fix at minimum with a link down from the serverless auth context, like we did with document- and field-level security
does cloud control built-in service accounts at the org level too?
| ``` | ||
|
|
||
| You create these accounts and assign roles to control their privileges. Accounts created in {{kib}} use the `kibana` namespace, and their principals have the form `kibana/<name>`. | ||
| You create these accounts and assign roles to control their privileges. The 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/<name>`. |
There was a problem hiding this comment.
You create these accounts and assign roles to control their privileges.
sentence too much in conversation with heading
| You create these accounts and assign roles to control their privileges. The 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/<name>`. | |
| 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/<name>`. |
| ### Service accounts in {{serverless-short}} [service-accounts-serverless] | ||
| ```{applies_to} | ||
| serverless: ga | ||
| ``` | ||
|
|
||
| {{serverless-short}} uses the same [built-in service accounts](#built-in-service-accounts), with credentials managed by Elastic. | ||
|
|
||
| User-managed accounts have a generated identifier that is independent of the name you enter in {{kib}}. Their identifiers don't use the `<namespace>/<service>` principal format of {{stack}} accounts. | ||
|
|
||
| You can assign a user-managed account to a workflow, and {{kib}} manages the short-lived credentials used to run it. You can't obtain a token for an external application or manage these accounts through the {{es}} service account APIs. The service token instructions on this page apply to {{stack}}. | ||
|
|
||
| The account's privileges are limited to those allowed by both its assigned roles and its creator's access at creation time. For details about role limits, cross-project search, and deleting accounts, refer to [Create and manage service accounts in {{kib}}](manage-service-accounts-in-kibana.md). |
There was a problem hiding this comment.
most of this is duplicative with the rest of the page. it also puts tiny serverless details in a dedicated section when they would be more helpful next to their stack counterparts. by paragraph:
- the structure of the page implies that built in service accounts are avail for serverless already (we could clarify about management in the built-in service acconts section)
- generated identifier is useful but maybe could just be paired with the kibana namespace info above: "In {{stack}}, accounts created in {{kib}} use the
kibananamespace, and their principals have the formkibana/<name>." - we explain this where we explain user-managed service accounts above
- we explain this where we explain creation on the child page. prob not necessary for this parent
| 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 roles required by the workflow steps. Accounts created directly through the {{es}} API can't be used for workflow execution, even if they use the `kibana` namespace. | ||
| 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. |
There was a problem hiding this comment.
I'm confused - it says you can create this without leaving the editor, but then says the account must be created (which implies pre-creation)
| 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. {{es}} resolves the account's roles whenever it authenticates, so changes to an assigned role apply to later credential requests without saving the workflow again. | ||
| 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. |
There was a problem hiding this comment.
perhaps? "affect" is a little confusing
| 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. | |
| The workflow stores a reference to the account. When a run starts, {{kib}} obtains a short-lived credential and renews it as needed. Edits to an assigned role update the account's privileges. You don't need to save the workflow again. |
| 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. |
There was a problem hiding this comment.
A service account token, or service token, is a unique string that a service uses to authenticate with {{es}}.
We state above (correctly) that these tokens can also authenticate to Kibana. Is it confusing that this only says {{es}}?
For a given service account, each token must have a unique name.
This feels out of place in a section talking about tokens. I'd remove it.
Because tokens include access credentials, they should always be kept secret by whichever client is using them.
pedantic nit-picking: The tokens are credentials, they don't include 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}}, {{kib}} creates and stores a service token 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. |
There was a problem hiding this comment.
| When you create a user-managed service account in {{kib}}, {{kib}} creates and stores a service token 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. | |
| When you create a user-managed service account in {{kib}}, {{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. |
| You can create a service token using either: | ||
|
|
||
| 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. |
There was a problem hiding this comment.
The API is only viable if you're not going to use them for Kibana workloads (such as Workflows). If the Service Account is to be used for Kibana workloads, then it must be created within Kibana. Otherwise Kibana won't have the opportunity to create its own managed token.
edit: I see you make this distinction on the child Manage service accounts page.
|
|
||
| * 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 either: |
There was a problem hiding this comment.
we don't mention the Kibana UI in this list
| Roles reserved for internal use by [{{alerting-v2-system}}](/explore-analyze/alerting/esql/system-overview.md) aren't available in the role picker. | ||
|
|
There was a problem hiding this comment.
This feels unnecessary to state, do we need to keep it?
| Roles reserved for internal use by [{{alerting-v2-system}}](/explore-analyze/alerting/esql/system-overview.md) aren't available in the role picker. |
| ### Credentials after deletion in {{serverless-short}} [delete-service-account-serverless-credentials] | ||
| ```{applies_to} | ||
| serverless: ga | ||
| ``` | ||
|
|
||
| Deleting an account stops new tokens from being issued immediately. Tokens already issued remain valid until they expire, which takes a few minutes at most. |
There was a problem hiding this comment.
We don't expose tokens to end users in serverless, so I don't think there's a need to discuss this within our documentation.
| ### Credentials after deletion in {{serverless-short}} [delete-service-account-serverless-credentials] | |
| ```{applies_to} | |
| serverless: ga | |
| ``` | |
| Deleting an account stops new tokens from being issued immediately. Tokens already issued remain valid until they expire, which takes a few minutes at most. |
| 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. |
There was a problem hiding this comment.
We do not invalidate short-lived access tokens.
| 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. | |
| Deleting an account through {{kib}} attempts to remove every service token, including the credential it stores for workloads and tokens created outside {{kib}}. If any credential cleanup fails, {{kib}} completes the deletion and reports a warning. |
|
|
||
| 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. If you delete an account directly through the {{es}} API, short-lived access tokens already issued to the account remain valid until they expire, 20 minutes after issuance by default. |
There was a problem hiding this comment.
This statement is talking about two token types: the never-expiring type, and the short-lived type. Remaining short-lived tokens will not prevent a SA from being re-created. Only the lingering never-expiring tokens will prevent this.
| Ensure that your [HTTP authentication configuration](kibana-authentication.md#http-authentication) accepts the `Bearer` scheme. | ||
|
|
There was a problem hiding this comment.
I'm torn on whether or not to include this. Kibana accepts the Bearer scheme by default, so an administrator would have to go out of their way to turn this off.
| Ensure that your [HTTP authentication configuration](kibana-authentication.md#http-authentication) accepts the `Bearer` scheme. |
|
|
||
| Ensure that your [HTTP authentication configuration](kibana-authentication.md#http-authentication) accepts the `Bearer` scheme. | ||
|
|
||
| The response depends on the account's roles. A `403` response means the account authenticated but doesn't have the required privilege. Add privileges by editing the assigned role rather than assigning broad administrative roles to the account. |
There was a problem hiding this comment.
This behavior is standard for HTTP APIs, and is probably not worth mentioning.
| The response depends on the account's roles. A `403` response means the account authenticated but doesn't have the required privilege. Add privileges by editing the assigned role rather than assigning broad administrative roles to the account. |
shainaraskas
left a comment
shainaraskas
left a comment
There was a problem hiding this comment.
couple higher sev ones in here like the malformed applies tag + the kibana page-level tag
otherwise good job reconciling two similar but not same experiences!
| Use a user-managed service account to authenticate programmatic requests to {{kib}}. The account provides a non-human identity whose privileges come from its assigned roles. | ||
| 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. | ||
|
|
||
| On {{serverless-full}}, use [API keys](/deploy-manage/api-keys.md) for programmatic access from external applications, because service account tokens aren't available for this use. |
There was a problem hiding this comment.
"for this use" is a bit vague. perhaps:
| On {{serverless-full}}, use [API keys](/deploy-manage/api-keys.md) for programmatic access from external applications, because service account tokens aren't available for this use. | |
| 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). |
| :::{warning} | ||
| :applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"} | ||
| :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 binding, and editing or deleting a bound workflow, also requires 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). | ||
| 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). | ||
| ::: |
There was a problem hiding this comment.
something is wrong here - the page is framed for stack only
I see some serverless tags floating around. might need a rethink at the page level. serverless-custom-roles links to it so that's probably the easiest way forward, but I think this page is ultimately misplaced as a reference for kibana privileges and we should maybe log an issue if you agree
|
|
||
| - [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md). | ||
| - [Authenticate to the {{kib}} API with a service account](authenticate-kibana-api-with-service-account.md). | ||
| - {applies_to}`{serverless: unavailable}` [Authenticate to the {{kib}} API with a service account](authenticate-kibana-api-with-service-account.md). |
There was a problem hiding this comment.
| - {applies_to}`{serverless: unavailable}` [Authenticate to the {{kib}} API with a service account](authenticate-kibana-api-with-service-account.md). | |
| - {applies_to}`serverless: unavailable` [Authenticate to the {{kib}} API with a service account](authenticate-kibana-api-with-service-account.md). |
Summary (9.6 feature, DO NOT MERGE until release date)
The service accounts documentation currently describes only built-in identities, while Workflows authorization assumes execution as a user. This draft documents user-managed service accounts for Elastic Stack 9.6 on Elastic Cloud Hosted, Elastic Cloud Enterprise, Elastic Cloud on Kubernetes, and self-managed deployments, with Kibana as the starting point for account creation.
Related to elastic/docs-content-internal#1733. The scope follows the Tier 1 guidance in Larry's detailed implementation notes. Serverless availability remains marked as unavailable, with follow-up notes for documenting its differences when enabled.
Coverage
settings.run_as, verifying execution identity, testing saved workflows, handling identity and permission failures, and removing assignments.Review
Major updates are in the following docs:
Service accounts + 2 new child-docs
Workflow authorization updates
Run a workflow as a service account (new doc)
Draft review points
Workflows permissions: the current Kibana code requires
manage_securityto edit or delete an already-bound workflow as well as to change its assignment. Larry's notes describe the requirement as binding-only. The draft follows the code and includes an internal release-check comment; confirm the intended 9.6 behavior and update the related pages together if needed.Recheck the account creation and role-selection UI after elastic/kibana#296889 lands.
Companion reference work remains in the product repositories: Kibana service account settings, audit event lifecycle labels, and the query service accounts API link when available. Internal follow-up comments identify these items.
Generative AI disclosure
OpenAI Codex assisted with drafting, product-source research, editing, and validation. The documentation was refined iteratively with the author. SME review is still needed for the permissions discrepancy and the release-dependent UI details listed above.
Closes elastic/docs-content-internal#1733