anchor.diff:  interface. See <<encrypt-http-communication,encrypt HTTP client communications for {es}>>.
   // end::service-accounts-tls[]
   
  +[discrete]
   [[service-accounts-tokens]]
  -==== How service account tokens work
  -A service account token, or simply 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 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 account tokens can be backed by either the `service_tokens` file or the
  -`.security` index. You can create multiple service account tokens for a single
  +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 account token to use a service account. You can
  -create a service account token using either:
  +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 account token in the `$ES_HOME/config/service_tokens` file
  +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 tokens API>>,
  -which saves the new service account token in the `.security` index and returns
  +* 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
   
  -Service account tokens never expire. You must actively <<security-api-delete-service-token,delete>> them if they are no longer needed.
  +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 account tokens
  +=== Authenticate with service tokens
   
   NOTE: Service accounts currently do not support basic authentication.
   
  
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: 
  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 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.
  
  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
  * 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]]
  === 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 and
  must be unique within its namespace.
  
  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: 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[]
  