Field and document level security in Elasticsearch - Mini Project: Build & Apply

Field and Document Level Security in Elasticsearch

📖 Scenario: You are managing a company's employee data stored in Elasticsearch. Some information is sensitive and should only be visible to certain users. You want to control which fields and documents each user can see.

🎯 Goal: Build an Elasticsearch role with field and document level security to restrict access to employee data. You will create a sample index, define a role with specific field and document filters, and test the access by querying the data.

📋 What You'll Learn

Create an Elasticsearch index called employees with sample employee documents

Define a role called employee_viewer that restricts access to certain fields and documents

Use field level security to allow viewing only name and department fields

Use document level security to allow viewing only employees in the sales department

Query the employees index using the employee_viewer role to see the filtered results

💡 Why This Matters

🌍 Real World

Companies often need to protect sensitive data by controlling who can see what information in their databases.

💼 Career

Understanding field and document level security is important for roles like Elasticsearch administrators, security engineers, and backend developers managing data access.

1

Create the employees index with sample data

Create an Elasticsearch index called employees and add these documents exactly: {"name": "Alice", "department": "sales", "salary": 70000}, {"name": "Bob", "department": "engineering", "salary": 90000}, {"name": "Carol", "department": "sales", "salary": 65000}

Elasticsearch

# Use Elasticsearch API to create index and add documents
# Your code here

Hint

Use the PUT method to create the index with mappings, then use POST to add documents.

2

Define the employee_viewer role with field and document level security

Create a role called employee_viewer that grants read access to the employees index, allows viewing only the name and department fields, and restricts documents to those where department is sales

Elasticsearch

PUT /_security/role/employee_viewer
{
  "indices": [
    {
      "names": ["employees"],
      "privileges": ["read"],
      # Your code here
    }
  ]
}

Hint

Use field_security to specify allowed fields and query to filter documents by department.

3

Query the employees index using the employee_viewer role

Write a search query to get all documents from the employees index using the employee_viewer role. Use the GET /employees/_search API and assume the role is applied. The query should return only employees in the sales department with only the name and department fields visible.

Elasticsearch

# Use GET /employees/_search to query the index
# Your code here

Hint

Use a simple match_all query to retrieve documents. The role's document and field level security will filter results automatically.

4

Display the filtered search results

Print the search results from the GET /employees/_search query showing only employees in the sales department with only the name and department fields visible. The output should list the documents returned by Elasticsearch.

Elasticsearch

# Print the search hits below
# Your code here

Hint

The output should show only Alice and Carol with their name and department fields. The salary field should not appear.

Practice

1. What is the main purpose of field-level security in Elasticsearch?

easy

A. To restrict access to specific fields within documents

B. To encrypt the entire Elasticsearch index

C. To limit the number of documents returned in a query

D. To control user login credentials

Solution

1. Step 1: Understand field-level security concept

   Field-level security controls which fields in a document a user can see or query.

2. Step 2: Compare with other options

   Encryption and login control are unrelated to field-level security; limiting documents is document-level security.

3. Final Answer:

   To restrict access to specific fields within documents -> Option A

4. Quick Check:

   Field-level security = restrict fields [OK]

Hint: Field-level security hides fields, not whole documents [OK]

Common Mistakes:

• Confusing field-level with document-level security
• Thinking it encrypts data
• Assuming it controls user passwords

2. Which of the following is the correct syntax to define field-level security in an Elasticsearch role?

easy

A. "fields": ["title", "author"]

B. "field_security": { "deny": ["title", "author"] }

C. "field_security": { "grant": ["title", "author"] }

D. "field_access": { "allow": ["title", "author"] }

Solution

1. Step 1: Recall correct field-level security syntax

   Elasticsearch uses "field_security" with a "grant" array to specify allowed fields.

2. Step 2: Eliminate incorrect options

   "deny" is not valid here; "fields" and "field_access" are incorrect keys.

3. Final Answer:

   "field_security": { "grant": ["title", "author"] } -> Option C

4. Quick Check:

   Use "field_security" with "grant" for allowed fields [OK]

Hint: Use "field_security" with "grant" to allow fields [OK]

Common Mistakes:

• Using "deny" instead of "grant"
• Wrong key names like "fields" or "field_access"
• Confusing syntax with document-level security

3. Given this role definition snippet:

{
  "indices": [
    {
      "names": ["books"],
      "privileges": ["read"],
      "query": { "term": { "genre": "fiction" } },
      "field_security": { "grant": ["title", "author"] }
    }
  ]
}

What documents and fields will a user with this role see when querying the books index?

medium

A. All documents showing all fields

B. All documents showing only 'title' and 'author' fields

C. Only documents where genre is 'fiction' showing all fields

D. Only documents where genre is 'fiction' showing only 'title' and 'author' fields

Solution

1. Step 1: Analyze document-level security query

   The "query" limits documents to those with genre 'fiction'.

2. Step 2: Analyze field-level security grant

   Only "title" and "author" fields are visible due to "field_security".

3. Final Answer:

   Only documents where genre is 'fiction' showing only 'title' and 'author' fields -> Option D

4. Quick Check:

   Query filters docs + grant limits fields = Only documents where genre is 'fiction' showing only 'title' and 'author' fields [OK]

Hint: Query filters docs; field_security limits fields shown [OK]

Common Mistakes:

• Ignoring the query filter on documents
• Assuming all fields are visible
• Confusing document and field level restrictions

4. You defined this role snippet:

{
  "indices": [
    {
      "names": ["library"],
      "privileges": ["read"],
      "query": { "term": { "category": "science" } },
      "field_security": { "grant": ["title", "summary"] }
    }
  ]
}

But users report they see all documents and fields. What is the likely error?

medium

A. The query filter is incorrect or not applied properly

B. Field names in grant are misspelled

C. Privileges should include "write" to restrict fields

D. Role must include "manage" privilege for security to work

Solution

1. Step 1: Check query filter correctness

   If the query filter is malformed or ignored, document filtering won't happen.

2. Step 2: Verify field_security and privileges

   Field names look correct; "read" privilege is enough for filtering; "write" or "manage" not needed.

3. Final Answer:

   The query filter is incorrect or not applied properly -> Option A

4. Quick Check:

   Query filter controls docs; if ignored, all docs show [OK]

Hint: Check query syntax if document filtering fails [OK]

Common Mistakes:

• Assuming 'write' privilege needed for filtering
• Ignoring query filter syntax errors
• Thinking field names cause document filtering issues

5. You want to create a role that allows users to read only documents where status is active and see only the name and email fields. Which role definition snippet correctly implements this?

hard

A. {
"indices": [
{
"names": ["users"],
"privileges": ["read"],
"query": { "match": { "status": "active" } },
"field_security": { "deny": ["password"] }
}
]
}

B. {
"indices": [
{
"names": ["users"],
"privileges": ["read"],
"query": { "term": { "status": "active" } },
"field_security": { "grant": ["name", "email"] }
}
]
}

C. {
"indices": [
{
"names": ["users"],
"privileges": ["read"],
"query": { "term": { "status": "active" } },
"fields": ["name", "email"]
}
]
}

D. {
"indices": [
{
"names": ["users"],
"privileges": ["read"],
"query": { "term": { "status": "active" } }
}
]
}

Solution

1. Step 1: Verify document-level security query

   Using "term" query on "status" with "active" correctly filters documents.

2. Step 2: Verify field-level security syntax

   "field_security" with "grant" array specifying "name" and "email" fields is correct.

3. Step 3: Eliminate incorrect options

   { "indices": [ { "names": ["users"], "privileges": ["read"], "query": { "match": { "status": "active" } }, "field_security": { "deny": ["password"] } } ] } uses "deny" which is invalid; { "indices": [ { "names": ["users"], "privileges": ["read"], "query": { "term": { "status": "active" } }, "fields": ["name", "email"] } ] } uses wrong key "fields"; { "indices": [ { "names": ["users"], "privileges": ["read"], "query": { "term": { "status": "active" } } } ] } lacks field-level security.

4. Final Answer:

   Role with "query" term filter and "field_security" grant for "name" and "email" -> Option B

5. Quick Check:

   Use "query" for docs + "field_security" grant for fields [OK]

Hint: Use "query" for docs and "field_security" with "grant" for fields [OK]

Common Mistakes:

• Using "deny" instead of "grant" in field_security
• Using wrong keys like "fields" instead of "field_security"
• Omitting field-level security to restrict fields