Skip to content
Maxuru

Elasticsearch audit logging needs a paid license

Severity: lowApplies to: Elasticsearch 8.x / 9.x (Basic tier)Applies to: Elasticsearch 7.x
The fix/etc/elasticsearch/elasticsearch.yml
# Requires a Platinum/Enterprise subscription — will not work on Basic:
# xpack.security.audit.enabled: true


# What Basic actually gives you: the standard node log.
# Raise logging on the security package to see authentication events:
Terminal window
curl -sk -u elastic -X PUT https://localhost:9200/_cluster/settings \
  -H 'Content-Type: application/json' \
  -d '{"persistent":{"logger.org.elasticsearch.xpack.security.authc":"DEBUG"}}'

The thing to know first

Section titled “The thing to know first”

Security audit logging is a subscription feature. xpack.security.audit.enabled requires a Platinum or Enterprise license — it is not in the free Basic tier that gives you authentication, RBAC and TLS.

This matters because “enable audit logging” appears on essentially every Elasticsearch hardening checklist, usually without noting that it’s paid. On a Basic-tier cluster, setting xpack.security.audit.enabled: true does not produce an audit trail — the feature is licence-gated, and you’ll get a licence error or silence, not logs.

So unlike the rest of this checklist — all of which works on the free tier — this one is a purchasing decision. Knowing that now is cheaper than discovering it during an audit when you assumed the trail existed.

The clean distinction: everything that prevents an incident (auth, TLS, binding, RBAC) is free. The feature that records one is paid. That’s a defensible split, but it means the free-tier answer to “who accessed this index last Tuesday” is “we don’t fully know.”

What Basic gives you instead

Section titled “What Basic gives you instead”

Less than an audit log, and not nothing.

Authentication events in the node log. By raising the log level on the security authentication package (the PUT above), successful and failed logins appear in /var/log/elasticsearch/<cluster>.log. It’s noisier and less structured than the audit log, and it captures authentication rather than data access — but during an incident it answers “who logged in, and what failed” which is the question you most often have.

Set it back when you’re done; DEBUG on that logger is verbose:

Terminal window
curl -sk -u elastic -X PUT https://localhost:9200/_cluster/settings \
  -H 'Content-Type: application/json' \
  -d '{"persistent":{"logger.org.elasticsearch.xpack.security.authc":null}}'

The slow log, if you already run it, incidentally records queries above a threshold — not a security tool, but it can show unexpected access patterns.

OpenSearch is different here. If you’re on the AWS fork, audit logging is in the open-source security plugin at no cost — it’s one of the places the fork’s Apache-2.0 licensing gives you a feature Elastic charges for. If audit logging is a hard requirement and you’re not committed to Elastic’s stack, that’s a real factor.

Why this is low

Section titled “Why this is low”

It closes no exposure. Nothing on this page makes an attack harder — it changes what you can reconstruct afterwards, and on Basic it changes it only partially. That’s real value during an incident and zero value before one, which is what low means, and it’s why every preventive control on this checklist ranks above it.

Section titled “Related”