Role-based access control in Elasticsearch - Mini Project: Build & Apply

Role-based access control

📖 Scenario: You are managing access to an Elasticsearch cluster. Different users have different roles, and each role has specific permissions to access certain indices.We want to create a simple role-based access control setup using Elasticsearch role definitions.

🎯 Goal: Build a role definition in Elasticsearch that assigns specific index permissions to roles, then check the permissions assigned.

📋 What You'll Learn

Create a role called read_only with read access to the products index

Create a role called write_access with write access to the orders index

Create a variable roles that holds these role definitions as a dictionary

Print the permissions of the read_only role

💡 Why This Matters

🌍 Real World

Role-based access control is essential in Elasticsearch to secure data by limiting what users can see or change.

💼 Career

Many jobs require managing Elasticsearch security roles to protect sensitive data and ensure proper access.

1

Create role definitions

Create a dictionary called roles with two keys: read_only and write_access. The read_only role should have indices permission with names as ["products"] and privileges as ["read"]. The write_access role should have indices permission with names as ["orders"] and privileges as ["write"].

Elasticsearch

# Create the roles dictionary with read_only and write_access roles
# Your code here

Hint

Use a dictionary with keys read_only and write_access. Each key maps to another dictionary with key indices which is a list of dictionaries specifying names and privileges.

2

Add a helper variable for role to check

Create a variable called role_to_check and set it to the string "read_only".

Elasticsearch

roles = {
    "read_only": {
        "indices": [
            {
                "names": ["products"],
                "privileges": ["read"]
            }
        ]
    },
    "write_access": {
        "indices": [
            {
                "names": ["orders"],
                "privileges": ["write"]
            }
        ]
    }
}
# Create a variable role_to_check and set it to "read_only"
# Your code here

Hint

Just assign the string "read_only" to a variable named role_to_check.

3

Extract permissions for the selected role

Create a variable called permissions and set it to the indices value inside the roles dictionary for the key stored in role_to_check.

Elasticsearch

roles = {
    "read_only": {
        "indices": [
            {
                "names": ["products"],
                "privileges": ["read"]
            }
        ]
    },
    "write_access": {
        "indices": [
            {
                "names": ["orders"],
                "privileges": ["write"]
            }
        ]
    }
}
role_to_check = "read_only"
# Extract the indices permissions for the role stored in role_to_check
# Your code here

Hint

Use the variable role_to_check as a key to get the role from roles, then get the indices key from that role.

4

Print the permissions

Write a print statement to display the value of the permissions variable.

Elasticsearch

roles = {
    "read_only": {
        "indices": [
            {
                "names": ["products"],
                "privileges": ["read"]
            }
        ]
    },
    "write_access": {
        "indices": [
            {
                "names": ["orders"],
                "privileges": ["write"]
            }
        ]
    }
}
role_to_check = "read_only"
permissions = roles[role_to_check]["indices"]
# Print the permissions variable
# Your code here

Hint

Use print(permissions) to show the permissions.

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