Skip to content

Tutorial: Secure the Elasticsearch Connector with TLS

For the complete documentation index see: llms.txt

All documentation pages available in markdown.

Objectives

By the end of this tutorial, you will be able to:

  • Configure mutual TLS between Aerospike XDR and the Elasticsearch connector using mkcert certificates.
  • Enable server TLS and basic authentication between the Elasticsearch connector and Elasticsearch.
  • Write a record in Aerospike Database and verify it reaches Elasticsearch over HTTPS.
  • Run a support desk’s Elasticsearch search over HTTPS for a specific merchant’s open disputes.

Introduction

The Get started with the Elasticsearch Connector tutorial runs a complete dispute-search pipeline, but two network hops are unprotected.

  1. Aerospike Database to the Elasticsearch connector. Cross-Datacenter Replication (XDR) change notification delivers each dispute record to the connector over unencrypted HTTP on port 8080. Dispute records carry merchant names, amounts, and memos. This payment data must not travel in plain text on a production network.
  2. The Elasticsearch connector to Elasticsearch. The connector indexes those records over unencrypted HTTP, and Elasticsearch accepts support searches without TLS or authentication. Anyone who can reach port 9200 could read indexed dispute data or run queries against it.

In production, you encrypt and authenticate both hops. Mutual TLS (mTLS) on the XDR connection proves Aerospike and the connector are who they claim to be and keeps the change feed confidential. Server TLS plus basic authentication on the Elasticsearch connection protect indexed data in transit and restrict who can search it.

In this tutorial, you add both layers to the local Docker Compose stack from the “Get started” tutorial. You write a dispute record to Aerospike Database and run the support agent’s Elasticsearch search over HTTPS to verify each hop is encrypted.

If you completed the previous tutorial in aerospike-elastic-quickstart, run docker compose down before you start this tutorial. You can reuse its features.conf file, but create the separate aerospike-elastic-tls project directory used in this tutorial. Both tutorials use the same Docker container names (aerospike, elasticsearch, aerospike-elasticsearch-outbound, aerospike-tools).

What you build

Two TLS layers protect the pipeline:

  • Mutual TLS (mTLS) between Aerospike Database and the Elasticsearch connector. Aerospike presents a client certificate, the Elasticsearch connector presents a server certificate, and each side verifies the other against a shared certificate authority (CA).
  • Server TLS between the Elasticsearch connector and Elasticsearch. Elasticsearch presents a server certificate, and the Elasticsearch connector verifies it against the same CA. The Elasticsearch connector also authenticates to Elasticsearch with the built-in elastic user.
TLS data flow
write record
aql client ─────────────────▶ Aerospike Database (asd.aerospike.com)
│
│ mTLS XDR
▼
Elasticsearch connector (connector.aerospike.com)
│
│ HTTPS + basic auth
▼
Elasticsearch (elasticsearch.local)

The aql client label represents Aerospike Quick Look (AQL) running in the aerospike-tools container to simulate application writes. The names in parentheses are certificate identities in the generated subject alternative names (SANs), not public hostnames:

  • asd.aerospike.com identifies the Aerospike client certificate.
  • connector.aerospike.com identifies the Elasticsearch connector’s mTLS listener.
  • elasticsearch.local identifies the Elasticsearch HTTPS endpoint.

Docker Compose connects to services using aerospike-elasticsearch-outbound and elasticsearch, which are also included in the corresponding certificates.