Finish the chapter by implementing the same AtlasMart least-privilege intent in OpenSearch and Elasticsearch while documenting the deliberately non-portable TLS, identity, role, tenant/space, DLS/FLS, API-key, audit, and bootstrap mechanisms.
Compare an Equivalent Least-Privilege Application Role in OpenSearch vs Elastic and Document Behavioral Differences
Build least-privilege OpenSearch security with observable identity, authorization, fine-grained read controls, credential lifecycle, and explicit Elasticsearch comparison boundaries.
Learning outcomes
AtlasMart now has two security implementations with the same business goal: a product-search service may read product data but may not modify indices or administer security; an ingest service may write only the intended product index; analysts may see only their tenant’s documents/fields. This final lesson compares the intent rather than pretending OpenSearch and Elasticsearch security APIs are interchangeable.
Express least privilege as product-neutral business permissions before translating to vendor-specific security objects.
Compare OpenSearch Security-plugin roles/mappings/tenants with Elasticsearch roles/realms/Kibana Spaces without claiming API identity.
Compare OpenSearch 3.8 API-key scope/lifecycle with Elasticsearch API keys at the intent level only.
Build a portable security acceptance suite around identity, 2xx/403 behavior, data visibility and credential rotation.
Document migration/managed-service gaps that require explicit redesign rather than JSON translation.
OpenSearch side: 3.8.0 / OpenSearch Dashboards 3.8.0 with the bundled upstream Security plugin. Elastic side: Elasticsearch 9.5.3 / Kibana 9.5.3. Both are separate local clusters. Shared Lucene/search ancestry does not make TLS bootstrap, security APIs, identity backends, tenants/spaces, DLS/FLS licensing, audit controls or machine-credential endpoints portable.
The generation environment does not run the AtlasMart Docker
cluster. Requests below are deterministic lab instructions and
response fragments are expected shapes/invariants, not
fabricated captures. Record your own certificate
DN/fingerprint/expiry, authinfo identity,
role-resolution evidence, 200/403 behavior, tenant visibility,
DLS/FLS results, API-key ID/expiry/revocation, audit events,
and p95/p99 latency under authenticated load.
1. Start with a vendor-neutral security contract
| AtlasMart principal | Must be able to | Must not be able to |
|---|---|---|
| Product search service | Search/get approved product fields | Index/update/delete, manage security, snapshots, cluster settings |
| Product ingest service | Write intended product documents | Read sensitive analytics if unnecessary, manage security or snapshots |
| Tenant-A analyst | Read tenant-A documents and approved fields; view team dashboards | Read other tenants/cost fields; write product data |
| Security administrator | Manage identities/roles/keys under controlled workflow | Run as an embedded application credential |
This table is the portable artifact. Each product implementation should be tested against it. The JSON documents are implementation details.
2. Equivalent intent, different objects
| Intent | OpenSearch 3.8 | Elasticsearch 9.5.3 |
|---|---|---|
| TLS/bootstrap |
Security plugin TLS; node/admin certificate DNs;
security index; securityadmin/REST
|
Secure-by-default first start, HTTP/transport TLS,
enrollment/bootstrap mechanisms;
/_security APIs
|
| Human/service RBAC | Security roles + role mappings + internal/external backend roles | Elasticsearch roles assigned to users/API keys; realms authenticate users |
| UI saved-object boundary | OpenSearch Dashboards tenants | Kibana Spaces and feature privileges |
| Document/field read control | Security-plugin DLS/FLS | Elastic DLS/FLS with subscription/deployment feature boundaries |
| Machine credential |
OpenSearch API keys (3.7+) at
/_plugins/_security/api/apitokens
|
Elasticsearch API keys at Elastic
/_security endpoints; service accounts are
separate Elastic construct
|
| Audit | Security-plugin audit logging, disabled by default upstream | Elasticsearch/Kibana audit logging with Elastic subscription/deployment boundaries |
3. Build one acceptance suite, two adapters
identity:
- authenticated principal is exactly the intended service/user
allow:
- search_service can search atlasmart-products-secure-v1
- ingest_service can perform its documented write operation
deny:
- search_service cannot delete atlasmart-products-secure-v1
- application principals cannot modify security configuration
visibility:
- tenant_a analyst sees only tenant-a documents
- cost_internal is absent from tenant_a analyst reads
credential_lifecycle:
- new machine credential works
- old credential fails after revocation
transport:
- production client validates CA and hostname
The OpenSearch adapter calls
/_plugins/_security/authinfo and plugin APIs. The
Elasticsearch adapter calls
/_security/_authenticate and Elastic security APIs.
Test results are comparable even though endpoints are not.
4. Wrong migration: translate security JSON one-to-one
Copying an Elastic role into
/_plugins/_security/api/roles, or an OpenSearch
role into /_security/role, fails mechanically and
conceptually. Permission names, role mapping, UI tenancy,
authentication backends, API-key behavior and feature
availability differ. The safe migration path is requirement →
effective privilege inventory → target-product role design →
controlled acceptance tests.
Requirement: product frontend may search products only
Source evidence:
identity = ...
allowed endpoints/actions = ...
forbidden endpoints/actions = ...
field/document visibility = ...
Target implementation:
product = OpenSearch 3.8.0 OR Elasticsearch 9.5.3
auth mechanism = ...
roles/mappings = ...
machine credential = ...
Acceptance:
allowed tests pass
forbidden tests return 403
rotation test passes
p95/p99 remains inside measured SLO
5. Managed services add another security dialect
Amazon OpenSearch Service can combine fine-grained access control with AWS IAM/domain policies and provider-managed TLS; Elastic Cloud controls some bootstrap, certificate and operational responsibilities compared with self-managed Elasticsearch. “OpenSearch versus Elastic” is therefore not enough information for a security runbook. Always record distribution, deployment mode and identity/control-plane owner.
6. AtlasMart chapter acceptance drill
- On the disposable OpenSearch cluster, keep the demo admin only for controlled administration; create reader/ingester roles and users or API keys.
-
Insert at least two documents with different
tenant_idvalues and acost_internalfield. - Map a tenant-A reader to DLS/FLS and prove the tenant-B document/cost field are absent from reads.
- Prove the reader cannot delete the index or call Security administration APIs.
- Create a short-lived scoped API key, use it, record its ID/expiry, revoke it and prove it no longer authenticates.
- If audit logging is enabled in the lab, correlate identity and authorization/key events; otherwise state that audit evidence was not executed rather than inventing output.
- Compare the same business contract to Chapter 19’s Elastic implementation and list every non-equivalent mechanism.
The chapter is complete only when the team can show positive and negative authorization evidence and can rotate/revoke machine credentials. A diagram of “RBAC enabled” is not sufficient.
7. Cleanup and rollback
# As the controlled OpenSearch security administrator.
DELETE _plugins/_security/api/rolesmapping/atlasmart_reader
DELETE _plugins/_security/api/internalusers/atlasmart_reader_user
DELETE _plugins/_security/api/roles/atlasmart_reader
DELETE _plugins/_security/api/roles/atlasmart_ingester
DELETE _plugins/_security/api/roles/atlasmart_tenant_a_reader
DELETE _plugins/_security/api/roles/atlasmart_analyst
DELETE _plugins/_security/api/roles/atlasmart_ops_viewer
DELETE _plugins/_security/api/tenants/atlasmart_ops
DELETE atlasmart-products-secure-v1
# Revoke any API key by ID before discarding the token.
DELETE _plugins/_security/api/apitokens/<key-id>
Do not remove shared bootstrap/security resources established by
earlier chapters. If you changed config.yml, audit
settings or TLS files, restore only from your reviewed
backup/change set—not from an untracked old directory.
8. Bridge to Chapter 21
Security is now explicit enough that routine maintenance can be tested without falling back to admin-everywhere. Chapter 21 moves to cluster health, voting/quorum safety, rolling maintenance, upgrades, node replacement and failure recovery. Those workflows must preserve the security plugin, certificate trust, compatible plugins and client behavior at every gate.
Check your understanding
- What is the most portable security artifact between OpenSearch and Elasticsearch?
- Are Dashboards tenants and Kibana Spaces the same API?
- Can you copy DLS/FLS role JSON between products?
- Why include forbidden-operation tests in migration?
- What must a runbook record beyond product name?
Review the answers
1. The business-level allow/deny/data-visibility/credential-lifecycle contract and its acceptance tests.
2. No. They serve related saved-object isolation goals but are product-specific mechanisms.
3. No. Redesign and test against target-product syntax, permissions and feature/licensing boundaries.
4. A migration that preserves allowed calls but accidentally broadens destructive/security access is a security regression.
5. Exact version, distribution, deployment/managed-service mode, identity provider, TLS/control-plane ownership and relevant plugins/features.
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
- OpenSearch 3.8 release/version history — Pinned OpenSearch 3.8.0 release baseline.
- OpenSearch Security overview — Security-plugin architecture, TLS, authentication and authorization overview.
- Configure TLS certificates — Transport/HTTP TLS, node DNs and admin certificate concepts.
- Apply Security configuration safely — Security-index initialization, backup and narrow apply guidance.
- Security APIs — Internal users, roles, mappings, tenants, certificate and related APIs.
- Users and roles — Internal users, roles, role mappings and built-in roles.
- Authentication backends — Authentication flow and chained backend concepts.
- Multi-tenancy — OpenSearch Dashboards tenant mechanics and permissions.
- Document-level security — DLS read filtering and limitations.
- Field-level security — FLS include/exclude semantics and interactions.
- Audit logs — Security audit categories, storage and enablement.
- API keys — OpenSearch 3.7+ scoped API-key lifecycle and limitations.
- OpenSearch downloads/license — Current distribution and Apache-2.0 licensing context.