Support api_key authentication for agent-elasticsearch association

[pkoutsovasilis]

This PR introduces support for utilising an api-key instead of a username,password from the elasticsearchRefs.secretName to authenticate against unmanaged ElasticSearch clusters for the Agent type only. Since references, such as ElasticSearch, KibanaRef, etc., of all types are captured in the code as Associations, this PR alters AgentESAssociation to introduce auth apikey support. In my thinking parsing of secrets could also be migrated per Association and thus achieve more special handling per one. More than happy to discuss the best way to introduce this feature.

[thbkrkr]

I left a few minor comments but it looks good!
I need a bit more time for testing.

[pkoutsovasilis]

I left a few minor comments but it looks good! I need a bit more time for testing.

thank you for the comments @thbkrkr , glad that this approach makes sense to you! Please take as much time as you need to do testing; I tested this with two agents (one Daemonset and one Deployment) referencing an external Elastic Search cluster starting with a secret containing api-key. Then I updated the secret to switch to username and password and I saw both agents being restarted and successfully connecting to the Elastic Search cluster. Then another update to the secret migrating to api-key and again all green. Last I did spawn two agents referencing an ECK-managed Elastic Search cluster and I could see data flowing properly.

[pkoutsovasilis]

@thbkrkr would it make sense to try to include this feature in v2.12.0?

[pebrc]

I wonder if we should also support api_key in Beats. Logstash would be another candidate but we should probably coordinate with the Logstash team on that.

[pkoutsovasilis]

I wonder if we should also support api_key in Beats. Logstash would be another candidate but we should probably coordinate with the Logstash team on that.

hey @pebrc, I can give it a try 🙂 would you like to couple this under this PR or first wait for this one to get merged and then open a subsequent one?

[pebrc]

hey @pebrc, I can give it a try 🙂 would you like to couple this under this PR or first wait for this one to get merged and then open a subsequent one?

We can split it in two PRs if that's easier. But it should be very similar to the agent code you wrote.

[pkoutsovasilis]

We can split it in two PRs if that's easier. But it should be very similar to the agent code you wrote.

yep you are right, I just pushed the relevant commit

[pebrc]

LGTM I think we want some documentation around this. Are you planning to cover that as well (in a separate PR?)

[pkoutsovasilis]

LGTM I think we want some documentation around this. Are you planning to cover that as well (in a separate PR?)

sure I will update the documentation; from a quick look this and this seem like appropriate to add info about supporting api-key for beats and agent, respectively, right?

[pebrc]

buildkite test this -f p=gke,E2E_TAGS=agent

[pebrc]

buildkite test this -f p=gke,E2E_TAGS=kibana