OpenSearch Security Review
OpenSearch’s security plugin ships with demo certificates for quick setup, and can be switched off with one setting. We test what your team actually enabled: roles, role mappings, tenants and API credentials. CREST-certified testers, fixed price from £2,620 for a 2-day single-system scope, quoted within 24 hours.
- Unlimited retesting
- Unlimited pre-retesting
- No hidden fees
“I would highly recommend EJN Labs to any organisation seeking reliable, detailed, and well-managed penetration testing services, particularly for government or enterprise-level projects.”
“There wasn’t another company we could find that could deliver what we needed in the timeframe we needed. The client loved it, and we got instant ROI from the engagement.”
Amazon OpenSearch Service documents three layers of security: the network, the domain access policy, and fine-grained access control. Each layer is evaluated in that order, so a mistake in the first two can matter before role-based permissions are ever checked.
OpenSearch security is built from layers that each have to be configured, not one setting that switches it all on
OpenSearch’s own security configuration guide is direct that the Security plugin can be disabled entirely with a single opensearch.yml setting, and that every cluster ships with demo TLS certificates intended for quick setup and demonstration, not production traffic. Since OpenSearch 2.12, the demo configuration guide requires a custom admin password meeting a minimum character mix and a strong zxcvbn rating before installation will even complete, which closes off the old fixed default, but does nothing for a cluster provisioned before that requirement existed or a demo certificate that was never replaced.
Every role combines cluster permissions, index permissions and tenant permissions, and OpenSearch’s document-level security documentation is explicit that a document-level restriction is retained by default even when a user holds a second role over the same index with no restriction attached, a safety net that a single cluster-wide setting, plugins.security.dfm_empty_overrides_all, can switch off for every user at once. Multi-tenancy in Dashboards is on by default too, splitting saved objects between a shared Global tenant and a private tenant per user, so which roles can read or write to which tenant is a decision your team made, not a setting OpenSearch made for you.
Amazon OpenSearch Service adds two more layers in front of the cluster: AWS’s own access control documentation warns that a Principal wildcard in the domain access policy opens the domain to anonymous requests unless it is paired with an IP condition, VPC placement or fine-grained access control, and a domain built with a public endpoint can never be moved into a VPC without standing up a new one. We test the cluster you actually run, self-managed or on Amazon OpenSearch Service, against the roles, tenants and network configuration your team put in place, not against OpenSearch or AWS’s own platform. For the wider family of stores this scope splits from, see our NoSQL, cache and streaming security review, and our MongoDB security review for the closest document-store comparison.
SCOPE
What we review in an OpenSearch cluster
Security Plugin Status, Demo Certificates and the Admin Account
The Security plugin can be turned off completely by setting plugins.security.disabled to true in opensearch.yml, and every install ships with demo TLS certificates that OpenSearch’s own documentation says are for quick setup and demonstration, not production. Since OpenSearch 2.12 the demo installer forces a custom admin password meeting a minimum character mix and a strong zxcvbn rating, so we test whether the plugin is actually enabled, whether production certificates have replaced the demo set, and how strong and how exposed the admin credential really is.
Internal Users, Roles and Role Mappings
Users can be defined in the internal user database through internal_users.yml, OpenSearch Dashboards, or the REST API, and each one is mapped to one or more roles that combine cluster, index and tenant permissions, with OpenSearch’s own guidance to manage this through Dashboards or the REST API once the cluster is running rather than the bootstrap YAML files. We test which users and backend roles actually hold which mappings, and whether a mapping created for initial setup has been left in place long after it should have been narrowed.
Cluster and Index Permissions (Action Groups)
A role is built from cluster permissions and index permissions, each granted as named actions or action groups such as cluster_monitor or indices_all, and OpenSearch’s own reserved kibana_server role shows how tightly these can be scoped when built deliberately, down to specific index patterns and administrative-only actions. We map every role actually in use against the action groups and index patterns it grants, and flag a role built from a broad built-in group where a narrower, purpose-built one would do.
Document-Level Security (DLS)
A role’s index permissions can carry a DLS query that filters which documents a match returns, and OpenSearch’s documentation confirms the restriction is retained by default even when a user holds a second role over the same index with no DLS query attached, unless the cluster-wide setting plugins.security.dfm_empty_overrides_all has been switched on, which flips that behaviour and lets the unrestricted role win instead. We test every DLS query against the data it is meant to restrict, and check whether dfm_empty_overrides_all is enabled anywhere in the cluster, since it quietly removes every document-level restriction for a user who holds even one broader role.
Field-Level Security and Field Masking
Field-level security lets a role’s index permissions include or exclude specific fields from a response using an fls list, where a tilde prefix excludes a named field, while field masking anonymises a field instead of removing it, using a secure random hash by default or a pattern-based mask where the field still needs to support aggregations. We test which fields are actually hidden or masked for each role, and whether a masked field still leaks its value through an aggregation, a highlight, or a script that reads it directly.
Multi-Tenancy in OpenSearch Dashboards
Multi-tenancy is enabled in Dashboards by default, giving every user a private tenant alongside the shared Global tenant, and OpenSearch stores each tenant’s saved objects in its own index, following the pattern .kibana_
Authentication Backends: Internal Users, SAML and OpenID Connect
OpenSearch authenticates through one or more configured domains run in a set order, and its own SAML guidance recommends keeping an internal, basic-auth domain first in that order with the challenge flag disabled, both to support API access outside the identity provider and because the Dashboards server account itself cannot authenticate through SAML or OpenID Connect. We test every configured authentication domain, not just the one your users see, since the internal fallback that keeps the Dashboards server account and API access working is also a full password-based route into the cluster.
Security REST API and Credential Exposure
Internal users, roles and role mappings are all managed through the security plugin’s own REST API, and OpenSearch’s guidance is to use the REST API or Dashboards for ongoing changes rather than editing internal_users.yml and roles.yml after initial setup, while some administrative calls, such as reading the reserved kibana_server role definition, need the cluster’s admin TLS certificate rather than an ordinary user role. We test who and what can reach the security REST API, what a leaked API credential or admin certificate can actually change, and whether an endpoint meant for initial bootstrap is still reachable.
Amazon OpenSearch Service: Fine-Grained Access Control and the Master User
A domain’s master user, set at creation as either an IAM role or user or a username and password, can create further master users by mapping them to the built-in all_access and security_manager roles, and AWS documents fine-grained access control as the last of three security layers, evaluated only after a request has already passed the network and the domain access policy. We test who actually holds master-user or all_access rights, whether the master-user type and domain access policy AWS recommends pairing together is the combination actually deployed, and what a compromised master credential reaches once fine-grained access control is the only barrier left.
Amazon OpenSearch Service: Domain Access Policy, VPC and Public Access
A domain is created with either a public endpoint or a VPC endpoint, and AWS is explicit that you cannot switch between them afterwards, only migrate to a new domain, while the domain access policy sits in front of fine-grained access control and AWS warns that a Principal wildcard in that policy opens the domain to anonymous requests unless it is paired with an IP condition, VPC placement or fine-grained access control. We test what the domain access policy actually allows past the network layer, and whether a public domain, an open access policy, or both, are doing more of the access-control work than the team realises.
OUR PROCESS
OpenSearch Security Review: From Scope to Attestation
Scope and Access
We agree which OpenSearch clusters, domains and Dashboards tenants are in scope, plus a user for every distinct role you use and, on Amazon OpenSearch Service, read access to the domain’s access policy and master user configuration.
Role and Permission Mapping
We map every role, role mapping, document and field-level restriction and Dashboards tenant against who or what actually needs that level of access, on self-managed clusters and Amazon OpenSearch Service alike.
Manual Testing
A CREST-certified tester manually tests authentication and role boundaries, document and field-level security, tenant isolation in Dashboards, and REST API and network exposure, chaining findings where they compound.
Attestation and Retest
You get a technical report with CVSS scores and reproduction steps, a walkthrough call, a free retest once fixes are deployed, and an attestation letter for auditors.
CREDENTIALS
Verified Accreditations Auditors Accept
Every credential below is independently verifiable. UK procurement teams, FCA supervisors, ISO 27001 / SOC 2 auditors, and cyber insurance underwriters all recognise these standards.
GET YOUR QUOTE
Get a CREST OpenSearch pen test quote in 24 hours
A fixed-price quote back in one business day, from a named CREST assessor. No sales pipeline, no chasing.
- CREST and IASME accredited. Testing your auditors and clients already recognise.
- Fast-track testing within 24 hours where required. Free retest of every fix included.
- Live findings via your client portal, not a four-week PDF.
- Fixed price from £3,500 for a single-role, single-app scope, agreed up front. Most engagements run £5,000 and up. No day-rate surprises.
Dan WilcocksonFounder, CelloriUnder NDA Further named references available on a scoping call.
- We reply within one business day with a fixed-price quote from a named CREST assessor.
- You approve the scope and we book a start date, usually within 24 hours.
- Live findings land in your client portal as we test, with a free retest of every fix.
Get your fixed pen test quote in 24 hours
Quote request received
We will reply within one business day with your fixed-price quote from a named CREST assessor.
Your data stays with us. No newsletter signup.
or book a 20-min scoping call first
We reply within one business day. Your data stays with us. No newsletter signup.
COMPLIANCE READY
Reports Mapped to Every Framework
Findings are written so your team can reference the report against each framework without translation work.
ISO 27001:2022
Annex A.8.8 management of technical vulnerabilities plus A.5.15-5.18 and A.8.2-8.5 access control validation.
SOC 2 Type I & II
CC6 logical access, CC7 system operations, CC8 change management evidence.
PCI DSS
Requirement 11.4 application penetration testing across cardholder data environments, including ecommerce penetration testing for online retail platforms.
FCA SYSC
SYSC 4.1.1R, 6.1.1R, 13 mapped to each finding for FCA-regulated firms.
UK GDPR
Article 32 effectiveness testing, customer-data security controls, ICO-acceptable evidence.
Cyber Essentials Plus
Direct certification through our IASME body status, single-vendor delivery.
PRICING
Transparent OpenSearch Security Review Pricing
Pricing depends on the number of roles, integrations and environments in scope. See our pricing page for how we quote.
2 to 3 testing days
Single user role, basic CRUD application, marketing website with auth. Around 5 working days from kickoff to report.
Get a fixed quote3 to 4 testing days
Multi-role SaaS, business application with payment integration. Around 8 to 12 working days from kickoff to report.
Get a fixed quote4 to 6 testing days
Multi-tenant platform, complex authorisation matrix, integration-heavy applications. Around 15 to 20 working days from kickoff to report.
Get a fixed quoteSECTORS
Sectors We Test OpenSearch For
Sector-specific scoping for regulated UK organisations.
Fintech & FCA-Regulated
FCA SYSC, Open Banking FAPI 1.0, PSD2 SCA, payment-flow scrutiny, KYC/AML testing.
Fintech sector pageSaaS Companies
SOC 2 Type I & II evidence, multi-tenant boundaries, role escalation, customer-tenant isolation.
SaaS sector pageLaw Firms
SRA Cyber Standard, privileged data, conveyancing fraud defence, partner-tier procurement.
Law firm sector pageHealthcare
NHS DTAC, DSP Toolkit v6, UK GDPR Article 32, EHR systems, telehealth platforms.
Healthcare sector pageInsurance
FCA / PRA Operational Resilience, cyber underwriting, claims data, broker portals.
Insurance sector pagePublic Sector
CCS / G-Cloud framework, NCSC-aligned, citizen-facing services, PSN-compliance scrutiny.
Public sector pageWHY EJN LABS
What You Get From OpenSearch Security Review
Six concrete differentiators competitors don’t all match.
CREST-Certified Testers, Verifiable
Every test by a CREST-certified pen tester (CRT, CCT APP, CCT INF where applicable). Verify our company status at crest-approved.org.
24-Hour Startup, Where Required
From signed scope to active testing in a single business day for incident response, audit deadlines, or regulator-driven timelines.
Live Findings, Not 4-Week PDFs
Critical issues reported during testing through your client portal. Your team remediates while testing continues.
Audit-Ready Reports
Executive summary plus full technical report with CVSS scores and explicit framework mappings (ISO 27001, SOC 2, PCI DSS, FCA SYSC).
Free Retests, Standard
Verify remediation of every finding before close-out. Letter of attestation for audit submission included. Most competitors charge £1,500-£3,000 per retest.
UK-Based CREST Testers
Every engagement performed by vetted, UK-based CREST-certified testers, matched to your needs, security clearance, and compliance scope.
FAQ
Frequently Asked
What access do you need to test our OpenSearch cluster?
We need an authenticated account for every distinct role you use, from a narrow read-only role through to whichever role holds the widest cluster and index permissions, plus a Dashboards login covering the Global tenant and any other shared tenant in scope. Read access to your current internal_users.yml, roles.yml and role mapping configuration, or the REST API equivalent, speeds up scoping but is not required to start.
Will testing touch live data?
We test the roles, permissions, document and field-level restrictions and tenants you nominate, working against your actual configuration rather than a copy, so we agree exclusions such as destructive queries, bulk deletes or production index writes before testing starts. We do not export real customer data or run destructive tests without that agreement in writing.
Do you test self-managed OpenSearch and Amazon OpenSearch Service the same way?
The underlying questions are the same: who can authenticate, what role they hold, and what the network and any access policy expose in front of that. What differs is the boundary, since Amazon OpenSearch Service manages the host, adds a domain access policy in front of fine-grained access control, and configures VPC placement differently again, so we confirm exactly what you control during scoping and test to that boundary.
What is out of scope for a single-system OpenSearch review?
We never test OpenSearch’s own source code, the underlying host, or Amazon OpenSearch Service’s shared infrastructure, and a separately hosted application that happens to query the cluster is scoped and quoted on its own. We test the security plugin configuration, roles, role mappings, document and field-level security, Dashboards tenants and, on Amazon OpenSearch Service, the domain access policy and network configuration for the cluster or domain you nominate.
Does OpenSearch or AWS have a policy on customer penetration testing?
OpenSearch itself is open-source software with no customer-testing policy to follow, but Amazon OpenSearch Service is explicitly named on AWS’s list of permitted services for customer-initiated security assessments carried out without prior approval, alongside a small set of prohibited activities such as denial-of-service testing. We confirm AWS’s current policy and any account-specific conditions during scoping and test within them.
How long does an OpenSearch security review take?
A single OpenSearch cluster or Amazon OpenSearch Service domain, with a typical number of roles, indices and Dashboards tenants, sits in our 2-day single-system scope, with a report usually landing around 5 working days after kickoff. Multiple domains, several authentication backends, or a large number of custom document and field-level security rules move into a larger scope with more testing days.
Do you need our source code or admin access?
No. There is no application source code in an OpenSearch cluster to review. We test with the role accounts and access you provide, and any standing super-admin certificate access is limited to what is needed to verify a specific finding during the engagement.
Are your testers CREST certified?
Yes. Every OpenSearch engagement is carried out by UK-based, CREST-certified testers, and your report and attestation letter are recognised by auditors and insurers accordingly.
20+ CREST-accredited testing services in one place
Web, mobile, API, cloud, AI, infrastructure, red team. Pick the test that fits your environment.
Get a fixed price for your OpenSearch review
OpenSearch’s security plugin ships with demo certificates for quick setup, and can be switched off with one setting. We test what your team actually enabled: roles, role mappings, tenants and API credentials. CREST-certified testers, fixed price from £2,620 for a 2-day single-system scope, quoted within 24 hours.
