Secure-by-Default Principles, Node/HTTP TLS, Certificates, Trust, and Enrollment/Bootstrap Concepts

Learning outcomes

AtlasMart’s developers can reach a fresh Elasticsearch node, but the first implementation stores the elastic superuser password in an application environment file and disables certificate verification because “it is only internal.” That collapses bootstrap authority, transport trust and application identity into one secret. This lesson separates those mechanisms before any application role is created.

1. Start with channels, not usernames

Elasticsearch has two network planes that are easy to conflate. The HTTP layer is the REST interface used by applications, Kibana and administrators, normally on port 9200. The transport layer is Elasticsearch’s internal node-to-node protocol, normally on port 9300. In a secured multi-node cluster, transport uses mutual TLS so cluster members authenticate each other. HTTP TLS encrypts and authenticates the server to clients and can optionally participate in client-certificate authentication when PKI realms are configured.

2. Observe automatic security setup without turning it into permanent architecture

On a first eligible self-managed start, Elasticsearch 9.5.3 can automatically enable security, generate HTTP and transport certificates, configure TLS settings, set the elastic superuser password, and create a Kibana enrollment token. An enrollment token is a bootstrap artifact used to establish trusted initial configuration; it is not a reusable application bearer token. Kibana enrollment tokens are short-lived (the current auto-setup documentation states 30 minutes).

# PowerShell/Git Bash variables are examples; do not commit their values.
export ES_URL="https://localhost:9200"
export ES_CA="/path/to/http_ca.crt"
export ELASTIC_USER="elastic"
# ELASTIC_PASSWORD should come from your local secret store/session.

curl --fail --silent --show-error \
  --cacert "$ES_CA" \
  -u "$ELASTIC_USER:$ELASTIC_PASSWORD" \
  "$ES_URL/_security/_authenticate?pretty"

Expected invariant: the call succeeds only when both the TLS trust decision and the credential are valid. The authentication response identifies the principal, authentication realm/type and roles. It does not prove the principal is least-privileged.

3. Prove certificate trust instead of disabling it

openssl s_client \
  -connect localhost:9200 \
  -CAfile "$ES_CA" \
  -verify_return_error \
  -servername localhost </dev/null

Capture the subject/SAN, issuer, validity dates and verification result. A certificate can be cryptographically valid but still be wrong for the hostname; hostname verification is part of server identity. If your production clients connect through search.atlasmart.example, the certificate must be valid for that name rather than merely for localhost.

# WRONG: this removes server-certificate verification.
curl -k -u "$ELASTIC_USER:$ELASTIC_PASSWORD" https://localhost:9200/

# CORRECT: trust the CA that signed the server certificate.
curl --cacert "$ES_CA" -u "$ELASTIC_USER:$ELASTIC_PASSWORD" "$ES_URL/"

4. Realms identify users; roles authorize them

A realm is an authentication mechanism that can identify users. Native and file realms are straightforward self-managed choices; other realm types such as LDAP/Active Directory, PKI, SAML/OIDC/JWT/Kerberos have distinct configuration and subscription/deployment constraints. Do not design “LDAP role JSON” as if realm configuration and RBAC are the same layer. A user can authenticate successfully and still receive a 403 because its roles do not authorize the requested action.

GET /_security/_authenticate
GET /_security/user
GET /_security/role

The chapter’s mandatory lab uses the native realm for reproducibility. That is a learning choice, not a claim that every production organization should manage human identities natively.

5. Bootstrap authority is intentionally too powerful for applications

The built-in elastic superuser is appropriate for controlled bootstrap and emergency administration. It is deliberately inappropriate for AtlasMart search or ingest processes because compromise grants cluster-wide authority. The correct progression is: bootstrap securely, create narrow roles and identities, validate forbidden operations, create/rotate machine credentials, then reduce how often humans need the bootstrap credential.

PUT atlasmart-products-secure-v1
{
  "settings": {"number_of_shards": 1, "number_of_replicas": 0},
  "mappings": {
    "dynamic": "strict",
    "properties": {
      "sku": {"type":"keyword"},
      "name": {"type":"text", "fields":{"keyword":{"type":"keyword"}}},
      "category": {"type":"keyword"},
      "tenant_id": {"type":"keyword"},
      "price": {"type":"scaled_float", "scaling_factor":100},
      "cost_internal": {"type":"scaled_float", "scaling_factor":100},
      "updated_at": {"type":"date"}
    }
  }
}

6. Boundary: Elastic security APIs are not OpenSearch Security APIs

OpenSearch 3.8.0 uses the OpenSearch Security plugin with its own certificates, internal users, roles, role mappings, tenants and REST APIs. Shared ancestry does not make /_security/role, Elastic enrollment tokens, Elastic service accounts or Kibana Spaces portable. Chapter 20 builds the OpenSearch model directly. This chapter compares only enough to prevent accidental cross-product assumptions.

7. Production judgment

Certificate rotation, CA ownership, private-key storage, network exposure, reverse proxies/load balancers and managed-cloud boundaries belong in the threat model. Monitor certificate expiry before outages occur. Separate administrator endpoints from application paths where network controls permit. Measure authentication/TLS overhead in the real topology, but do not trade server identity verification for marginal latency.

References

• Elastic: Secure your cluster — Current security architecture and deployment-type responsibility.
• Elastic: Automatic security setup — First-start TLS, elastic password, and Kibana enrollment-token behavior.
• Elastic: TLS for cluster communications — HTTP versus transport TLS and trust boundaries.
• Elastic: Users and roles — Authentication and RBAC model.
• Elasticsearch privileges reference — Cluster, index, application and run-as privilege semantics.
• Elastic: API key API — Expiration and role-descriptor scoping.
• Elastic: Service accounts — Predefined service accounts and service tokens.
• Elastic: DLS/FLS — Read-oriented document/field restrictions and limitations.
• Elastic: Run as — Delegated request semantics and supported authenticators.
• Elastic: Audit logging — Audit-event configuration and subscription notice.
• Elastic self-managed subscriptions — Current Basic/paid feature boundaries.
• Elastic downloads — Pinned Elasticsearch 9.5.3 release baseline.