Field and document level security in Elasticsearch - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this Elasticsearch query with field level security?

Given the following role definition that restricts access to only the title and author fields, what fields will be returned in the search results?

Elasticsearch

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

Search query:
GET /books/_search
{
  "query": { "match_all": {} }
}

A No fields will be returned because the query does not specify fields.

B All fields will be returned because the query matches all documents.

C Only the <code>title</code> field will be returned because <code>author</code> is ignored.

D Only the fields <code>title</code> and <code>author</code> will be returned in each document.

💡 Hint

Field level security controls which fields are visible in the search results.

The role restricts access to only the title and author fields, so only these fields appear in the search results regardless of the query.

❓ Predict Output

intermediate

What documents are returned with this document level security query?

Given a role with document level security defined as { "term": { "status": "published" } }, what documents will the user see when running GET /articles/_search?

Elasticsearch

{
  "indices": [
    {
      "names": ["articles"],
      "privileges": ["read"],
      "query": {
        "term": { "status": "published" }
      }
    }
  ]
}

Search query:
GET /articles/_search
{
  "query": { "match_all": {} }
}

A No documents will be returned because the query is overridden.

B All documents will be returned because the query matches all.

C Only documents where <code>status</code> is <code>published</code> will be returned.

D Documents with any <code>status</code> except <code>published</code> will be returned.

💡 Hint

Document level security filters documents based on the query in the role.

The role's document level security query restricts access to only documents where status is published, so only those documents appear in results.

🔧 Debug

advanced

Why does this role not restrict access to the salary field as expected?

A role is defined to deny access to the salary field using except in field level security, but users still see the salary field in search results. What is the likely cause?

Elasticsearch

{
  "indices": [
    {
      "names": ["employees"],
      "privileges": ["read"],
      "field_security": {
        "except": ["salary"]
      }
    }
  ]
}

A The <code>except</code> parameter is not supported; only <code>grant</code> works for field security.

B The <code>salary</code> field is misspelled in the <code>except</code> list.

C The role must also include a document level security query to hide <code>salary</code>.

D The <code>except</code> parameter requires a wildcard pattern, not a field name.

💡 Hint

Check the official Elasticsearch documentation for supported field security parameters.

Elasticsearch field level security supports only the grant parameter to specify allowed fields. The except parameter is not valid, so it is ignored and all fields are returned.

📝 Syntax

advanced

Which role definition syntax correctly applies document level security to only show documents with department equal to sales?

Choose the correct JSON snippet for the role's indices section to enforce this document level security.

A

{
  "names": ["employees"],
  "privileges": ["read"],
  "document_level_security": {
    "term": { "department": "sales" }
  }
}

B

{
  "names": ["employees"],
  "privileges": ["read"],
  "query": {
    "term": { "department": "sales" }
  }
}

C

{
  "names": ["employees"],
  "privileges": ["read"],
  "filter": {
    "term": { "department": "sales" }
  }
}

D

{
  "names": ["employees"],
  "privileges": ["read"],
  "query": {
    "match": { "department": "sales" }
  }
}

💡 Hint

Document level security uses the query field inside the indices section.

The correct syntax uses the query key with a valid Elasticsearch query. Option B uses term query correctly. Option B uses an invalid key. Option B uses an unsupported key. Option B uses match which is valid but less precise than term for exact matches.

🚀 Application

expert

How to combine field and document level security to restrict access to salary field and only active employees?

You want to create a role that: - Allows reading only name and position fields (hide salary) - Shows only documents where status is active Which role definition correctly implements both restrictions?

A

{
  "indices": [
    {
      "names": ["employees"],
      "privileges": ["read"],
      "field_security": { "grant": ["name", "position"] },
      "query": { "term": { "status": "active" } }
    }
  ]
}

B

{
  "indices": [
    {
      "names": ["employees"],
      "privileges": ["read"],
      "field_security": { "grant": ["name", "position", "salary"] },
      "query": { "term": { "status": "active" } }
    }
  ]
}

C

{
  "indices": [
    {
      "names": ["employees"],
      "privileges": ["read"],
      "field_security": { "except": ["salary"] },
      "query": { "match": { "status": "active" } }
    }
  ]
}

D

{
  "indices": [
    {
      "names": ["employees"],
      "privileges": ["read"],
      "field_security": { "grant": ["name", "position"] },
      "query": { "term": { "status": "inactive" } }
    }
  ]
}

💡 Hint

Use grant for allowed fields and query for document filtering.

Option A correctly grants only name and position fields and filters documents with status equal to active. Option A uses unsupported except. Option A grants salary which should be hidden. Option A filters for inactive status, which is incorrect.

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