Switch over to using API Keys for reporting (many open questions)

[tsullivan]

Basic Authorization might not be successful for the scheduled reports use case. Can we use API Keys?

[tsullivan]

A thread in this issue: #76210 finds that trying to use API Keys for Reporting will not work.

Reporting's pre-routing logic checks the current username against the roles they have in the system. For API Key users, they have no roles since all of their permissions are a snapshot of what existed when the key was created.

[tvernum]

For API Key users, they have no roles since all of their permissions are a snapshot of what existed when the key was created.

That is an oversimpilification. An API key may have less privileges than the user had at the time it was created, which is why there is no way to use role names. For example, it is entirely valid (and expected) for a superuser to create an API key that has readonly access, which means the API key no longer has "superuser" even though the owner did (and probably still does).

[elasticmachine]

Pinging @elastic/kibana-reporting-services (Team:Reporting Services)

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServices)

[tsullivan]

I'm going to close this issue since we can focus on #19914

Instrumenting Kibana Apps to use Feature Controls to check the reporting privilege will mean that the reporting_user role has to be deprecated. Those changes will effectively take care of this issue.