Role-based access control in Elasticsearch - Step-by-Step Execution

Concept Flow - Role-based access control

User sends request

↓

Check user role

↓

Match role permissions

↓

Allow or deny access

↓

Return response

The system checks the user's role, matches permissions, then allows or denies access accordingly.

Execution Sample

Elasticsearch

POST /_security/role/my_role
{
  "indices": [
    {
      "names": ["logs-*"],
      "privileges": ["read"]
    }
  ]
}

Defines a role 'my_role' with read access to indices matching 'logs-*'.

Execution Table

Step	Action	Input/Condition	Result	Next Step
1	Receive request	User requests access to 'logs-2024'	Request received	Check user role
2	Check user role	User has role 'my_role'	Role found: 'my_role'	Match role permissions
3	Match role permissions	Role 'my_role' allows read on 'logs-*'	Permission matches request	Allow or deny access
4	Allow or deny access	Permission allows read	Access granted	Return response
5	Return response	Access granted	Response sent: 200 OK	End

💡 Access granted because user role permissions match the requested action.

Variable Tracker

Variable	Start	After Step 2	After Step 3	Final
user_role	undefined	'my_role'	'my_role'	'my_role'
requested_action	undefined	'read logs-2024'	'read logs-2024'	'read logs-2024'
permission_match	false	false	true	true
access_granted	false	false	false	true

Key Moments - 2 Insights

Why does the system check the user role before permissions?

Because permissions are linked to roles, the system must first identify the user's role to know which permissions to check, as shown in step 2 of the execution table.

What happens if the requested action does not match role permissions?

The system denies access and does not proceed to allow access, stopping the flow before step 4, as the permission_match would be false.

Visual Quiz - 3 Questions

Look at the execution table, what is the user_role value after step 2?

A undefined

B 'admin'

C 'my_role'

D null

💡 Hint

Check the variable_tracker table under 'user_role' after Step 2.

At which step does the system confirm permission matches the requested action?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Look at the 'Match role permissions' action in the execution_table.

If the user role did not have read permission, what would happen at step 4?

A Access denied

B Access granted

C Request retried

D Role changed

💡 Hint

Refer to the key moment about permission mismatch and the execution flow at step 4.

Concept Snapshot

Role-based access control (RBAC) in Elasticsearch:
- Define roles with specific permissions.
- Assign roles to users.
- When a user requests access, Elasticsearch checks the user's role.
- Permissions linked to the role determine if access is allowed.
- Access is granted or denied based on matching permissions.

Full Transcript

Role-based access control in Elasticsearch works by checking the user's role when a request is made. The system looks up the role assigned to the user, then checks if the role's permissions allow the requested action. If permissions match, access is granted; otherwise, it is denied. This process ensures users only access what their roles permit.

Practice

1. What is the main purpose of Role-based Access Control (RBAC) in Elasticsearch?

easy

A. To control who can perform specific actions by assigning roles

B. To speed up search queries

C. To store data in different formats

D. To backup Elasticsearch clusters automatically

Solution

1. Step 1: Understand RBAC concept

   RBAC is about managing permissions by assigning roles to users.

2. Step 2: Identify RBAC purpose in Elasticsearch

   It controls who can do what actions on the cluster or indexes.

3. Final Answer:

   To control who can perform specific actions by assigning roles -> Option A

4. Quick Check:

   RBAC = Control access by roles [OK]

Hint: RBAC means controlling access by roles, not data or speed [OK]

Common Mistakes:

• Confusing RBAC with data storage or backup
• Thinking RBAC speeds up queries
• Assuming RBAC changes data formats

2. Which of the following is the correct JSON structure to define a role with read access to the index logs-2024?

easy

A. {"cluster": ["all"], "indices": [{"names": ["logs-2024"], "privileges": ["monitor"]}]}

B. {"cluster": ["all"], "indices": [{"names": ["logs-2024"], "privileges": ["write"]}]}

C. {"cluster": ["read"], "indices": [{"names": ["logs-2024"], "privileges": ["write"]}]}

D. {"cluster": ["monitor"], "indices": [{"names": ["logs-2024"], "privileges": ["read"]}]}

Solution

1. Step 1: Check cluster privileges for read access

   Read access to an index usually requires cluster privileges like 'monitor', not 'all' or 'read'.

2. Step 2: Verify index privileges

   The index privileges must include 'read' for the specified index.

3. Final Answer:

   {"cluster": ["monitor"], "indices": [{"names": ["logs-2024"], "privileges": ["read"]}]} -> Option D

4. Quick Check:

   Cluster 'monitor' + index 'read' = correct role [OK]

Hint: Cluster 'monitor' + index 'read' grants read access [OK]

Common Mistakes:

• Using 'all' cluster privilege unnecessarily
• Confusing 'write' with 'read' privileges
• Assigning 'read' cluster privilege which is invalid

3. Given this role definition, what permissions does a user have on the sales-data index?

{
  "cluster": ["monitor"],
  "indices": [
    {
      "names": ["sales-data"],
      "privileges": ["read", "write"]
    }
  ]
}

medium

A. User can read and write data in sales-data index

B. User can only read data from sales-data index

C. User can manage cluster settings but not access sales-data

D. User has full admin access to all indexes

Solution

1. Step 1: Analyze cluster privileges

   Cluster privilege 'monitor' allows monitoring but no write or admin cluster changes.

2. Step 2: Analyze index privileges

   Privileges 'read' and 'write' on 'sales-data' index allow reading and writing data there.

3. Final Answer:

   User can read and write data in sales-data index -> Option A

4. Quick Check:

   Index 'read' + 'write' = read/write access [OK]

Hint: Check index privileges for read/write to know access level [OK]

Common Mistakes:

• Ignoring 'write' privilege and assuming read-only
• Confusing cluster 'monitor' with admin rights
• Assuming full admin access without 'all' privilege

4. You defined this role but users report they cannot write to the app-logs index. What is the error?

{
  "cluster": ["monitor"],
  "indices": [
    {
      "names": ["app-logs"],
      "privileges": ["read"]
    }
  ]
}

medium

A. The cluster privilege 'monitor' is incorrect for write access

B. The index privilege should include 'write' to allow writing

C. The index name 'app-logs' is misspelled

D. The role JSON is missing a 'run_as' field

Solution

1. Step 1: Check index privileges

   The role only grants 'read' privilege on 'app-logs', so writing is not allowed.

2. Step 2: Identify missing privilege

   To write, the 'write' privilege must be added to the index privileges.

3. Final Answer:

   The index privilege should include 'write' to allow writing -> Option B

4. Quick Check:

   Write access needs 'write' privilege [OK]

Hint: Write access requires 'write' privilege on index [OK]

Common Mistakes:

• Assuming 'monitor' cluster privilege allows writing
• Overlooking missing 'write' privilege on index
• Thinking 'run_as' is required for write permission

5. You want to create a role that allows a user to read from all indexes starting with prod- but only write to prod-logs. Which role definition is correct?

hard

A. {
"cluster": ["all"],
"indices": [
{"names": ["prod-logs"], "privileges": ["read", "write"]}
]
}

B. {
"cluster": ["monitor"],
"indices": [
{"names": ["prod-logs"], "privileges": ["read", "write"]},
{"names": ["prod-*"], "privileges": ["read", "write"]}
]
}

C. {
"cluster": ["monitor"],
"indices": [
{"names": ["prod-*"], "privileges": ["read"]},
{"names": ["prod-logs"], "privileges": ["write"]}
]
}

D. {
"cluster": ["monitor"],
"indices": [
{"names": ["prod-*"], "privileges": ["write"]}
]
}

Solution

1. Step 1: Understand the requirement

   User needs read access on all 'prod-*' indexes and write only on 'prod-logs'.

2. Step 2: Check each option

   { "cluster": ["monitor"], "indices": [ {"names": ["prod-*"], "privileges": ["read"]}, {"names": ["prod-logs"], "privileges": ["write"]} ] } correctly assigns 'read' to 'prod-*' and 'write' to 'prod-logs'. { "cluster": ["all"], "indices": [ {"names": ["prod-logs"], "privileges": ["read", "write"]} ] } gives full cluster 'all' which is too broad. { "cluster": ["monitor"], "indices": [ {"names": ["prod-logs"], "privileges": ["read", "write"]}, {"names": ["prod-*"], "privileges": ["read", "write"]} ] } incorrectly grants 'read' and 'write' to all 'prod-*' indexes. { "cluster": ["monitor"], "indices": [ {"names": ["prod-*"], "privileges": ["write"]} ] } wrongly gives 'write' to all 'prod-*' indexes.

3. Final Answer:

   { "cluster": ["monitor"], "indices": [ {"names": ["prod-*"], "privileges": ["read"]}, {"names": ["prod-logs"], "privileges": ["write"]} ] } -> Option C

4. Quick Check:

   Read on prod-* + write on prod-logs = correct role [OK]

Hint: Use wildcard for read, specific index for write [OK]

Common Mistakes:

• Giving write privilege to all prod-* indexes
• Using cluster 'all' unnecessarily
• Mixing up index names and privileges