Turn Chapter 19 into a concrete AtlasMart threat model that reduces credential blast radius, proves forbidden actions fail, protects snapshots and expensive query surfaces, and defines incident-response evidence.
Threat-Model an Elastic Deployment for Anonymous Exposure, Over-Privileged APIs, Snapshot Theft, and Query Abuse
Design equivalent AtlasMart retention intent in Elastic and OpenSearch while documenting non-equivalent lifecycle, tiering, policy-update, simulation, and managed-service behavior.
Learning outcomes
Security design is complete only when AtlasMart can name its assets, attackers, trust boundaries, abuse paths and observable controls. This final lesson tests four realistic paths: public/anonymous exposure, over-privileged application credentials, snapshot theft, and expensive query abuse. Each path ends with a control and evidence—not merely a recommendation.
Construct an AtlasMart threat model that links assets, trust boundaries, attack paths and measurable controls.
Prove network/TLS/auth controls prevent anonymous or certificate-bypass access from becoming normal application behavior.
Reduce credential blast radius with separate roles, expiring API keys, rotation and forbidden-operation tests.
Protect snapshot repositories and query surfaces as first-class security assets rather than secondary operations details.
Produce an incident-response/security acceptance checklist that remains useful after deployment changes.
Examples target the official self-managed
Elasticsearch 9.5.3 / Kibana 9.5.3
distribution, reviewed 11 September 2026. The lab reuses
atlasmart-es at
https://localhost:9200, the generated HTTP CA
copied earlier as atlasmart-es-http-ca, and
ELASTIC_PASSWORD only as a bootstrap
administrator credential. Use curl --cacert;
never teach -k as an Elasticsearch security
shortcut. The official distribution includes a bundled OpenJDK
and Elastic recommends using it; no external JVM is required
by this lab. Kibana examples assume 9.5.3 when UI behavior
matters. OpenSearch 3.8.0 is mentioned only to mark
non-portable boundaries; Chapter 20 teaches its Security
plugin separately.
A control without evidence is an assumption. Every high-risk AtlasMart path below has an observable acceptance test: TLS verification, 401/403 behavior, privilege inspection, key invalidation, repository authorization, rate/admission controls, or audit/proxy/application evidence.
The generation environment does not run the AtlasMart Docker cluster, so requests are deterministic lab instructions and response fragments are expected shapes/invariants, not fabricated captures. Record your own certificate fingerprints/expiry, 401/403 evidence, key identifiers/expiration, audit events where licensed, and application p95/p99 latency under authenticated load.
1. Build the model: assets, actors and trust boundaries
| Asset / boundary | Threat | Minimum evidence |
|---|---|---|
| Elasticsearch HTTP endpoint | Internet/public exposure or TLS interception | Network policy + CA-verified TLS + anonymous request fails |
| Search/ingest credentials | Secret theft or privilege escalation | Separate scoped principals/keys; forbidden operations 403; rotation drill |
| Security configuration | Unauthorized role/user/key changes | Restricted manage_security; config review; audit/change evidence where available |
| Snapshot repository | Offline data theft, deletion or ransomware | Separate repository IAM/credentials, encryption/immutability where supported, restore drill |
| Query surface | Wildcard/regex/script/deep-pagination resource abuse | Query constraints, client budgets, backpressure/breakers, p95/p99 and rejection evidence |
| Kibana | UI exposure/session or space confusion | Kibana auth + feature/space roles plus independent Elasticsearch index RBAC |
2. Scenario A — anonymous or public Elasticsearch
The wrong design exposes port 9200 beyond intended networks and assumes an obscure URL is enough. The repaired design layers network controls, HTTPS, valid certificate trust, authentication and least privilege.
# No Authorization header. Expected: 401 on a secured self-managed cluster.
curl --cacert "$ES_CA" -i "$ES_URL/atlasmart-products-secure-v1/_search?size=0"
# Authenticated least-privilege key. Expected: 200 for search.
curl --cacert "$ES_CA" \
-H "Authorization: ApiKey $ATLASMART_API_KEY" \
"$ES_URL/atlasmart-products-secure-v1/_search?size=0"
Do not interpret “401 from the public Internet” as safe architecture. The endpoint should normally be unreachable except through intended network/proxy boundaries.
3. Scenario B — one broad credential for every service
A leaked superuser password turns a search-frontend bug into total cluster compromise. Split identity by service and environment. Give search only read/metadata, ingest only required writes, and security administration to a controlled operator/automation identity. Prefer short-lived API keys for runtime services, then practice rotation.
principal,operation,expected
atlasmart-search,search products,200
atlasmart-search,delete products index,403
atlasmart-search,create security role,403
atlasmart-ingest,create new product,201
atlasmart-ingest,search products,403
old-api-key-after-rotation,authenticate,401
new-api-key,search products,200
Automate this matrix after role changes. A security release should fail if any forbidden operation becomes allowed.
4. Scenario C — snapshot theft bypasses live-cluster RBAC
Chapter 18 established that snapshot repositories are recovery artifacts outside live shards. They are also data-exfiltration targets. Elasticsearch index roles do not automatically protect raw object-store/filesystem access if an attacker steals repository credentials. Protect repository credentials separately, avoid embedding cloud secrets in repository JSON when secure keystores/managed identities are available, encrypt storage, restrict writers and preserve off-host/immutable recovery copies where risk requires them.
snapshot_repository: atlasmart-production-backups
writer_identity: elastic-snapshot-service
readers:
- approved-dr-role
network_path: private/allowlisted
at_rest_encryption: required
immutability_or_object_lock: evaluate_for_ransomware_boundary
credential_storage: secure-keystore-or-managed-identity
restore_test_frequency: documented-and-measured
security_state_restore: separate approval track
Do not assume a “read-only” Elasticsearch role protects snapshots stored outside Elasticsearch. Repository IAM/filesystem ACLs are a separate trust boundary.
5. Scenario D — authenticated query abuse
Authentication does not make every query cheap. A valid AtlasMart user can accidentally or deliberately submit broad wildcard/regexp queries, scripts, very large aggregations or deep pagination. Chapter 06, 08, 15 and 16 supplied the mechanisms: expensive-query controls, breakers, thread pools/backpressure, pagination limits, profile/slow-log evidence and client concurrency budgets.
search_policy:
max_page_size: 100
deep_paging: "PIT + search_after; no arbitrary large from"
wildcard_regexp: "allowlist fields/patterns; reject leading-unbounded patterns"
script_queries: "not exposed to end-user query language"
timeout: "bounded per endpoint; not assumed to cancel all work instantly"
concurrency: "bounded by client pool; retry with jitter on overload"
aggregation_cardinality: "known dimensions only; cap buckets"
Do not respond to overload by disabling circuit breakers or expanding queues indefinitely. Those protections are safety signals. Security includes availability.
6. Incident response: revoke first, then investigate
When a runtime API key is suspected compromised, issue/validate a replacement if service continuity requires it, invalidate the old key, confirm old-key authentication fails, then inspect access/audit/proxy logs and affected data. If a broad human credential is compromised, rotate it and review all API keys/roles it could have created or modified.
1. Identify credential id/name and owner.
2. Contain network path if active exploitation is suspected.
3. Issue a replacement with equal-or-narrower scope.
4. Canary the replacement and deploy it.
5. Invalidate/delete the compromised credential.
6. Verify old credential returns 401 and forbidden actions remain 403.
7. Review security configuration changes, affected indices and snapshot access.
8. Preserve audit/proxy/application evidence according to retention policy.
9. Rotate adjacent secrets only where dependency analysis justifies it.
10. Record root cause and reduce future issuance/storage blast radius.
7. Security acceptance gate
| Gate | Pass condition |
|---|---|
| TLS | Clients verify the intended CA/hostname; no routine insecure bypass. |
| Authentication | Anonymous requests fail; principal identity is observable. |
| Authorization | Search/ingest roles pass allowed operations and fail forbidden operations. |
| Credential lifecycle | Application key has owner/purpose/expiration and a tested rotation/invalidation procedure. |
| Tenant/data controls | Index-level RBAC always works; DLS/FLS only when licensed/tested, with role-composition review. |
| Kibana | Space/feature permissions and Elasticsearch index permissions are reviewed separately. |
| Backups | Repository credentials/IAM are separate; restore is tested; security/global state is not restored blindly. |
| Availability | Expensive query surfaces and concurrency have bounded policy plus breaker/rejection/latency observability. |
| Auditability | Licensed audit logs or documented proxy/application fallback captures security-relevant events. |
8. Bridge to Chapter 20
Chapter 19 intentionally uses Elastic’s
/_security model, enrollment/bootstrap behavior,
Kibana Spaces, API keys and Elastic subscription boundaries.
Chapter 20 repeats the threat-model objective using OpenSearch
3.8.0’s Security plugin: node/HTTP certificates and
distinguished names, internal users, roles and role mappings,
authentication backends, Dashboards tenants, DLS/FLS and
plugin-specific audit controls. The goal is equivalent least
privilege—not JSON or terminology parity.
Check your understanding
- Why is a 401 from a publicly reachable endpoint not sufficient protection?
- What is the main blast-radius benefit of separate search and ingest credentials?
- Why are snapshot credentials a separate security boundary?
- How can an authenticated user still threaten availability?
- What is the chapter’s final security principle?
Review the answers
1. The endpoint should also be constrained by network boundaries; authentication is one layer, not a substitute for exposure control.
2. Compromise of one service does not automatically grant the other service’s privileges or cluster-wide administration.
3. Raw repository access is outside normal Elasticsearch index authorization and can expose or destroy backup data.
4. Expensive queries, aggregations, scripts or unbounded concurrency can exhaust resources even when authorization is valid.
5. Every important control needs a repeatable observable acceptance test, not just a configuration claim.
Summary and next step
Preserve the evidence, assumptions, version boundaries, and safety checks established in this lesson. Carry them into the next lesson—or, at the end of the capstone, into the production runbook—rather than treating this lesson as an isolated recipe.
References
- Elastic: Secure your cluster — Current security architecture and deployment-type responsibility.
- Elastic: Automatic security setup — First-start TLS, elastic password, and Kibana enrollment-token behavior.
- Elastic: TLS for cluster communications — HTTP versus transport TLS and trust boundaries.
- Elastic: Users and roles — Authentication and RBAC model.
- Elasticsearch privileges reference — Cluster, index, application and run-as privilege semantics.
- Elastic: API key API — Expiration and role-descriptor scoping.
- Elastic: Service accounts — Predefined service accounts and service tokens.
- Elastic: DLS/FLS — Read-oriented document/field restrictions and limitations.
- Elastic: Run as — Delegated request semantics and supported authenticators.
- Elastic: Audit logging — Audit-event configuration and subscription notice.
- Elastic self-managed subscriptions — Current Basic/paid feature boundaries.
- Elastic downloads — Pinned Elasticsearch 9.5.3 release baseline.