AutoOps ECK integration

[naemono]

Resolves #8789

What is this change?

This adds a new CRD AutoOpsAgentPolicy that allows Elastic AutoOps to be integrated into self-managed ECK clusters.

TODO

• Allow parts of the configuration (configmap) to be overridden
• Allow cleanup of orphaned Agents and their relevant data.
• A minimally functional e2e test should be possible that just verifies that the deployment is created, and (currently fautlly behavior) becomes ready, even with URLs set to localhost. - This is still non-functional, but a wip This is now fully functional.

Implementation Notes

• For each ES cluster, the CA is copied to the namespace of the AutoOps Policy, and an API Key is created in the ES cluster for communication purposes and an additional secret is created that contains the API Key.
• Currently if the policy is in the same namespace as ECK operator the query for ES clusters is cluster-scoped, and if it's outside of the operator namespace, it's namespace scoped. This follows what we did for SSP, but recent discussions are questioning this behavior. (This behavior could quickly change and default to cluster-scoped always, which seems to make sense)

Needs testing

• All Helm Charts

[prodsecmachine]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[github-actions]

🔍 Preview links for changed docs

• docs/reference/api-reference/main.md

[naemono]

I just realised that the telemetry integration for AutoOpsAgentPolicies is missing.

This has now been added:

❯ kc view-secret -n elastic kibana-sample-kb-config 'telemetry.yml' | yq '.eck.stats.autoopsagentpolicies'
helm_resource_count: 0
pod_count: 1
resource_count: 1

[naemono]

buildkite test this -f p=kind,t=TestAutoOpsAgentPolicy -m s=9.2.0

[pebrc]

Looks good. Let's undo that rename of policyFromLabels though.

I will create a few follow up issues:

• status reporting is very bare-bones, we should maybe offer a bit more traceablity
• phase calculation could be cleaner (but I don't see it as a blocker for merging) there is a lot of overlap in responsiblity between reconcile.go and a derivation of the status phase from the error/ready count
• we should add support for an explicit namespace selector to allow uses to restrict the reach of the policy (we have the RBAC access reviews but that is more a cluster admin level feature, the namespace selector would be a user level feature)

[naemono]

buildkite test this -f p=kind -m s=9.2.0,s=8.19.6