anchor.diff:  
   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 be authenticated
  +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.
   
  -With service accounts, services (such as {fleet} server) can create a
  -service account token, authenticate with that token, and manage their own API keys.
  -Multiple service account tokens can be created for the same service account.
  -This prevents credential sharing between multiple instances of the same external service.
  -That is, these instances can assume the same identity while having their own distinct
  -service account tokens for authentication.
  +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 vs built-in users
  -Service account is an evolution of the built-in users. It provides
  -flexibility over built-in users because they:
  +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.
  +
  +Service accounts provide flexibility over <<built-in-users,built-in users>> 
  +because they:
   
   * Do not rely on the <<native-realm,internal `native` realm>>, and aren't
   always required to rely on the `.security` index
  -* Use a role descriptor named after the service account principal instead of traditional roles
  +* Use a role descriptor named after the service account principal instead of 
  +traditional roles
   * Support multiple credentials through service account tokens
   
   Service accounts are not included in the response of the
   <<security-api-get-user,get users API>>. To retrieve a service account, use the
   <<security-api-get-service-accounts,get service accounts API>>.
   
  +[discrete]
   [[service-accounts-explanation]]
  -==== How service accounts work
  +=== Service accounts usage
   Service accounts have a
   <<security-api-get-service-accounts-path-params,unique principal>> that takes
   the format of `<namespace>/<service>`, where the `namespace` is a top-level
  -grouping of service accounts, and `service` is the name of the service.
  +grouping of service accounts, and `service` is the name of the service and
  +must be unique within its namespace.
   
  -Currently, only one service account is available:
  +Service accounts are predefined in code. Currently, only one service account is available:
   
   `elastic/fleet-server`:: The service account used by the {fleet} server to
   communicate with {es}.
   
   // tag::service-accounts-usage[]
  -IMPORTANT: The predefined service accounts are intended for external services
  -connecting to {es}. Do not attempt to use service accounts for authenticating
  -individual users.
  +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.
   // end::service-accounts-usage[]
   
   // tag::service-accounts-tls[]
  
positive.code:   "full_name": "Service account - elastic/fleet-server",
    "email": null,
    "token": {
      "name": "token1"      <1>
    },
    "metadata": {
      "_elastic_service_account": true
    },
    "enabled": true,
    "authentication_realm": {
      "name": "service_account",
      "type": "service_account"
    },
    "lookup_realm": {
      "name": "service_account",
      "type": "service_account"
    },
    "authentication_type": "token"
  }
  ----
  // NOTCONSOLE
  <1> Name of the service account token
  
negative.code: interface. See <<encrypt-http-communication,encrypt HTTP client communications for {es}>>.
  // end::service-accounts-tls[]
  
  [discrete]
  [[service-accounts-tokens]]
  === Service account tokens
  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.
  
  Service tokens can be backed by either the `service_tokens` file or the
  `.security` index. You can create multiple service tokens for a single
  service account, which enables multiple instances of the same service to run
  with different credentials.
  
  You must create a service token to use a service account. You can
  create a service token using either:
  
  * The <<service-tokens-command,elasticsearch-service-tokens>> CLI tool, which
  saves the new service token in the `$ES_HOME/config/service_tokens` file
  and outputs the bearer token to your terminal
  * The <<security-api-create-service-token,create service account token API>>,
  which saves the new service token in the `.security` index and returns
  the bearer token in the HTTP response
  
  Both of these methods 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.
  
  Service tokens never expire. You must actively 
  <<security-api-delete-service-token,delete>> them if they are no longer needed.
  
  [discrete]
  [[authenticate-with-service-account-token]]
  === Authenticate with service tokens
  
  NOTE: Service accounts currently do not support basic authentication.
  
  