OpenSearch security hardening guide for self-hosted clusters

Why OpenSearch security hardening starts before the first index is loaded

The right time to harden an OpenSearch cluster is before it holds anything you would not want exposed. Once logs, customer records or security events are indexed, every later change to TLS, roles and audit settings has to be made against live data, live clients and live dashboards. A cluster that is about to receive production data needs its access model decided first, then the indices and ingestion pipelines built on top of it.

The OpenSearch Security plugin supplies the controls you will design together: TLS for node-to-node transport and for client traffic, role-based access control, document-level and field-level security, field masking, user impersonation and audit logs. These controls depend on each other. A role that restricts documents by a query means little if the same user can reach the REST API directly, impersonate a more privileged account, or read a field that should be masked. Decide the set of roles, the data each role may see, and the paths by which that data can be reached in one design pass, then write the configuration from that design.

Several things make this harder than it looks. A fresh installation carries default configuration that must be replaced, not merely tuned. Access arrives through several interfaces: the REST API, OpenSearch Dashboards, the node-to-node transport layer and any ingestion agents or client libraries, and each needs its own certificate, authentication and authorization path. The largest effort is usually the mapping work: existing identities in directories and applications must be matched to backend roles, and existing data must be classified so that each index and field has an owner and an access rule. Ask whether your security team has a current data classification for the logs or events you plan to store, and who approves role membership.

DeployOpen plans and implements this hardening inside your own infrastructure, whether that is your cloud accounts, data centers or an air-gapped network, so the keys, certificates and audit trails stay under your control. Before scoping work, confirm the OpenSearch version you will run, the authentication backend your identity team will support, the data classes and retention rules that apply, and which systems will write to the cluster. Those answers determine how many roles, certificates and test cases the build needs.

A practical first step is to write down, for each planned index, who reads it, who writes to it, which fields are sensitive and whether audit records must be kept for those actions. Review that list with the compliance owner before any ingestion is enabled. DeployOpen can prepare the role design, configuration and evidence for that review, but the decisions on data ownership and access remain with your organization, and independent auditors or certification bodies assess any compliance outcome.

Which Security plugin components need hardening

The OpenSearch Security plugin controls how nodes talk to each other, how clients connect, who can read which data and what gets recorded. A gap in any one of these components can undo the controls around the others, so each one needs an explicit check rather than trust in the defaults. The cards below walk through the components a hardening review should cover and what to verify in each.

Node-to-node transport TLS

Transport TLS encrypts and authenticates traffic between cluster nodes, including replication, shard recovery and cluster manager coordination. Without it, anyone with network reach to the cluster network can read indexed data in transit or inject traffic that a node may accept. Check that every node presents a certificate issued by the expected authority, that hostname verification is enabled and that no node is left on an unencrypted listener during rollout. Confirm the exact settings for your release in the Security plugin documentation.

REST layer client TLS

REST TLS protects the HTTP interface that applications, Dashboards, ingestion agents and administrators use to send queries and documents. A plaintext REST endpoint exposes credentials and query content to anyone on the path, and it can let clients skip certificate checks if they are configured to trust any server. Verify that the HTTP listener requires TLS, that clients validate the server certificate against your internal authority and that certificate rotation has an owner and a procedure.

Security index and configuration files

The security index stores the live security configuration, while the YAML files under the config directory define the initial state that is loaded into it. Edits made to files on one node do not reach the others unless the configuration is applied through the supported tooling, so drift between nodes is a common gap. Restrict filesystem access to these files, track changes in version control and confirm which copy is authoritative before a change is made.

Roles and role mappings

Roles define which indices, actions and document or field restrictions a user can access, and role mappings connect identities from an external backend to those roles. Broad roles such as all-access granted to service accounts, or mappings that match on wide group names, are the most frequent sources of excess privilege. Review each role against a named workload, remove wildcard index patterns where a list works, and test mappings with an identity from each backend before go-live.

Tenants and internal users

Tenants separate saved objects such as Dashboards visualizations and index patterns between groups, and internal users hold credentials stored in the security configuration. Shared tenants can expose saved queries or sensitive field names to people outside the owning team, and leftover internal accounts with default or weak passwords give attackers a login that bypasses the external identity provider. Disable or rotate built-in accounts, assign each internal user an owner and review tenant membership on the same schedule as role reviews.

Audit logging

The audit log records authentication events, failed logins and, depending on configuration, read and write activity, which is the evidence base for investigating misuse and for compliance assessments. If auditing is off, or it records to a location the cluster administrators can edit, you lose the ability to show who accessed what. Decide which categories to capture, where the log is stored and forwarded, who can read it and how long it is retained, and test that a deliberate failed login appears in the output.

Which authentication, TLS and role model fits your environment

This table compares the authentication backend, certificate source, role granularity and audit log scope choices available with the OpenSearch Security plugin. Read each row against your identity provider, PKI and access model, then check the operational cost before you commit. The main takeaway is that your identity estate usually decides the backend, while document-level security and certificate rotation add ongoing work you should plan for at the start.

Choice	When it fits	Operational cost to plan for
SAML	Corporate identity provider issues assertions and users sign in to Dashboards through the browser	IdP metadata and signing certificate changes must be coordinated; an IdP outage blocks all Dashboards logins
OpenID Connect	Modern identity provider or cloud directory with OpenID Connect clients already in use	Client secret and redirect URI management; key and token rotation depends on IdP change control
Active Directory and LDAP	Users and groups live in Active Directory or LDAP, and roles follow directory groups	Bind account credentials need rotation; directory latency and lookups affect every login and role mapping
Kerberos	Windows domain estate where Kerberos single sign-on is already the standard	Service principals, keytab rotation and clock synchronization across nodes and domain controllers
JSON Web Token	An upstream gateway already issues signed tokens for API and Dashboards access	Signing key rotation, issuer and audience validation, and token lifetime settings must be maintained
Internal users	Small or isolated clusters, or a break-glass admin account alongside a central backend	Passwords and access reviews are manual; offboarding depends on someone removing accounts
Internal CA or corporate PKI	Internal CA suits isolated networks and lab clusters; corporate PKI fits enterprise trust and audit policy	An internal CA means you own root protection, renewal and revocation; corporate PKI needs an agreed request process
Index-level or document and field-level roles	Index-level roles fit simple tenancy; document and field-level security fits mixed-sensitivity data	Document-level security adds query overhead and makes role design, testing and review more involved
Audit log scope	Compliance-driven teams need defined event categories and retention; minimal scope suits small clusters	Broader scope increases log volume, index storage and review effort; scope must match agreed retention

Hardening OpenSearch in the order the Security plugin expects

This sequence hardens an OpenSearch cluster in the order the Security plugin depends on: inventory first, then certificates, TLS, identity, roles, data-level controls, auditing and API restrictions. Each step closes with a check the team can repeat, so the finished baseline can be verified.

Inventory data classes and clients
The security team and the platform owner list every index family, the data classes it holds, and each application, dashboard, shipper and person that reaches the cluster, noting whether each one reads, writes or administers it. This inventory decides which roles, document filters and masked fields are needed later, so nothing is designed from guesswork. Confirm with the data owners which fields carry personal or regulated data. The step is done when each client has a named owner, an access purpose and a list of indices, signed off before any configuration starts.
Plan certificates and node names
Define the certificate authority, certificate lifetimes, the renewal process, and the node names and Subject Alternative Names each certificate must carry. Keep the transport certificates used between nodes separate from the REST certificates that clients see, and record which admin certificate will manage the security configuration. Ask your certificate authority team which key lengths and CA setup meet your policy, and confirm the expected certificate fields against the docs for the version you run. The step is done when a written certificate map lists every node, hostname and certificate file, and a test issuance succeeds.
Enable transport and REST TLS
Configure TLS on the node-to-node transport layer first, then on the REST layer that clients use, and turn on certificate verification so peers must present a certificate signed by the trusted CA. Keep the security settings consistent across all nodes and restart them in the order your deployment method documents. Check that a TLS handshake succeeds with the expected certificate chain and host name, and that a plain HTTP request to the REST port is refused. The step is done when every node joins the cluster over TLS and the REST endpoint presents the expected certificate.
Configure the authentication backend
Connect the Security plugin to the identity source your organization already runs, such as SAML, OpenID Connect, Active Directory, LDAP, Kerberos or JSON Web Tokens, using only the backends supported in your version. Keep the initial admin account for break-glass use with its credentials held in a vault, and disable any local accounts you do not need. Agree with the identity team which directory attributes carry group membership. The step is done when a directory test user authenticates successfully and a login with a wrong password is rejected.
Define roles and role mappings
Create security roles that grant the smallest set of cluster and index permissions each inventory entry needs, then map backend groups or users to those roles. Keep dashboard reader roles separate from ingestion writer roles, and keep administrative roles to a short, named list. Use named indices or aliases instead of wildcard patterns wherever the inventory allows it. The step is done when a user with a reader role can query its own indices, and the same user receives a denied response for an out-of-scope index.
Add document, field-level and masking rules
Apply document-level security queries and field-level security only where the inventory marked records or fields as restricted, and use field masking for values that some users may see only in masked form. Test each rule with users from different groups, and review query performance on large indices in your target environment, since filters can add load. Record which roles see which fields. The step is done when a restricted user's search returns only permitted documents, a masked field returns the masked value, and a hidden field returns no value.
Enable audit logging with filters
Turn on audit logging for the Security plugin and choose which categories to record, such as failed logins, granted and denied requests, and changes to security configuration. Decide where audit events are stored, who can read them, and keep that store separate from the indices users search. Confirm the category names and storage options against the docs for your version. The step is done when a deliberately failed login creates an audit entry, a denied request is logged, and a role change appears in the audit trail.
Lock down the REST API and endpoints
Restrict REST access to the networks and clients listed in the inventory, disable or limit the endpoints and features the deployment does not use, and confirm that cluster-level administrative calls require the admin certificate. Review the settings that control which endpoints are exposed and which can be changed at runtime, and confirm each one against the docs for your version. Test from both permitted and unpermitted networks. The step is done when requests from unlisted networks are refused, unused endpoints return a denied or not-found response, and the baseline is saved as a reviewed configuration record for future upgrades.

Least-privilege roles, field masking and REST API lockdown

The Security plugin decides who can read which indices, documents and fields, and who can change the cluster itself. The cards below cover the access controls that matter most, from role design and field masking to locking down administrative paths and keeping secrets out of configuration repositories.

Role design by team and data class

Define security roles around what each team needs to do and which data class it touches, rather than around individual users. Map backend roles from the identity provider to these security roles so access follows directory group membership and is removed when someone leaves a team. Check that every role grants index patterns narrowly and that no team inherits broad read access to logs or records it does not own.

Backend roles from the identity provider

Backend roles carry group membership from SAML, OpenID Connect, LDAP or Active Directory into the Security plugin, where they are mapped to security roles. Confirm which claim or attribute carries group data in your identity provider, and test the mapping with a user from each group before rollout. Review the mapping whenever groups change, because stale mappings are a common source of excess access.

Field masking for sensitive fields

Field masking lets a role see a document while sensitive fields return a hashed or obscured value. Identify fields such as account identifiers, personal data and secrets that appear in logs or indexed records, then decide which roles may see them in clear form. Test masking with queries, aggregations and dashboards, since a field that is masked in search results may still be exposed through other views.

User impersonation limits

Impersonation allows one identity to act as another, which is useful for troubleshooting but a strong privilege in its own right. Restrict impersonation to a small set of named operators, log every use, and confirm that impersonated sessions do not carry rights beyond what the target user holds. Review the list of permitted impersonators during each access review.

Securing the admin certificate and security index

The admin certificate and the security configuration index control the Security plugin itself, so they need the tightest handling in the cluster. Keep the admin certificate private key out of shared storage, restrict who can apply security configuration changes, and confirm that the security index is not readable through ordinary roles. Record each change to the security configuration so it can be traced during an incident.

Restricting administrative REST paths

Administrative REST paths, including those under the security and cluster APIs, should accept connections only from a management network or bastion. Enforce this at the network layer and, where the platform allows, in the proxy or load balancer in front of the cluster. Test each path from an allowed and a disallowed source, and confirm that Dashboards and application clients cannot reach the same administrative endpoints.

Broad operations access versus separation of duties

Operations teams need enough access to restart nodes, reindex data and fix broken indices during an incident, but broad admin rights let one person change security settings and read every index. Decide which duties are split, for example security configuration held by a separate group from cluster operations, and document the break-glass procedure for emergencies. Review the balance with your auditors before finalizing roles, since they will ask how the split is enforced.

Keeping secrets out of configuration repositories

Keystore passwords, TLS private keys and admin credentials should never be committed to configuration repositories or written into templates in plain text. Store them in a secrets manager or the OpenSearch keystore, inject them at deploy time, and rotate them on a schedule and after any staff change. Scan repositories for accidental commits and confirm that backups and snapshots do not contain key material.

How single node, high availability and Kubernetes change the hardening work

A single node or development cluster is the simplest place to see the Security plugin working, but it is also where shortcuts tend to survive into production. There is no peer-to-peer trust to establish between nodes, so the work centers on the HTTP layer, the admin certificate and the initial security configuration. The risk is that a demo setup with generated certificates and default settings gets promoted without review.

What changes and what to check:

Certificate distribution: one node certificate often serves both transport and REST traffic, so confirm whether the subject names match the hostname clients actually use.
Node naming: a single node name is easy to forget, but the node name and cluster name still appear in logs and must be set deliberately.
Transport trust: with one node there is no inter-node transport traffic, yet the transport certificate settings should still be in place so that adding nodes later does not reopen the design.
Identity reachability: if the single node is meant to use SAML or OpenID Connect, confirm the identity provider can reach it, since local users are often the only path during development.
Configuration location: the security configuration is applied through the security configuration files and the security admin tool on the node itself, so record exactly where those files live and who can change them.

Before promoting a single node to any shared use, confirm that default demonstration credentials are gone, the admin certificate is restricted to a named operator group, and the configuration is version controlled.

What drives OpenSearch security hardening effort and how to keep it down

This table lists the factors that move OpenSearch security hardening effort, how each one raises the workload, and a practical way to keep it contained. Read it before scoping a rollout so the choices that multiply work, such as per-cluster configuration and field-level rules, are made deliberately. The main takeaway is that most effort comes from repetition across clusters, identities and data classes, so standard templates and shared patterns lower it the most.

Driver	Why it raises effort	How to keep it down
Number of clusters and environments	Each cluster needs its own TLS setup, security configuration, roles and audit settings, and each environment adds a separate test pass.	Define one hardened baseline as code and apply it to every cluster, changing only environment values such as hostnames and identity endpoints.
Identity sources and role groups	Each authentication backend (SAML, OpenID Connect, LDAP or Active Directory, Kerberos, JSON Web Token) needs mapping rules, and every group needs a backend role mapped to a security role.	Use a single primary identity provider where possible and keep a short, named list of standard role templates rather than one role per team.
Data classes needing document or field-level controls	Document-level and field-level security rules must be written, tested against real query patterns and reviewed whenever index mappings change.	Confine field-level rules and field masking to a small set of indices holding the sensitive data, and keep other indices on index-level permissions.
Dashboards tenants	Each tenant has its own saved objects and sharing rules, so the number of tenants multiplies permission mapping and review work.	Limit tenants to a few shared spaces for common teams, and create private tenants only where a stated data-handling need exists.
Integrations with ingest clients and log shippers	Every shipper or application that writes or reads data needs its own service account, client certificate or role, and each must be tested after changes.	Create one service role per integration pattern, reuse it across similar shippers, and document the required index and action permissions in one place.
Existing certificate infrastructure	If the organization has no internal certificate authority or uses several, node and client certificates must be issued, renewed and trusted by hand, and chain problems are hard to diagnose.	Use a single internal certificate authority with a documented renewal process and automated issuance where the organization already supports it.
Compliance evidence needs	Assessors expect documented configuration, role inventories, audit log settings and proof of review. Gathering this after the fact takes more effort than producing it during the build.	Keep configuration in version control, export role and mapping files on each change, and agree the evidence list with the assessor before the build starts.
Audit logging scope	Audit categories, retention and the destination for audit events must be chosen per cluster, and noisy settings create storage and review load.	Agree a short list of audit categories tied to the stated requirement, and route events to the existing log platform with a defined retention period.

How to test that TLS, roles and audit logs hold and fail safely

The point of this section is simple: every hardening control you configured must be shown to refuse the requests it is meant to refuse, and the results must be recorded in a form an assessor can review. Hardening that has only been configured is an assumption. Testing turns it into evidence. Run these checks in a staging cluster built from the same configuration as production before any change reaches production, and repeat them after each upgrade, role change or certificate rotation. Start with transport security. Attempt plaintext connections to the transport layer (node-to-node) and the REST layer (client-facing HTTP) and confirm that both are refused. Use a client that is configured for HTTP rather than HTTPS, and confirm that the cluster does not answer. Then confirm that a connection presenting an untrusted or expired certificate is rejected, and that a valid client certificate is required wherever mutual TLS is configured. Record the command, the target endpoint, the response and the time of the test. Check the same behavior on every node, not only the coordinating nodes that clients usually reach. Next, test each role in both directions. For every security role, send requests that should succeed and requests that should fail: reads and writes to permitted indices, attempts against indices outside the role, and cluster-level actions the role does not grant. Where document-level security, field-level security or field masking is configured, query as that role and confirm that filtered documents do not appear, that restricted fields are absent or masked in both search hits and aggregations, and that the same query run as an administrator returns the full result. Field masking is easy to misconfigure, so compare counts and sample values rather than assuming the filter applied. Then test identity lifecycle. Disable or delete a test user and confirm that existing sessions and new logins are denied. Remove a backend role mapping and confirm that the permissions it granted disappear. Let a test certificate or token expire and confirm that access stops at the expected time. Confirm that the audit trail shows each of these events. Audit logging needs its own check: generate a successful login, a failed login and a configuration change, then confirm that each produces an audit entry containing the user, source address, time and action. Confirm that the audit output is shipped to where the assessor will look and that it cannot be edited by ordinary cluster users. Finally, verify network reachability. From hosts and subnets that are not on the approved list, attempt to reach the REST API and the transport port and confirm that the connection fails at the network layer or is refused by the cluster. Keep the evidence in a dated test register with test ID, control reference, procedure, expected result, actual result, tester and retest status. DeployOpen prepares this evidence. An independent auditor or certification body is the party that issues any assessment result, so confirm the required format and scope with your auditor before the test cycle begins.

What does OpenSearch security hardening cost and what does it need from our team?

What drives the cost of OpenSearch security hardening?

The main drivers are the scope written into the plan, the number of clusters, the identity sources to connect, and the data classes that need separate access rules. A single cluster with one identity provider and two data classes is a much smaller job than several clusters with directory, SSO and certificate work across mixed data. Costs fall into two groups. The one-time work covers design, TLS setup, roles, audit logging, testing and handover. Recurring work covers patching, reviewing roles as teams change, and rotating certificates. DeployOpen does not publish a price list. A quote follows from a written scope, so ask the provider to show which items are priced per cluster, per identity source and per data class, and which are one-time or recurring.

What does our team need to provide during OpenSearch hardening?

Four inputs decide whether the work moves on schedule. First, identity owners must confirm how users, groups and service accounts are defined in SAML, OpenID Connect, LDAP or Active Directory. Second, someone needs access to the certificate authority so node and client certificates can be issued and renewed. Third, data owners must define the data classes and say which roles may read, write or see which fields. Fourth, the team needs a change window for restarts, security index changes and rollback testing. Without data owners, role design stalls, and without certificate access, TLS stays incomplete. Ask the provider to list these inputs in the written scope with named owners and dates.

Can an internal team harden OpenSearch without an outside partner?

Yes, an internal team can do this work with the OpenSearch documentation for the Security plugin and enough time to test each change. The Security plugin covers role-based access control, document-level and field-level security, field masking, audit logs and TLS for node and client traffic. The harder parts are not the settings themselves but the order of changes, the testing of role mappings against real client traffic, and the rollback plan if a restart fails. Teams without spare engineers for a test cluster often find the schedule is the constraint, not the knowledge. Ask whether the plan includes a test environment, a written rollback procedure and a review of role mappings before production changes.

How is the scope of an OpenSearch hardening engagement agreed?

Most DeployOpen engagements are fixed-scope. The scope, deliverables and timelines are agreed in writing before any work starts, and the quote follows from that written scope. A useful scope names the clusters, the identity sources, the data classes, the roles to be created, the audit logging requirements and the testing to be done. It also states what is out of scope, such as application code changes or work on other search platforms. Before signing, check that every assumption from the client side appears in the document, including owners for identity, certificates and data classes. If a requirement changes during the work, the change should be recorded and priced through a written update to the scope.

Which identity backends does the OpenSearch Security plugin support?

The OpenSearch Security plugin supports SAML, OpenID Connect, Active Directory and LDAP, Kerberos and JSON Web Token authentication backends. Each backend needs its own configuration for claims or group attributes, and those values are then mapped to security roles. Engineers should confirm which backend matches the identity provider in use, which groups or claims carry role information, and how service accounts for applications are issued. Test each mapping with a user from every group, because a mapping that works for one group can grant too much or too little access to another. Keep a record of the mappings so the next upgrade or identity change can be checked against it.

What happens after OpenSearch hardening is handed over to our team?

After handover, your team owns the running configuration, so the handover package should be complete before the engagement closes. It should include the documented configuration, role and mapping inventory, certificate renewal steps, audit log locations, the rollback procedure and the test results. Your engineers should be able to add a user group, renew a certificate and read an audit entry without outside help. Security patches and new releases still need planning, because OpenSearch versions receive bug fixes and security patches during maintenance. Ask the provider what the handover includes, which items are walked through with your team, and how questions are handled after the engagement ends.

Can ongoing OpenSearch hardening be covered by a retainer?

Yes, ongoing hardening can be covered by a retainer. DeployOpen offers retainers for ongoing support, upgrades and continuous testing, which suits teams that add clusters, identity sources or data classes over time. A retainer is useful when role reviews, certificate renewals, patch windows and periodic security testing need a steady owner. Confirm in writing what the retainer covers, how requests are prioritized, how often reviews happen and how changes outside the retainer are scoped and quoted. The retainer terms should be compared with the cost of keeping the same work in-house, including the engineers who would need time to maintain it.

What to monitor, rotate, upgrade and document after hardening

The hardening work only holds if someone watches it after handover. The first priority is the audit trail and authentication failures. The Security plugin's audit logging should be configured to record the events your compliance and incident response teams actually need, such as failed logins, privilege changes and access to sensitive indices. Route those logs to a location the cluster administrators cannot silently edit, and set alerts on bursts of failed authentication against the admin and service accounts. Ask your team to confirm which audit categories are enabled in the audit configuration file, because the default set may not match your retention or investigation requirements. Certificates need a dated owner. Node and client TLS certificates, along with the admin certificate used for security configuration changes, should be listed in a certificate inventory with issuer, subject, expiry date and the systems that depend on each one. Schedule renewal well before expiry and rehearse it in a non-production cluster first. Losing the admin certificate is especially disruptive because it is the credential used to apply security configuration, so confirm where its private key is stored, who can retrieve it under change control, and how a replacement would be issued. Role mappings drift when identity groups change. When the directory team renames, splits or retires a group, the backend role mappings in the Security plugin can silently grant too much or too little access. Review the role and mapping register on a fixed cadence and whenever a SAML, OpenID Connect, LDAP or Active Directory group changes. Keep the security configuration files in version control, so every change to roles, mappings, tenants and audit settings has an author, a reviewer and a reason, and so that a known-good state can be restored. Patches and upgrades follow the release policy. During maintenance, OpenSearch versions receive bug fixes and security patches but no new features, so a supported version can be patched without a feature upgrade. Confirm with the OpenSearch releases page which minor version your cluster is on and when that line leaves maintenance, then plan patch windows around it. Each upgrade or patch should be followed by a rerun of the verification checks from the hardening work, covering TLS on node and client traffic, anonymous access, the REST API lockdown and the role tests, before users are reconnected. Finally, the handover package must be complete enough for someone else to operate the cluster. Hand over the architecture and trust diagram, the role and mapping register, the certificate inventory, the audit configuration, the runbooks for certificate rotation, admin access and incident response, and the test results from the hardening verification. Ask the implementation partner to state in writing which of these documents will be delivered, in what format, and who will keep them current after the engagement closes.

How DeployOpen scopes, builds and hands over OpenSearch hardening

DeployOpen plans and implements OpenSearch security hardening inside your own infrastructure, using the Security plugin for TLS, role-based access, document and field-level security and audit logging. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts.

How we scope

Inventory the clusters, nodes, indices and Dashboards instances that the hardening must cover
Map which users, services and applications need which index and field access today
Agree in writing which Security plugin features, backends and audit settings are in scope

How we build

Enable TLS for node-to-node and client traffic, with certificate ownership and rotation documented
Build least-privilege roles, backend role mappings and document or field-level restrictions, then test them against real access paths
Restrict or lock down REST API access and audit logging settings, verifying each change on a non-production cluster first

How we hand over

Deliver the role, mapping, certificate and audit configuration as version-controlled artifacts
Provide test evidence showing which access rules were verified and how each was checked
Document the runbook for adding users, rotating certificates and reviewing audit logs

How we support

Engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as a retainer
Retainer work can cover re-checking hardening after OpenSearch minor version upgrades
Confirm with us during scoping which operational responsibilities stay with your team after handover