Document/Field-Level Security, Run-As, Audit Logging, and Subscription/Feature Awareness

Learning outcomes

AtlasMart now has narrow index roles and expiring API keys, but two tenants share the same physical product index. One design hides tenant B’s dashboards in Kibana and assumes tenant A cannot query tenant B’s documents directly. Another adds DLS but gives the same user an unrestricted second role. This lesson shows why fine-grained data security needs careful role composition, read-only semantics and license-aware fallbacks.

1. DLS filters documents; FLS filters fields

Document-level security (DLS) attaches a query to an index-permission entry so read requests see only matching documents. Field-level security (FLS) grants/denies fields for document-based reads. They compose with ordinary index privileges: neither creates a new authentication mechanism.

PUT /_security/role/atlasmart_tenant_a_dls_role
{
  "indices": [
    {
      "names": ["atlasmart-products-secure-v1"],
      "privileges": ["read", "view_index_metadata"],
      "query": {"term": {"tenant_id": "tenant-a"}},
      "field_security": {
        "grant": ["sku", "name", "category", "tenant_id", "price", "updated_at"]
      }
    }
  ]
}

The internal cost_internal field is absent from the grant list, and tenant B documents fail the DLS query. Verify the current subscription before executing this in self-managed production.

2. Test with documents that can reveal mistakes

POST atlasmart-products-secure-v1/_bulk?refresh=true
{"index":{"_id":"TENANT-A-1"}}
{"sku":"A-1","name":"Tenant A Keyboard","category":"office","tenant_id":"tenant-a","price":100.00,"cost_internal":60.00,"updated_at":"2026-09-11T14:40:00Z"}
{"index":{"_id":"TENANT-B-1"}}
{"sku":"B-1","name":"Tenant B Keyboard","category":"office","tenant_id":"tenant-b","price":120.00,"cost_internal":70.00,"updated_at":"2026-09-11T14:40:00Z"}

GET atlasmart-products-secure-v1/_search
{
  "query": {"match_all": {}},
  "sort": ["sku"]
}

# Expected under the DLS/FLS role:
# - TENANT-A-1 may be returned
# - TENANT-B-1 is not returned
# - cost_internal is not exposed in _source fields permitted by FLS

3. Multiple roles are an OR/union hazard

DLS queries across applicable roles are combined in a way that can widen access; a second role granting the same index without DLS can remove the document restriction. FLS grants are likewise combined across roles. Therefore “tenant role + general read role” is dangerous unless the effective combination is intentionally reviewed.

4. Basic/free fallback: make the security boundary physical

If DLS/FLS is unavailable or operationally inappropriate, separate sensitive tenants/data into different indices (or different clusters when risk warrants), then grant ordinary index-level RBAC. AtlasMart can use atlasmart-products-tenant-a-v1 and atlasmart-products-tenant-b-v1. This consumes more operational resources but makes the authorization boundary visible to Basic RBAC and avoids relying on a paid fine-grained feature.

PUT /_security/role/atlasmart_tenant_a_basic_role
{
  "indices": [
    {
      "names": ["atlasmart-products-tenant-a-v1"],
      "privileges": ["read", "view_index_metadata"]
    }
  ]
}

For field secrecy under Basic, do not index highly sensitive fields into the tenant-visible index; transform/project data into an appropriately exposed index upstream. Security-by-schema is often simpler to audit than “all fields exist but application promises not to request them.”

5. Run-as is delegated authorization, not role merging

Elasticsearch run_as lets an authenticated identity submit a request as another user when its role explicitly permits that username and the authentication/lookup realms support delegation. When run-as is used, Elasticsearch evaluates the impersonated user’s roles rather than merging them with the caller’s ordinary roles. API keys can participate as authenticating credentials; service tokens and several token/SSO mechanisms have different run-as support, so check the current documentation.

PUT /_security/role/atlasmart_gateway_runas_role
{
  "cluster": [],
  "indices": [],
  "run_as": ["atlasmart_tenant_a_reader"]
}

# Request header used by an authorized gateway principal:
# es-security-runas-user: atlasmart_tenant_a_reader

Run-as is useful when a trusted gateway authenticates users externally, but it increases the gateway’s blast radius. Restrict the run-as user pattern tightly, audit it where available, and never allow wildcard impersonation casually.

6. Audit logging answers “what happened?”—if available and enabled

Elasticsearch audit logging can record authentication failures, access denials and security-configuration changes. It is not automatically equivalent to application business audit. Availability is subscription-sensitive and configuration differs by deployment type. Build detections for repeated 401/403 bursts, security-role changes, API-key lifecycle changes and suspicious run-as use.

events_expected:
  - authentication_failed for intentionally bad lab credential
  - access_denied for forbidden delete attempt
  - security_config_change for role/API-key lifecycle where configured
fields_to_preserve:
  - timestamp
  - authenticated user / API-key identity
  - run-as user when present
  - action / request path
  - originating address or proxy identity as trustworthy in your topology
retention:
  - separate from application data retention when compliance requires it

Where audit logging is not licensed, retain reverse-proxy/API-gateway access logs, application authorization decisions and security-configuration change records as a fallback. That is not feature-equivalent, so document the evidence gap.

7. Production judgment

Fine-grained access controls consume CPU/cache and complicate query behavior. DLS can affect profiling and leak aggregate/statistical information under documented limitations. Measure representative queries and understand what metadata/statistics remain visible. When tenant isolation is a hard security boundary, physical separation can be safer than composing many roles and filters.

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.