API key management in Elasticsearch - Step-by-Step Execution

Concept Flow - API key management

Create API Key Request

↓

Elasticsearch Validates Request

↓

Generate API Key with Permissions

↓

Return API Key and ID

↓

Use API Key in Requests

↓

Elasticsearch Authenticates Using API Key

↓

API Key Usage Allowed or Denied

↓

Optional: Invalidate API Key

↓

End

This flow shows how an API key is created, returned, used for authentication, and optionally invalidated in Elasticsearch.

Execution Sample

Elasticsearch

POST /_security/api_key
{
  "name": "my-api-key",
  "role_descriptors": {
    "my-role": { "cluster": ["all"] }
  }
}

This request creates an API key named 'my-api-key' with full cluster permissions.

Execution Table

Step	Action	Request/Response	Result
1	Send API key creation request	POST /_security/api_key with name and roles	Request received by Elasticsearch
2	Validate request	Check user permissions and request format	Request valid, proceed
3	Generate API key	Create key string and assign roles	API key and ID generated
4	Return API key	Response with id and api_key	Client receives API key
5	Use API key in request	Send request with Authorization: ApiKey <encoded>	Elasticsearch authenticates request
6	Authenticate API key	Check API key validity and permissions	Request allowed or denied
7	Optional: Invalidate API key	Send DELETE /_security/api_key with id	API key invalidated
8	Use invalidated key	Send request with invalidated key	Request denied due to invalid key

💡 Execution stops when API key is invalidated or request is denied.

Variable Tracker

Variable	Start	After Step 3	After Step 4	After Step 7	Final
api_key_id	null	generated_id_123	generated_id_123	null	null
api_key_string	null	generated_key_abc	generated_key_abc	null	null
api_key_valid	false	true	true	false	false

Key Moments - 3 Insights

Why does the API key become invalid after step 7?

Because the API key is explicitly invalidated by a DELETE request, as shown in execution_table row 7, making it unusable for future requests.

How does Elasticsearch know if the API key has the right permissions?

During authentication (step 6), Elasticsearch checks the roles assigned to the API key against the requested action, as shown in execution_table row 6.

What happens if the API key creation request is invalid?

The request is rejected during validation (step 2), so no API key is generated, stopping the flow early.

Visual Quiz - 3 Questions

Look at the execution_table, what is the state of api_key_valid after step 4?

A true

B false

C null

D undefined

💡 Hint

Check variable_tracker column 'After Step 4' for 'api_key_valid'

At which step does Elasticsearch authenticate the API key in a request?

A Step 5

B Step 6

C Step 3

D Step 7

💡 Hint

See execution_table row describing authentication process

If the API key is invalidated, what happens when it is used again?

A Request is allowed

B API key is regenerated automatically

C Request is denied

D Request is ignored

💡 Hint

Refer to execution_table row 8 about using invalidated key

Concept Snapshot

API Key Management in Elasticsearch:
- Create API key with POST /_security/api_key
- Assign roles for permissions
- Use API key in Authorization header
- Elasticsearch authenticates API key on each request
- API keys can be invalidated to revoke access

Full Transcript

This visual execution trace shows how API key management works in Elasticsearch. First, a client sends a request to create an API key with a name and roles. Elasticsearch validates the request, generates the key and ID, and returns them. The client then uses the API key in the Authorization header for subsequent requests. Elasticsearch authenticates these requests by checking the API key's validity and permissions. Optionally, the API key can be invalidated, after which any use of that key is denied. Variables like api_key_id and api_key_valid change state during these steps, reflecting the lifecycle of the API key.

Practice

1. What is the primary purpose of an API key in Elasticsearch?

easy

A. To monitor Elasticsearch cluster health

B. To store data inside Elasticsearch indices

C. To allow applications to securely access Elasticsearch with specific permissions

D. To backup Elasticsearch data automatically

Solution

1. Step 1: Understand API key role

   API keys are secret tokens used to authenticate and authorize applications.

2. Step 2: Identify purpose in Elasticsearch

   They grant controlled access to Elasticsearch resources based on assigned roles.

3. Final Answer:

   To allow applications to securely access Elasticsearch with specific permissions -> Option C

4. Quick Check:

   API key = secure app access [OK]

Hint: API keys control app access permissions [OK]

Common Mistakes:

• Confusing API keys with data storage
• Thinking API keys monitor cluster health
• Assuming API keys handle backups

2. Which of the following is the correct Elasticsearch API call to create an API key?

easy

A. DELETE /_security/api_key

B. GET /_security/api_key/create

C. PUT /_security/api_key

D. POST /_security/api_key

Solution

1. Step 1: Recall API key creation syntax

   Elasticsearch uses POST method to create resources like API keys.

2. Step 2: Match correct endpoint

   The correct endpoint for creating an API key is POST /_security/api_key.

3. Final Answer:

   POST /_security/api_key -> Option D

4. Quick Check:

   POST + /_security/api_key = create key [OK]

Hint: Use POST to create API keys in Elasticsearch [OK]

Common Mistakes:

• Using GET or DELETE for creation
• Confusing endpoint paths
• Using PUT instead of POST

3. Given this API key creation request body, what will be the name of the created API key?

{
  "name": "my-app-key",
  "role_descriptors": {
    "my-role": {
      "cluster": ["all"],
      "index": [{"names": ["logs-*"], "privileges": ["read"]}]
    }
  }
}

medium

A. my-app-key

B. my-role

C. logs-*

D. all

Solution

1. Step 1: Identify the API key name field

   The "name" field in the request body sets the API key's name.

2. Step 2: Read the value of the "name" field

   The value is "my-app-key", which becomes the API key's name.

3. Final Answer:

   my-app-key -> Option A

4. Quick Check:

   API key name = "name" field value [OK]

Hint: API key name is in the "name" field [OK]

Common Mistakes:

• Confusing role name with API key name
• Using index pattern as key name
• Mistaking privileges for name

4. You try to delete an API key using this request: DELETE /_security/api_key?id=12345 but get an error. What is the likely cause?

medium

A. API key names cannot be deleted, only IDs

B. API key ID must be passed in the request body, not as a query parameter

C. DELETE method is not supported for API keys

D. You must use GET method to delete API keys

Solution

1. Step 1: Check API key deletion syntax

   Elasticsearch requires the API key ID in the request body JSON, not as a URL query parameter.

2. Step 2: Understand method support

   DELETE method is supported, but parameters must be correctly passed in the body.

3. Final Answer:

   API key ID must be passed in the request body, not as a query parameter -> Option B

4. Quick Check:

   Delete API key ID in body, not URL [OK]

Hint: Pass API key ID in JSON body for deletion [OK]

Common Mistakes:

• Passing ID as URL query parameter
• Using wrong HTTP method
• Confusing API key name with ID

5. You want to create an API key that only allows reading from indices starting with "sales-" and no cluster privileges. Which role descriptor is correct in the request body?

hard

A. { "role_descriptors": { "read_sales": { "cluster": [], "index": [{ "names": ["sales-*"], "privileges": ["read"] }] } } }

B. { "role_descriptors": { "read_sales": { "cluster": ["all"], "index": [{ "names": ["sales-*"], "privileges": ["write"] }] } } }

C. { "role_descriptors": { "read_sales": { "cluster": ["monitor"], "index": [{ "names": ["sales-*"], "privileges": ["all"] }] } } }

D. { "role_descriptors": { "read_sales": { "cluster": ["all"], "index": [{ "names": ["*"], "privileges": ["read"] }] } } }

Solution

1. Step 1: Identify required privileges

   The API key should have no cluster privileges and only read privileges on indices starting with "sales-".

2. Step 2: Match role descriptor to requirements

   { "role_descriptors": { "read_sales": { "cluster": [], "index": [{ "names": ["sales-*"], "privileges": ["read"] }] } } } has empty cluster privileges and read privilege on "sales-*" indices, matching the requirement.

3. Final Answer:

   { "role_descriptors": { "read_sales": { "cluster": [], "index": [{ "names": ["sales-*"], "privileges": ["read"] }] } } } -> Option A

4. Quick Check:

   No cluster + read sales-* = { "role_descriptors": { "read_sales": { "cluster": [], "index": [{ "names": ["sales-*"], "privileges": ["read"] }] } } } [OK]

Hint: Empty cluster array means no cluster privileges [OK]

Common Mistakes:

• Giving cluster all privileges by mistake
• Using write or all privileges instead of read
• Applying privileges to wrong index patterns