Elasticsearch "Shield" no longer exists. The paid Shield plugin shipped only for Elasticsearch 1.x–2.x; it was folded into X-Pack Security in version 5.0 (2016), and since Elasticsearch 6.8 / 7.1 (May 2019) the core security features — TLS encryption, native authentication, and role-based access control (RBAC) — are free in the Basic tier with no plugin to install. From Elasticsearch 8.0 (2022) security is on by default: the cluster auto-generates certificates, passwords, and enrollment tokens at first start. So the way to secure a modern cluster is to configure the built-in security stack, not to install Shield.
This guide is the 2026 replacement for the old "install Shield" recipe. For a complementary checklist, see our companion post on Elasticsearch security measures.
Key takeaways
- Do not install Shield. It was renamed X-Pack Security in 2016 and the same controls are now built in and free.
- Security is free. TLS, native-realm authentication, and RBAC are in the Basic (free) tier since ES 6.8 / 7.1.
- Security is on by default in ES 8.x and 9.x — auto-generated certs, an
elasticsuperuser password, and enrollment tokens. - Never expose Elasticsearch to the public internet unauthenticated — that is still the single most common cause of Elasticsearch data breaches.
- OpenSearch is the AWS fork (post-2021 licensing change) and ships its own free security plugin; the controls map closely to Elastic's.
What happened to Shield? The naming timeline
"Shield" is simply an old name. The same capability has been renamed and re-licensed several times, which is why so many tutorials are out of date.
| Era | Elasticsearch version | What you used for security |
|---|---|---|
| 2015–2016 | 1.x – 2.x | Shield (separate paid plugin) |
| 2016 | 5.0 | Renamed X-Pack Security (still paid) |
| May 2019 | 6.8 / 7.1 | Core security made free in the Basic tier |
| 2022 | 8.0 | Security on by default (auto TLS, passwords, enrollment tokens) |
| 2024–2026 | 8.x / 9.x | Built-in security; AWS's OpenSearch fork has its own plugin |
Bottom line: if a tutorial tells you to run bin/plugin -i elasticsearch/shield/latest, it predates 2017 and should be ignored.
How do I set up authentication today?
Elasticsearch ships with built-in users — elastic (superuser) and service accounts such as kibana_system. On ES 8.x the installer prints the elastic password and a Kibana enrollment token once; if you miss it, reset it.
Authentication realms supported out of the box include native (users stored in ES), file, LDAP/Active Directory, SAML, OIDC, and API keys for service-to-service access. Prefer scoped API keys over sharing the elastic password — for example, when wiring up Logstash log parsing as an ingest client.
# ES 8.x/9.x: security is ON by default. Reset the built-in 'elastic' superuser:
bin/elasticsearch-reset-password -u elastic
# Reset the password Kibana uses to talk to Elasticsearch:
bin/elasticsearch-reset-password -u kibana_system
# Generate an enrollment token to attach Kibana or a new node:
bin/elasticsearch-create-enrollment-token -s kibana
bin/elasticsearch-create-enrollment-token -s node
# Create an application user in the native realm via the API:
curl -u elastic -X POST "https://localhost:9200/_security/user/app_reader" \
-H 'Content-Type: application/json' -d '{
"password": "CHANGE_ME_use_a_strong_secret",
"roles": ["reader"],
"full_name": "Read-only service account"
}'How do I enable TLS between Elasticsearch nodes?
There are two TLS layers: transport (xpack.security.transport.ssl) encrypts node-to-node traffic on port 9300, and HTTP (xpack.security.http.ssl) encrypts client traffic on port 9200. Use the bundled elasticsearch-certutil to generate a CA and certificates; on a fresh ES 8.x install this is already done for you.
For public client access, terminate TLS at a reverse proxy with a trusted certificate — see our walkthrough on configuring SSL with Let's Encrypt and Nginx.
# Generate a CA and a node certificate (PKCS#12)
bin/elasticsearch-certutil ca --out config/certs/ca.p12
bin/elasticsearch-certutil cert --ca config/certs/ca.p12 --out config/certs/node.p12
# config/elasticsearch.yml
xpack.security.enabled: true
# Node-to-node (transport) encryption
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: certs/node.p12
xpack.security.transport.ssl.truststore.path: certs/node.p12
# Client (HTTP) encryption
xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.keystore.path: certs/node.p12How does role-based access control (RBAC) work?
Authorization is built from roles (sets of cluster and index privileges), assigned to users directly or via role mappings (e.g. mapping an LDAP/SAML group to a role). For per-row or per-column control, document-level and field-level security are available in the Platinum tier. Issue scoped API keys so each integration gets only the privileges it needs.
# Define a read-only role scoped to one index pattern
curl -u elastic -X PUT "https://localhost:9200/_security/role/reader" \
-H 'Content-Type: application/json' -d '{
"indices": [
{ "names": ["logs-*"], "privileges": ["read", "view_index_metadata"] }
]
}'
# Issue a least-privilege API key instead of sharing the elastic password
curl -u elastic -X POST "https://localhost:9200/_security/api_key" \
-H 'Content-Type: application/json' -d '{
"name": "logstash-ingest",
"role_descriptors": {
"writer": { "indices": [ { "names": ["logs-*"], "privileges": ["create_doc"] } ] }
}
}'What network and operational hardening still matters?
Authentication and TLS are necessary but not sufficient. Bind Elasticsearch to a private interface, firewall ports 9200/9300, store secrets in the keystore instead of plaintext YAML, enable audit logging (Platinum), and keep snapshots for recovery. The table below maps each control to its setting and tier.
| Control | Setting / tool | Tier |
|---|---|---|
| Authentication | native/file/LDAP realms, elasticsearch-reset-password, API keys |
Basic (free) |
| Authorization (RBAC) | roles, role mappings, privileges | Basic (free) |
| Field- & document-level security | role field/query rules | Platinum |
| Transport TLS (node-to-node) | xpack.security.transport.ssl |
Basic (free) |
| HTTP TLS (clients) | xpack.security.http.ssl |
Basic (free) |
| Secrets management | elasticsearch-keystore |
Basic (free) |
| Audit logging | xpack.security.audit.enabled |
Platinum |
| Recovery | snapshot & restore | Basic (free) |
# Store secrets outside elasticsearch.yml (e.g. snapshot repo credentials)
bin/elasticsearch-keystore create
bin/elasticsearch-keystore add s3.client.default.secret_key
# Bind to a private interface only — never 0.0.0.0 on a public host
# config/elasticsearch.yml
network.host: 10.0.1.10
http.port: 9200
# Enable the audit trail (Platinum)
xpack.security.audit.enabled: true
# Firewall: keep HTTP (9200) and transport (9300) off the public internet
sudo ufw allow from 10.0.0.0/16 to any port 9200 proto tcp
sudo ufw deny 9200/tcpWhat about OpenSearch and the licensing changes?
In 2021 Elastic relicensed Elasticsearch from Apache 2.0 to the dual SSPL / Elastic License v2; AWS responded by forking the last Apache-licensed code into OpenSearch, and "Amazon Elasticsearch Service" was renamed Amazon OpenSearch Service. In 2024 Elastic added AGPLv3 as an option, so current Elasticsearch is open source again.
Both stacks ship strong, free security. Elastic's is the built-in stack described above; OpenSearch ships the OpenSearch Security plugin (TLS, an internal user database, RBAC, and fine-grained access control) at no cost. If you run the open-source ELK stack to parse your logs, pick one stack and apply the same principles: TLS everywhere, least-privilege roles, no public exposure.
Frequently Asked Questions
Is Shield still available for Elasticsearch?
No. Shield was discontinued after Elasticsearch 2.x. It was renamed X-Pack Security in 5.0 (2016), and its core features became free and built in from 6.8 / 7.1 (May 2019). There is nothing called "Shield" to install on any supported version.
How do I secure Elasticsearch for free?
Use the Basic (free) tier, which includes TLS encryption, native-realm authentication, and role-based access control. On ES 8.x these are enabled by default; on older 7.x clusters set xpack.security.enabled: true and configure TLS — no paid license required.
What is the difference between Shield, X-Pack Security, and built-in security?
They are the same feature set at three points in time: Shield was the paid 1.x–2.x plugin, X-Pack Security was the 5.x–6.x rebrand, and "built-in security" is the free, no-plugin form from 6.8 / 7.1 onward that is on by default in 8.0+.
How do I enable TLS between Elasticsearch nodes?
Generate a CA and node certificates with elasticsearch-certutil, then set xpack.security.transport.ssl.* for node-to-node traffic and xpack.security.http.ssl.* for client traffic in elasticsearch.yml. A fresh ES 8.x install configures this automatically.
Should I expose Elasticsearch to the public internet?
No. Unauthenticated, internet-exposed Elasticsearch is the classic cause of data breaches. Bind to a private interface, firewall ports 9200 and 9300, require authentication, and place a TLS-terminating reverse proxy in front if external access is genuinely needed.
Does OpenSearch have the same security features as Elasticsearch?
Largely yes. OpenSearch ships the free OpenSearch Security plugin with TLS, an internal user database, RBAC, and fine-grained access control. The concepts mirror Elastic's built-in security, so a hardening checklist for one mostly applies to the other.
Running Elasticsearch or OpenSearch in production and want it locked down, upgraded off an end-of-life version, and monitored? MicroPyramid has secured and maintained search clusters for 50+ projects since 2014. Explore our server maintenance services to keep your cluster patched, encrypted, and breach-resistant.