Role-based access control in Elasticsearch - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this role definition query?

Given the following Elasticsearch role definition, what will be the effective cluster privileges for the role named data_analyst?

Elasticsearch

{
  "data_analyst": {
    "cluster": ["monitor"],
    "indices": [
      {
        "names": ["sales-*"],
        "privileges": ["read", "view_index_metadata"]
      }
    ]
  }
}

A ["all"]

B ["monitor"]

C ["monitor", "read", "view_index_metadata"]

D ["read", "view_index_metadata"]

💡 Hint

Cluster privileges and index privileges are separate in Elasticsearch roles.

The cluster field defines cluster-wide privileges, here only monitor. The indices field defines index-level privileges, which do not affect cluster privileges.

❓ Predict Output

intermediate

What error occurs when assigning an invalid privilege?

Consider this role definition snippet in Elasticsearch. What error will Elasticsearch return when trying to create this role?

Elasticsearch

{
  "invalid_role": {
    "cluster": ["invalid_privilege"],
    "indices": [
      {
        "names": ["logs-*"],
        "privileges": ["read"]
      }
    ]
  }
}

A 400 Bad Request with message 'unknown cluster privilege [invalid_privilege]'

B Role created successfully with no errors

C 500 Internal Server Error

D 403 Forbidden error

💡 Hint

Elasticsearch validates privileges strictly when creating roles.

Elasticsearch returns a 400 error if an unknown cluster privilege is specified, indicating the privilege is invalid.

🚀 Application

advanced

How to restrict a role to only write access on specific indices?

You want to create a role that allows users to only write data to indices starting with app-logs- but no read or delete access. Which role definition below achieves this?

A

{
  "write_only_role": {
    "cluster": [],
    "indices": [
      {
        "names": ["app-logs-*"],
        "privileges": ["write", "read"]
      }
    ]
  }
}

B

{
  "write_only_role": {
    "cluster": [],
    "indices": [
      {
        "names": ["app-logs-*"],
        "privileges": ["create", "index"]
      }
    ]
  }
}

C

{
  "write_only_role": {
    "cluster": ["write"],
    "indices": [
      {
        "names": ["app-logs-*"],
        "privileges": ["write"]
      }
    ]
  }
}

D

{
  "write_only_role": {
    "cluster": [],
    "indices": [
      {
        "names": ["app-logs-*"],
        "privileges": ["write"]
      }
    ]
  }
}

💡 Hint

Cluster privileges are not needed for index write access. Use only index privileges.

Option D grants only the write privilege on the specified indices, which allows writing but not reading or deleting. Other options either add read or invalid cluster privileges.

🔧 Debug

advanced

Why does this role fail to grant read access on indices?

This role is intended to allow read access on indices named user-data-*, but users report they cannot read those indices. What is the cause?

Elasticsearch

{
  "user_reader": {
    "cluster": ["monitor"],
    "indices": [
      {
        "names": ["user-data-*"],
        "privileges": ["read"]
      }
    ]
  }
}

A Cluster privileges must include 'read' to allow index reading

B The 'privileges' field is missing 'view_index_metadata'

C The 'names' field should be a list, not a string

D The role name 'user_reader' is reserved and cannot be used

💡 Hint

Check the data type of the 'names' field in the indices array.

The 'names' field must be an array of strings. Using a string causes the role to be invalid and not grant privileges.

🧠 Conceptual

expert

What is the effect of overlapping roles with conflicting privileges?

If a user is assigned two roles: one grants read access on logs-* indices, and another denies read access on logs-2023-* indices, what will be the user's effective access to logs-2023-01?

A The user will be denied read access because deny privileges take precedence

B The user will have read access because allow privileges override deny

C The user will have read access only if the roles are merged manually

D The user will have no access because conflicting roles cause an error

💡 Hint

In Elasticsearch, deny rules override allow rules when conflicts occur.

Elasticsearch uses a deny-overrides policy. If any role denies access to a resource, that denial takes precedence over any allow.

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