Cherry-pick #16365 to 7.x: Refactor keystore interface into 3 different interfaces #17435
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.
Cherry-pick of PR #16365 to 7.x branch. Original message:
What does this PR do?
This PR refactor keystore interface into 3 different interfaces.
This PR introduces a newKeystore
backend which isReadOnly
and retrieves passwords from k8s secrets through k8s API. In order to implement this, the basicKeystore
interface is split into 3 different interfaces,Keystore
(readonly),WritableKeystore
(Keystore + store/write/delete),ListingKeystore
(WritableKeystore + list) as proposed on #5832.The new Keystore that retrieves data from k8s secrets is ofKeystore
(readonly) type.#### Autodiscover adoptionIn order to support this k8s Keystore in Autodiscover, a keystore object is attached on every event. The keystore object is either created or retrieved if it already exists. We create only one keystore per namespace and we reuse it for events of the same namespace.
Why is it important?
This is important in order to support different keystore backends, like k8s keystore.
This is important in order to support autodiscover hints being able to refer to k8s secrets for password retrieval.How to test this PR locally
Try all the set of available commands:
./metricbeat keystore create
./metricbeat keystore add ES_PWD
./metricbeat keystore add ES_PWD --force
echo "passpass" | ./metricbeat keystore add ES_PWD --stdin --for
./metricbeat keystore list
./metricbeat keystore remove ES_PWD
Create a key and consume it (Elastic Cloud auth or any other ES setting can be used as an example):
./metricbeat keystore add ES_PWD
./metricbeat -e -d "*" -E "cloud.id=testkeys:xxxx" -E "cloud.auth=\${ES_PWD}"
or
./metricbeat keystore add ES_HOST
./metricbeat -e -d "*" -E output.elasticsearch.hosts=["\${ES_HOST}"]
Related issues