OpenSearch 3.6

In the Azure Portal, open Marketplace, search for OpenSearch 3.6 and select the SecureAnyCloud publisher entry. Click Create to start the wizard.

On the Basics tab, choose your subscription, target resource group and region. The region must match the region where your Azure Compute Gallery exposes the image. Set the virtual machine name.

Choose a size of Standard_D2s_v5 or larger, which provides two virtual CPUs and eight gigabytes of memory. OpenSearch defaults to a one gigabyte Java heap, and Dashboards uses around seven hundred megabytes of resident memory. The operating system and the page cache need the remainder.

Choose SSH public key as the authentication type, enter a username of your choice, and paste your SSH public key.

On the Disks tab, choose Premium SSD as the OS disk type and leave the OS disk size at the default. If you plan to move the OpenSearch data directory to a separate Premium SSD data disk, you can attach that disk now. You can also do it after the cluster is running, by following Step 12.

On the Networking tab, select your existing virtual network and subnet. Attach a network security group that allows inbound TCP 22 from your management IP range, inbound TCP 9200 only from the virtual network CIDR, and inbound TCP 5601 only from the virtual network CIDR or a jump host.

Do not expose 9200 or 5601 to the public internet. The demo certificates ship with predictable public keys and are documented as unsuitable for production. Any exposure beyond a private network requires the certificate replacement described in Step 13.

On the Management, Monitoring and Advanced tabs, the defaults are appropriate. Click Review + create, wait for validation to pass, then click Create. Deployment takes around three minutes.

To deploy from the command line, accept the Marketplace terms once, then deploy from the Marketplace image URN:

RG="opensearch-prod" LOCATION="eastus" VM_NAME="opensearch-node-1" ADMIN_USER="opsuser" IMAGE_URN="sac1647283583153:opensearch-3-6-ubuntu-22-04:sac:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION" az network vnet create \
  --resource-group "$RG" \
  --name opensearch-vnet \
  --address-prefix 10.30.0.0/16 \
  --subnet-name opensearch-subnet \
  --subnet-prefix 10.30.1.0/24 az network nsg create --resource-group "$RG" --name opensearch-nsg az network nsg rule create --resource-group "$RG" --nsg-name opensearch-nsg \
  --name allow-ssh --priority 1000 \
  --source-address-prefixes "<your-management-cidr>" \
  --destination-port-ranges 22 --protocol Tcp --access Allow az network nsg rule create --resource-group "$RG" --nsg-name opensearch-nsg \
  --name allow-rest --priority 1010 \
  --source-address-prefixes 10.30.0.0/16 \
  --destination-port-ranges 9200 --protocol Tcp --access Allow az network nsg rule create --resource-group "$RG" --nsg-name opensearch-nsg \
  --name allow-dashboards --priority 1020 \
  --source-address-prefixes 10.30.0.0/16 \
  --destination-port-ranges 5601 --protocol Tcp --access Allow
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:opensearch-3-6-ubuntu-22-04:sac:latest
az vm create \
  --resource-group "$RG" \
  --name "$VM_NAME" \
  --image "$IMAGE_URN" \
  --size Standard_D2s_v5 \
  --admin-username "$ADMIN_USER" \
  --ssh-key-values "$SSH_KEY" \
  --vnet-name opensearch-vnet \
  --subnet opensearch-subnet \
  --nsg opensearch-nsg \
  --public-ip-address "" \
  --os-disk-size-gb 64

The final command creates a virtual machine with no public IP, which is the recommended posture for an OpenSearch node. Connect through a bastion host, the Azure Bastion service, or a virtual private network peered into the same virtual network.

Connect with the admin username you chose during deployment and the private key that matches the public key you pasted into the deployment form:

ssh -i ~/.ssh/id_rsa <admin-username>@<vm-private-ip>

All later commands in this guide run on the virtual machine as the admin user, with sudo where a command needs root. Do not log in directly as the opensearch service user. That account has /usr/sbin/nologin as its shell and is intended for the daemon only.

On its first boot, the virtual machine runs opensearch-firstboot.service. The service generates a thirty-two-character admin password and writes it to /stage/scripts/opensearch-credentials.log. Read the file with sudo:

sudo cat /stage/scripts/opensearch-credentials.log

The file contains four lines:

username=admin password=<generated-password> opensearch_url=https://<vm-private-ip>:9200 dashboards_url=http://<vm-private-ip>:5601

Copy these values somewhere safe. The password is not recoverable from the image. Step 10 explains how to rotate it.

If your environment requires it, store the file off the virtual machine, then tighten the file mode or remove the file. By default, the file is owned by opensearch and has mode 0600.

The image ships the following components:

• OpenSearch 3.6.0: the distributed search and analytics engine. It is installed under /opt/opensearch, a symlink to /opt/opensearch-3.6.0, and runs under the opensearch system user as opensearch.service.
• OpenSearch Dashboards 3.6.0: the web UI for search, visualisation and cluster management. It is installed under /opt/opensearch-dashboards, a symlink to /opt/opensearch-dashboards-3.6.0, and runs under the opensearch system user as opensearch-dashboards.service.
• OpenSearch Security plugin: pre-installed. The security demo installer writes the TLS certificates and a minimal internal users database during first boot.
• Bundled OpenJDK: OpenSearch ships its own Java runtime at /opt/opensearch/jdk. The system has no separate JDK package installed.
• One-shot first-boot unit: opensearch-firstboot.service runs once and sets the admin password. The sentinel file /var/lib/opensearch/.firstboot-done gates it, so the service does nothing on every later boot.

These are the paths you work with most often:

• /opt/opensearch: OpenSearch install root (symlink)
• /opt/opensearch-dashboards: Dashboards install root (symlink)
• /opt/opensearch/config/opensearch.yml: cluster configuration
• /opt/opensearch/config/opensearch-security/: Security plugin configuration (internal users, roles, mappings)
• /opt/opensearch/config/esnode.pem: demo node certificate
• /opt/opensearch/config/root-ca.pem: demo root CA certificate
• /opt/opensearch-dashboards/config/opensearch_dashboards.yml: Dashboards configuration
• /var/lib/opensearch/data: index data (move it to an attached disk for production, see Step 12)
• /var/log/opensearch/opensearch.log: OpenSearch daemon log
• /var/log/opensearch/opensearch-dashboards.log: Dashboards log
• /etc/systemd/system/opensearch.service: main service unit
• /etc/systemd/system/opensearch-dashboards.service: Dashboards service unit
• /etc/systemd/system/opensearch-firstboot.service: first-boot credential generator
• /stage/scripts/opensearch-credentials.log: admin credentials and URLs (file mode 0600)

systemd manages the two main services independently. Dashboards depends on OpenSearch, so start OpenSearch first when you bring the stack up from a cold stop.

sudo systemctl start opensearch.service
sudo systemctl status opensearch.service
sudo systemctl start opensearch-dashboards.service
sudo systemctl status opensearch-dashboards.service

To stop the stack, stop Dashboards first, then OpenSearch:

sudo systemctl stop opensearch-dashboards.service
sudo systemctl stop opensearch.service

Both services are enabled at boot. To stop Dashboards from starting automatically, run sudo systemctl disable opensearch-dashboards.service.

Log output is appended to files under /var/log/opensearch. Follow the OpenSearch daemon log with:

sudo tail -f /var/log/opensearch/opensearch.log

Load the admin password into a shell variable and query the cluster:

ADMIN_PW=$(sudo awk -F= '/^password=/ {print $2}' /stage/scripts/opensearch-credentials.log)
curl -sku "admin:${ADMIN_PW}" https://localhost:9200/_cluster/health?pretty
curl -sku "admin:${ADMIN_PW}" https://localhost:9200/_cat/nodes?v
curl -sku "admin:${ADMIN_PW}" https://localhost:9200

The -k flag tells curl to skip TLS verification. This is necessary while the image ships with the demo self-signed certificate.

To call the API from a remote host, replace localhost with the private IP of the virtual machine and copy the admin password to that host. Add -H 'Content-Type: application/json' when you send JSON bodies.

With the OpenSearch Python client, the equivalent connection looks like this:

from opensearchpy import OpenSearch client = OpenSearch( hosts=[{"host": "<vm-private-ip>", "port": 9200}], http_auth=("admin", "<generated-password>"), use_ssl=True, verify_certs=False, ssl_show_warn=False, ) print(client.cluster.health())

In production code, set verify_certs=True and provide your own root CA bundle after you replace the demo certificates as described in Step 13.

Create an index, index a document, run a simple search, and then delete the index:

curl -sku "admin:${ADMIN_PW}" -X PUT \
  https://localhost:9200/products \
  -H 'Content-Type: application/json' \
  -d '{"settings":{"number_of_shards":1,"number_of_replicas":0}}'
curl -sku "admin:${ADMIN_PW}" -X POST \
  https://localhost:9200/products/_doc?refresh=true \
  -H 'Content-Type: application/json' \
  -d '{"name":"sac OpenSearch image","price":0,"tags":["azure","ubuntu"]}'
curl -sku "admin:${ADMIN_PW}" -X GET \
  https://localhost:9200/products/_search \
  -H 'Content-Type: application/json' \
  -d '{"query":{"match":{"name":"opensearch"}}}' | jq
curl -sku "admin:${ADMIN_PW}" -X DELETE https://localhost:9200/products

Choose a new password, hash it, and push it into the security index with securityadmin.sh:

NEW_PW='<new-strong-password>'
HASH=$(/opt/opensearch/plugins/opensearch-security/tools/hash.sh -p "${NEW_PW}")
sudo -u opensearch sed -i \
  "s|^ hash: .*| hash: \"${HASH}\"|" \
  /opt/opensearch/config/opensearch-security/internal_users.yml
sudo -u opensearch \
  OPENSEARCH_JAVA_HOME=/opt/opensearch/jdk \
  /opt/opensearch/plugins/opensearch-security/tools/securityadmin.sh \
  -f /opt/opensearch/config/opensearch-security/internal_users.yml \
  -icl -nhnv \
  -cacert /opt/opensearch/config/root-ca.pem \
  -cert /opt/opensearch/config/kirk.pem \
  -key /opt/opensearch/config/kirk-key.pem \
  -h localhost -p 9200

Then update /opt/opensearch-dashboards/config/opensearch_dashboards.yml with the new password and restart Dashboards:

sudo sed -i "s|^opensearch.password:.*|opensearch.password: \"${NEW_PW}\"|" \
  /opt/opensearch-dashboards/config/opensearch_dashboards.yml
sudo systemctl restart opensearch-dashboards.service

Finally, update /stage/scripts/opensearch-credentials.log so that operators who connect later see the current value.

The OpenSearch Security plugin stores users, roles and role mappings in YAML files under /opt/opensearch/config/opensearch-security. The safest workflow is to edit the files, run securityadmin.sh to upload the changes into the security index, and reload.

Add a read-only user called analyst:

HASH=$(/opt/opensearch/plugins/opensearch-security/tools/hash.sh -p 'AnalystPass!234')
sudo -u opensearch tee -a /opt/opensearch/config/opensearch-security/internal_users.yml >/dev/null <<EOF analyst: hash: "${HASH}" reserved: false backend_roles: [] description: "Read only analyst account" EOF
sudo -u opensearch tee -a /opt/opensearch/config/opensearch-security/roles_mapping.yml >/dev/null <<'EOF' readall: reserved: false users: - analyst EOF
sudo -u opensearch \
  OPENSEARCH_JAVA_HOME=/opt/opensearch/jdk \
  /opt/opensearch/plugins/opensearch-security/tools/securityadmin.sh \
  -cd /opt/opensearch/config/opensearch-security/ \
  -icl -nhnv \
  -cacert /opt/opensearch/config/root-ca.pem \
  -cert /opt/opensearch/config/kirk.pem \
  -key /opt/opensearch/config/kirk-key.pem \
  -h localhost -p 9200

The built-in readall role grants cluster monitor and global read access. For finer-grained control, define a new role in roles.yml that names specific indices and action groups. Then map your user into that role in roles_mapping.yml.

The default /var/lib/opensearch/data lives on the OS disk. For production deployments, move it to a dedicated Premium SSD data disk. Index growth then does not compete with operating system writes, and you can size storage independently.

Attach a new Premium SSD disk through the portal or the Azure CLI. Then run the following on the virtual machine:

sudo systemctl stop opensearch-dashboards.service
sudo systemctl stop opensearch.service DEVICE=/dev/disk/azure/scsi1/lun0
sudo mkfs.ext4 "${DEVICE}"
sudo mkdir -p /mnt/opensearch-data echo "${DEVICE} /mnt/opensearch-data ext4 defaults,nofail 0 2" \
  | sudo tee -a /etc/fstab
sudo mount -a sudo rsync -aHAX /var/lib/opensearch/data/ /mnt/opensearch-data/
sudo chown -R opensearch:opensearch /mnt/opensearch-data
sudo sed -i 's|^path.data: .*|path.data: /mnt/opensearch-data|' \
  /opt/opensearch/config/opensearch.yml
sudo systemctl start opensearch.service
sudo systemctl start opensearch-dashboards.service

Check /var/log/opensearch/opensearch.log for a clean start. Then list the indices through the REST API to confirm that the index metadata is intact.

The certificates shipped with this image are the upstream OpenSearch demo certificates, signed by a demo root CA. They are suitable for evaluation and for private networks where traffic cannot be intercepted. They are not production grade.

To replace them:

• Issue a node certificate and a root CA certificate from your own certificate authority, either in-house or commercial. The node certificate must include the virtual machine's private IP and DNS name in its Subject Alternative Name extension.
• Copy the node certificate, its private key, the root CA certificate, and an admin certificate and key into /opt/opensearch/config/.
• Update /opt/opensearch/config/opensearch.yml with the new filenames under plugins.security.ssl.transport.pemcert_filepath, plugins.security.ssl.transport.pemkey_filepath, plugins.security.ssl.transport.pemtrustedcas_filepath and the matching plugins.security.ssl.http.* keys.
• Set plugins.security.authcz.admin_dn to the Subject DN of your new admin certificate, so that securityadmin.sh continues to work.
• Restart OpenSearch and Dashboards.

See the upstream OpenSearch Security documentation for the full list of configuration keys and the exact Subject Alternative Name requirements.

Cannot bind to 9200, port already in use. Run sudo ss -tlnp | grep 9200 to identify the process. If OpenSearch is already running, stop it with systemctl before you start it manually. If another daemon holds the port, stop or reconfigure that daemon.

Cluster health is red. Run curl -sku "admin:${ADMIN_PW}" https://localhost:9200/_cluster/allocation/explain?pretty. On a single-node cluster, red usually means that shards cannot be allocated because the disk is full. Check df -h on /var/lib/opensearch/data or on your attached data disk.

Dashboards shows "OpenSearch Dashboards server is not ready yet". This message appears on every start until OpenSearch is healthy and the security index is reachable. Wait sixty seconds, then run tail -n 200 /var/log/opensearch/opensearch-dashboards.log and look for the first non-zero exit condition.

Admin login fails in Dashboards. Confirm that the password in /opt/opensearch-dashboards/config/opensearch_dashboards.yml matches the one in /stage/scripts/opensearch-credentials.log. If you rotated the password with securityadmin.sh and did not update Dashboards, Dashboards fails to authenticate on the back channel.

install_demo_configuration.sh log references a missing OPENSEARCH_JAVA_HOME. This should appear only if you re-ran the script manually without exporting the bundled JDK path. Export OPENSEARCH_JAVA_HOME=/opt/opensearch/jdk before you run any OpenSearch security tool by hand.

Out of memory on a Standard_B2s. The default JVM heap is one gigabyte, and Dashboards takes around seven hundred megabytes. A virtual machine with 2 vCPU and 4 gigabytes of memory leaves no headroom for the page cache. Resize to Standard_D2s_v5, or stop Dashboards on that VM.

Isolate the network. Use a dedicated network security group that exposes TCP 22 only to your management CIDR, and TCP 9200 and 5601 only to the virtual network CIDR or an explicit client allow list. Do not place a public IP on the virtual machine unless you have already replaced the demo certificates and set a strong admin password.

Replace the demo certificates. Do this before any traffic other than evaluation traffic crosses the network (Step 13). The demo certificates are documented upstream as publicly reproducible, so anyone who reads the OpenSearch source knows the demo private key.

Rotate the admin password. Do this immediately after your first Dashboards login (Step 10). Create separate user accounts for each application and each analyst, and assign least-privilege roles. Avoid using the admin account as an application credential.

Keep patches current. Subscribe to the OpenSearch release notes and apply OpenSearch version upgrades within the distribution's patch windows. SecureAnyCloud publishes refreshed images at each minor release.

Enable the audit log if you need it. If your compliance framework requires it, enable the audit log in the Dashboards Security UI. The audit log writes to .opendistro_security_audit_log_* indices and captures every privileged operation.

SecureAnyCloud provides 24/7/365 expert technical support for this image, with a guaranteed 24 hour response on all requests and a one hour average on critical issues. Contact sales@secureanycloud.com for help with deployment, upgrades, certificate replacement or cluster migration.

OpenSearch and OpenSearch Dashboards are distributed by the OpenSearch Project under the Apache License 2.0. This image is a repackaged upstream distribution provided by SecureAnyCloud. Additional charges apply for build, maintenance and 24/7 support. The image is not affiliated with or endorsed by Amazon Web Services.

Full product documentation, versioning notes, and upgrade guides are available at https://secureanycloud.com/guides/opensearch-3-6-on-ubuntu-22-04-azure.

Deploy on Azure

Launch OpenSearch 3.6 on Ubuntu 22.04 on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com