Default X-Pack Security in Elasticsearch 8.0 and Integration Test Authentication Requirements

Goal

Run automated integration tests against a locally started Elasticsearch 8.x node without supplying production‑grade credentials, while keeping the test environment representative of a secured cluster.

Constraints arise because Elasticsearch 8.0 enables X‑Pack security by default, demanding TLS‑encrypted HTTP and rejecting unauthenticated requests; disabling security removes authentication but also turns off role‑based access, encryption and audit logging, which may hide real‑world issues.

Uncertainty remains about the minimal configuration that preserves security‑related behavior (e.g., token‑based auth) while allowing tests to proceed with non‑production credentials, such as using the auto‑generated elastic password or a self‑signed certificate.

What is the recommended approach to test client code against a secured Elasticsearch 8.x instance without exposing production secrets?
Should teams rely on the generated elastic password and reset it after each test run, or is it preferable to provision TLS certificates and use token‑based authentication in the test suite?
How does disabling xpack.security.enabled affect the validity of integration tests that depend on security‑related response headers or status codes?