How to Disable OpenSearch Security in Magento 2 While Keeping It Private on Ubuntu

What You Are Actually Doing Here

OpenSearch ships with its Security plugin enabled: TLS on the HTTP and transport layers, an admin user, and demo certificates. For a Magento development box or an internal single-server install, that machinery is often more friction than protection, and turning it off is a legitimate choice.

But be precise about what "safe" means in that sentence, because the usual version of this guide gets it wrong. With security disabled, anything that can reach port 9200 has full read and write access to your index, with no authentication at all. That includes deleting every index with a single HTTP request. The only thing standing between that and a stranger is the network boundary. So the network boundary is the part that has to be right, and it is the part most guides handle with a firewall rule that does nothing.

This guide disables OpenSearch security, binds it so it is genuinely unreachable, and then verifies that claim rather than assuming it.

When This Is Fine, And When It Is Not

The dividing line is simple: if traffic to OpenSearch never leaves the loopback interface, disabling security is a reasonable trade. The moment it touches a real NIC, you have an unauthenticated database on a network.

Version Requirements First

Magento pins its supported search engine per release, and a mismatch causes indexer failures that look like configuration problems:

Check Adobe's system requirements for your exact patch before installing. Installing whatever apt offers and hoping is how you end up debugging catalogsearch_fulltext at midnight.

Step 1: Install OpenSearch (Not With Plain apt)

The command you will find in most guides, sudo apt install opensearch, fails: OpenSearch is not in Ubuntu's repositories. You have to add the project's own repository first.

# Dependencies
sudo apt-get update
sudo apt-get -y install lsb-release ca-certificates curl gnupg2

# Import the OpenSearch GPG key
curl -o- https://artifacts.opensearch.org/publickeys/opensearch-release.pgp \
  | sudo gpg --dearmor --batch --yes -o /usr/share/keyrings/opensearch-release-keyring.gpg

# Add the 2.x repository
echo "deb [signed-by=/usr/share/keyrings/opensearch-release-keyring.gpg] \
https://artifacts.opensearch.org/releases/bundle/opensearch/2.x/apt stable main" \
  | sudo tee /etc/apt/sources.list.d/opensearch-2.x.list

sudo apt-get update

Now the second thing that trips people up. Since OpenSearch 2.12, the installer requires an initial admin password and refuses to install without one:

# Pin the version Magento expects rather than taking latest
sudo env OPENSEARCH_INITIAL_ADMIN_PASSWORD='Str0ng!Passw0rd' \
  apt-get -y install opensearch=2.19.0

The password must be at least eight characters with an uppercase letter, a lowercase letter, a number, and a special character, or the install fails with an unhelpful message.

There is a mild irony here: you set an admin password during an install where the next step is to disable the authentication that uses it. Set it anyway. It is required, and if you ever re-enable security you will want it to exist.

Step 2: Disable the Security Plugin

One setting, in /etc/opensearch/opensearch.yml:

plugins.security.disabled: true

That is the whole thing. You will see guides adding lines like opensearch.ssl.http.enabled: false or opensearch.ssl.transport.enabled: false. Those are not real OpenSearch settings. They do nothing. TLS on both layers is provided by the Security plugin, so disabling the plugin removes TLS with it. Extra ssl lines are cargo cult; delete them if you have them.

Two things the documentation is explicit about and most guides skip:

• A full restart is required. Not a reload. On a cluster it is a full cluster restart, because nodes cannot talk to each other mid-transition. On a single node, systemctl restart is enough.
• Disabling exposes the Security plugin's own configuration index. If it holds anything sensitive, that is now readable by anyone who can reach the port.

Step 3: The Bind Address Is the Real Protection

This is where the standard guide goes wrong. It tells you to run:

# This rule does NOT protect anything.
sudo ufw allow from 127.0.0.1 to any port 9200

That rule allows loopback traffic. Loopback is already allowed, UFW does not filter it by default. The rule adds nothing and, worse, it creates the impression that a firewall is now guarding the port when nothing changed.

The setting that actually protects you is the bind address:

# /etc/opensearch/opensearch.yml
network.host: 127.0.0.1
http.port: 9200

# Single-node install: tell OpenSearch not to look for peers
discovery.type: single-node

With network.host: 127.0.0.1, OpenSearch binds only to loopback. It is not reachable from another machine regardless of your firewall, because there is no socket listening on an external interface to reach. That is a property of the process, not a rule someone can later flush.

Add discovery.type: single-node for a single-server Magento box or OpenSearch will sit waiting to form a cluster and never go green.

Restart and move on:

sudo systemctl restart opensearch
sudo systemctl enable opensearch

Defence in depth is still worth it. If you want a firewall rule that does something, write a deny for the external interface rather than an allow for loopback:

sudo ufw deny 9200/tcp

That way, if someone later changes network.host to 0.0.0.0, the firewall is a second line rather than decoration.

Step 4: Verify It Is Actually Private

Do not skip this. "It should be bound to localhost" is exactly the assumption behind every exposed database on Shodan.

# 1. What is it ACTUALLY listening on?
sudo ss -tulpn | grep 9200
# Want:  127.0.0.1:9200
# Bad:   0.0.0.0:9200  or  *:9200  -> reachable from the network

That one line is the whole security model. If it says 0.0.0.0, you have an unauthenticated search engine on the internet and the firewall is the only thing saving you.

# 2. Does it answer locally over plain HTTP (no TLS, no auth)?
curl http://localhost:9200
# Should return cluster info as JSON, with no credentials

# 3. Health check
curl http://localhost:9200/_cluster/health?pretty
# status should be "green" (single-node) or at least "yellow"

Then the test that matters, run from a different machine:

# From your laptop, NOT from the server
curl --max-time 5 http://<server-public-ip>:9200
# Want: connection refused or timeout.
# If this returns JSON, stop and fix the bind address now.

If that last command returns data, every index you have is world-readable and world-deletable. Nothing else in this guide matters until it does not.

Step 5: Point Magento At It

The admin UI works, but the CLI is repeatable and scriptable:

bin/magento config:set catalog/search/engine opensearch
bin/magento config:set catalog/search/opensearch_server_hostname localhost
bin/magento config:set catalog/search/opensearch_server_port 9200
bin/magento config:set catalog/search/opensearch_index_prefix magento2
bin/magento config:set catalog/search/opensearch_enable_auth 0
bin/magento config:set catalog/search/opensearch_server_timeout 15

bin/magento cache:flush

opensearch_enable_auth 0 is the line that matches what you did in step 2. Leave it at 1 and Magento will try to authenticate against a plugin that is no longer there.

Via the admin UI the same thing lives under Stores > Configuration > Catalog > Catalog > Catalog Search: engine OpenSearch, hostname localhost, port 9200, and Enable HTTP Auth off.

Then prove the wiring end to end:

bin/magento indexer:reindex catalogsearch_fulltext

# Did documents actually land?
curl 'http://localhost:9200/_cat/indices?v'
# Expect a magento2_product_* index with a non-zero docs.count

A reindex that "completes without errors" but leaves an empty index is a common and confusing outcome. The _cat/indices check is what tells you it really worked. A zero docs.count usually means the index prefix does not match or the store has no indexable products.

What You Gave Up, And When To Undo It

You now have an OpenSearch instance with no authentication, no TLS, and no audit trail, protected by exactly one thing: it is not listening on a routable address. That is a legitimate configuration for a single-host Magento install. It stops being legitimate the moment any of these becomes true:

• OpenSearch moves to its own host
• Anything else gains shell access to the box
• You add a second node
• A compliance framework enters the conversation

Re-enabling is the reverse: remove plugins.security.disabled, restart, run the security admin tool to initialise the config index, replace the demo certificates with real ones, and set opensearch_enable_auth 1 in Magento. Plan for it to take an afternoon rather than a command.

The honest summary: disabling security is a trade of one protection for another, not the removal of protection. Loopback binding is the security control here. Verify it with ss, verify it again from outside, and treat any 0.0.0.0 in that output as an incident.

For the full setup on a supported version with security left on, see our guide to setting up OpenSearch for Magento 2.4.7 on Ubuntu. If you would rather have the search tier built and secured properly, that is what our Magento and servers management work covers.

Sources

• OpenSearch: disabling and enabling the Security plugin
• OpenSearch: install on Debian and Ubuntu
• OpenSearch: the end of the default admin password
• OpenSearch: network and discovery settings
• Adobe Commerce system requirements
• Adobe Commerce: configure Magento to use OpenSearch