ElasticSearch Risk Assessment & Management 5 — Questions and Answers
Question 1: Which Elasticsearch configuration change reduces the risk of cluster-wide disruption when a single node runs out of disk space?
- Setting cluster.routing.allocation.disk.watermark.low and high thresholds (Correct answer)
- Increasing the number of primary shards for all indices
- Enabling shard rebalancing on disk watermark breach
- Setting index.blocks.read_only to false on all indices
Correct answer: Setting cluster.routing.allocation.disk.watermark.low and high thresholds
Disk watermark thresholds trigger shard relocation before a node reaches full capacity, preventing allocation failures and index lockout.
Question 2: A penetration tester discovers that Elasticsearch's REST API responds to unauthenticated DELETE requests on /_all. What is the severity of this finding?
- Critical — all indices and their data can be permanently deleted in a single request (Correct answer)
- Medium — DELETE on /_all only removes index aliases, not data
- Low — the action is logged and can be reversed via ILM
- Informational — /_all deletion requires a follow-up reindex to take effect
Correct answer: Critical — all indices and their data can be permanently deleted in a single request
An unauthenticated DELETE /_all wipes every index in the cluster instantly, representing a critical data destruction vulnerability.
Question 3: Which risk does enabling Elasticsearch's 'allow_unsafe_bootstrapping' flag introduce in a new cluster setup?
- It bypasses quorum checks, allowing a single node to form a cluster independently, which can cause data divergence if other nodes rejoin (Correct answer)
- It permits nodes to join without valid TLS certificates
- It disables all write operations until a master is elected
- It sets the cluster to read-only mode permanently
Correct answer: It bypasses quorum checks, allowing a single node to form a cluster independently, which can cause data divergence if other nodes rejoin
Unsafe bootstrapping overrides consensus safety guarantees; if used carelessly, it can create a split-brain condition when the rest of the cluster is rejoined.
Question 4: What Elasticsearch security risk is introduced by running Kibana with an elasticsearch.username that has cluster:admin privileges?
- A Kibana exploit or misconfiguration can be leveraged to perform cluster-wide admin actions (Correct answer)
- Kibana session cookies are visible in Elasticsearch audit logs
- Users logged into Kibana automatically inherit cluster:admin in Elasticsearch
- Kibana cannot display visualizations with restricted API tokens
Correct answer: A Kibana exploit or misconfiguration can be leveraged to perform cluster-wide admin actions
Kibana's service account should use least-privilege credentials; over-privileged service accounts expand the impact of any Kibana-level compromise.
Question 5: Which Elasticsearch index setting, if left at its default, increases the risk of excessive memory use during large sort operations?
- indices.fielddata.cache.size defaulting to unbounded (Correct answer)
- index.max_docvalue_fields_search defaulting to 100
- index.refresh_interval defaulting to 1s
- index.number_of_replicas defaulting to 1
Correct answer: indices.fielddata.cache.size defaulting to unbounded
Without an explicit fielddata cache size limit, sort and aggregation operations can fill available heap and trigger JVM garbage collection pressure or OOM errors.
Question 6: A compliance audit requires demonstrating that no Elasticsearch data leaves a specific geographic region. Which feature best supports this requirement?
- Shard allocation awareness with zone/region attributes and allocation filtering (Correct answer)
- Cross-cluster replication with a geo-restricted follower
- Index-level aliases scoped to regional ingest pipelines
- ILM policies with region-specific rollover conditions
Correct answer: Shard allocation awareness with zone/region attributes and allocation filtering
Allocation awareness lets you tag nodes by region and then restrict shard placement to those nodes, keeping data within the required geographic boundary.
Question 7: What is the risk of setting action.destructive_requires_name: false in elasticsearch.yml?
- Wildcard patterns like DELETE /logs-* or DELETE /_all are permitted, enabling accidental or malicious mass deletion (Correct answer)
- Nodes can be decommissioned without explicitly naming them in allocation exclusions
- Index templates are applied without requiring a name match pattern
- Snapshot restore operations bypass the index name confirmation step
Correct answer: Wildcard patterns like DELETE /logs-* or DELETE /_all are permitted, enabling accidental or malicious mass deletion
Without this safeguard, a single wildcard DELETE request can remove many indices simultaneously, greatly increasing the blast radius of human error or attack.
ElasticSearch Risk Assessment & Management 5
Which Elasticsearch configuration change reduces the risk of cluster-wide disruption when a single node runs out of disk space?