[Elasticsearch] Allow Env Injected Auth #45092
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This allows tools to inject the auth parameters via the environment, which enables usage of dynamically deciding what to use for auth in OTel mode while still supporting blank values.
Specifically, this allows end users to specify either username and password or the API Key via configuration, which is not currently possible in the OTel configuration due to #45102.
Proposed commit message
Allow
ELASTICSEARCH_READ_USERNAME
,ELASTICSEARCH_READ_PASSWORD
, andELASTICSEARCH_READ_API_KEY
to be specified in the environment to control auth for Elasticsearch in a receiver context (not the exporter / output layer of Elasticsearch). This also enables the usage of them for theautoops_es
module.Disruptive User Impact
I intentionally added
READ_
to avoid disruption. These variables also never existed before, so anyone using them would have been using them to set the configuration already, which helpfully avoids collisions.Author's Checklist
How to test this PR locally
Related issues
Use cases
elasticsearch
andautoops_es
modules via Kubernetes / Docker