[Fleet] Improve Audit Functionality for Fleet activity

[nicpenning]

Describe the feature:
As a Fleet admin, I would like to be able observe what user upgraded an agent or multiple agents, when policies were changed (past state and current state), and have them displayed in the flyout Agent activity window but also an index that can be used in a dashboard format for more governance of Fleet activity.

Describe a specific use case for the feature:

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[jlind23]

@juliaElastic I believe this is similar/related to #164011 shall we do both at once?

[juliaElastic]

@jlind23 They are related, but can be done separately as well.

[kpollich]

Regarding the "what user changed what data when" part of this request, I recall discussing with @elastic/kibana-security that there was a roadmap item for a broader implementation of "document history" when discussing Fleet's audit logging implementation with them. I don't have a link handy and my GitHub issue searches aren't turning up much, but perhaps someone from that team could chime in if this sounds familiar.

If my memory is correct that there will be a higher level Kibana "field/data history" implementation, it'd probably be best to avoid implementing something unique to Fleet and instead tie this request to that upstream item instead.

[legrego]

Regarding the "what user changed what data when" part of this request, I recall discussing with https://github.com/orgs/elastic/teams/kibana-security that there was a roadmap item for a broader implementation of "document history" when discussing Fleet's audit logging implementation with them. I don't have a link handy and my GitHub issue searches aren't turning up much, but perhaps someone from that team could chime in if this sounds familiar.

If my memory is correct that there will be a higher level Kibana "field/data history" implementation, it'd probably be best to avoid implementing something unique to Fleet and instead tie this request to that upstream item instead.

@kpollich, I believe this was in reference to the Content Management initiative that the @elastic/appex-sharedux team is driving.

[nicpenning]

Pinging for an update here.

[jlind23]

hey @nicpenning, thanks for the ping. Unfortunately we were not able to make any progress here so far.
This is still on our short term roadmap though.

[nicpenning]

Thank you, @jlind23. I am happy to hear its still on the short term roadmap!

[kpollich]

@nimarezainia - Assigning to you to reevaluate priority. This has fallen off our list a few times now, but I think it's probably reasonable.

@juliaElastic @jillguyonnet - Does anything in our recent agent activity improvements overlap with this ask?

[jillguyonnet]

Hi @kpollich 👋 AFAIK:

what user upgraded an agent or multiple agents

This is not implemented today. I'm not sure either what the state of the above mentioned Content Management initiative is, so it might be worth doing a quick spike to understand the amount of effort involved.

when policies were changed (past state and current state)

Actions generated by a new agent policy revision do contain a timestamp. They do not, however, report any details about the policy itself (past of present). Furthermore, there is a caveat about the View Agents link that is described here under UI caveats (TL;DR: the link shows agents currently assigned to the policy, not necessarily the same as those who were assigned at the time of change). Perhaps it would be useful to discuss what possible changes we could bring to the flyout that could be helpful for the existing use cases.

have them displayed in the flyout Agent activity window but also an index that can be used in a dashboard format for more governance of Fleet activity

I'm not aware of that existing. Perhaps this is related to elastic/integrations#8358 (deprioritized since the flyout enhancements)?

For reference, these are the issues of the agent activity flyout enhancements:
🟣 Step 1
🟣 Step 2
🟢 Step 3 (open)

Something I could also point out is that we had some discussions during the implementation of step 2 about potentially moving the activity feed into a static page instead of a flyout, which we thought would dispel some issues linked to periodic data fetching but also potentially make room for more information (see e.g. #179161 (comment)).