Osquery plugin should not use `.fleet` indices directly

[joshdover]

The osquery plugin currently accesses the .fleet-agents, .fleet-actions, and .fleet-actions-results* indices directly using the internal Elasticsearch client (the kibana_system user). Some examples:

https://github.com/elastic/kibana/blob/686892540167ad8762b72ce6f92ef124ddde678c/x-pack/plugins/osquery/server/search_strategy/osquery/index.ts#L26

https://github.com/elastic/kibana/blob/686892540167ad8762b72ce6f92ef124ddde678c/x-pack/plugins/osquery/server/routes/action/create_action_route.ts#L82-L85

These indices are considered implementation details that are private to only the Fleet plugin in Kibana and Fleet Server. When we make changes to how these indices are accessed or mapped, we would like to only have to update one place in code, the Fleet plugin in Kibana. For example, these indices are slated to become system indices and will require special headers to be used to access them. We'd like to only make this change in the Fleet plugin and allow plugins like Osquery to get the changes automatically.

We should remove these direct usages and instead have the Osquery plugin use Fleet's JS APIs for accessing these. We already have the agentService on the server-side for accessing .fleet-agents, however we don't have an equivalent for actions or action results. The issue to create the actions service is here: https://github.com/elastic/kibana/issues/101603

@kevinlog could we get a list of requirements and for accessing actions and action results so we can provide the needed APIs from Fleet and move away from these direct access points?

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[kevinlog]

@aleksmaus @patrykkopycinski can comment on how OSQuery uses the existing indices.

@pzl @ashokaditya - I know that we now maintain our own indices in the Security app for actions/responses. I believe we do something similar to OSQuery, so we may also need to migrate to using new services that are yet to be created. I'm linking our original design ticket below.

@joshdover as I mentioned above, here's our original design ticket that shows our usage: https://github.com/elastic/security-team/issues/1508

At a high level, here are our use cases:

• Creating Endpoint specific Actions such as Host Isolation
  • Add the action to the Endpoint specific action index
  • Use system user to add the action to Fleet specific action index
• Viewing action results
  • Endpoint writes the result to the Endpoint specific results index and we read from it
  • We also read from the Fleet specific results index, I believe this is done directly.

@pzl @ashokaditya let me know if the above looks correct.

[ashokaditya]

@kevinlog Yes. We are writing to fleet actions index as "internal (kibana_system) user" from v7.16 onwards and we always read from fleet actions and responses indices only as "current user".

[ashokaditya]

@kevinlog Correction. We also read from fleet indices as an "internal user". code

[joshdover]

Yes. We are writing to fleet actions index as "internal (kibana_system) user" from v7.16 onwards and we always read from fleet actions and responses indices only as "current user".

Great, thanks for the confirmation. That makes this less urgent for the system indices changes that are being considered and more of a tech debt issue.

[elasticmachine]

Pinging @elastic/security-asset-management (Team:Asset Management)

[jen-huang]

This work is blocked by: https://github.com/elastic/kibana/issues/101603