Remove synthetic role names of API keys as they confuse users

[ywangd]

The synthetic role names of API key add confusion to users. This happens to API responses as well as audit logs. This PR removes them for clarity.

[tvernum]

LGTM

[ahmbolu]

Removing synthetic roles names from API keys broke the case when an API Key is used to generate a report with Kibana. Kibana requires the user to be a member of one of the roles listed in xpack.reporting.roles.allow. Since the API Key has an empty list of roles, it will always fail that check with no possible work around.

[ywangd]

@ahmbolu Thanks for reporting the issue. I am sorry that the change breaks your workflow. However, role names of API keys are more misleading than they are worth. Because it is possible for two API keys to have the exact same role name but underlyingly each has a completely different set of privileges. That is, my_role of API key 1 can be totally different from my_role of API key 2. This clash of names are not only confusing but also has security implications. Basically, one cannot trust the role names provided by an API Key.

For your specific use case, I think the issue is with Kibana in that it relies on role names instead of actual privileges to grant access. Even though the reporting_user is an empty marker role, I personally think it is not the right approach. It should instead depend on something like application privileges. I will propose a discussion about this topic to the team and get back to you once we have a more concrete answer.

[tvernum]

This is a Kibana reporting issue that is tracked here: elastic/kibana#76210

[ywangd]

Thanks Tim. I wasn't aware it is a known issue.