Service accounts
editService accounts
editThe Elastic Stack security features provide service accounts specifically for integration with external services that connect to Elasticsearch, 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 Elasticsearch 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 because they:
-
Do not rely on the 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 get users API. To retrieve a service account, use the get service accounts API.
Service accounts usage
editService accounts have a
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 Elasticsearch.
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.
In production mode, service accounts require TLS on the HTTP interface. A runtime check prevents you from invoking any related APIs or authenticating with a service account token unless TLS is enabled on the HTTP interface. See encrypt HTTP client communications for Elasticsearch.
Service account tokens
editA service account token, or service token, is a unique string that a service uses to authenticate with Elasticsearch. 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 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 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 Elasticsearch will fail without even checking the value of the
service token.
Service tokens never expire. You must actively delete them if they are no longer needed.
Authenticate with service tokens
editService accounts currently do not support basic authentication.
To use a service account token, include the generated token value in a request
with an Authorization: Bearer
header:
curl -H "Authorization: Bearer AAEAAWVsYXN0aWM...vZmxlZXQtc2VydmVyL3Rva2VuMTo3TFdaSDZ" http://localhost:9200/_security/_authenticate
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:
{ "username": "elastic/fleet-server", "roles": [], "full_name": "Service account - elastic/fleet-server", "email": null, "token": { "name": "token1", "type": "_service_account_index" }, "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" }