Append Kibana Security APIs

[stefnestor]

@pmuellr @jportner to better introspect Kibana Security/Space issues, adds APIs into Kibana diagnostic:

• List Kibana Roles
• List Kibana Spaces
  • Enables some introspection to mitigate this's impact.
• Get Current Kibana User
  • URL marks internal, but this is documented here & is frequently used to diagnose Kibana permission issues.

Kindly review

1. If endpoints return user private/sensitive data.
2. Initial available versions.
   • I pulled via Github search / oldest doc, but there's been a lot of migrations to pinpoint oldest well.

cc: @pickypg

[pmuellr]

I'm just seeing a single commit 7cd3567 with a change to a yaml file. Is there supposed to be some code here as well?

[stefnestor]

Great question. There's a CLI which targets towards Kibana. When Kibana runs it cycles through the endpoints listed in the YAML. Other CLI choices would point you to a different file in our YAML folder. So appending endpoints to the YAML is sufficient.

In the future, if we expand to cycle through spaces that will be non-YAML code, but the above is the stop gap on what could have already existed to setup the other conversation.

[pmuellr]

Ah, I see. In that case, I'm not familiar with these APIs, so can't help out with this PR.

[jportner]

• List Kibana roles: This should be OK, it doesn't return private data. This was introduced in RBAC Phase 1 kibana#19723, initial available version is 6.4.0.
• List Kibana spaces: This should be OK but it's not clear to me how having this information will assist in troubleshooting the linked issue. Can you clarify what the expectation here is?
• Get Current Kibana User: This can contain some "private data" in terms of personal information, example:

  {
    "username": "elastic",
    "roles": [
      "superuser"
    ],
    "full_name": null,
    "email": null,
    "metadata": {
      "_reserved": true
    },
    "enabled": true,
    "authentication_realm": {
      "name": "reserved",
      "type": "reserved"
    },
    "lookup_realm": {
      "name": "reserved",
      "type": "reserved"
    },
    "authentication_type": "realm",
    "authentication_provider": {
      "type": "basic",
      "name": "basic"
    }
  }

  If the user is authenticated via SSO and their ES is configured to map attributes correctly, the full_name and/or email fields can be populated. That said, the rest of this data is really valuable for troubleshooting, and I think we can justify collecting this small amount of personal information for a support case where we likely already have this info anyway.
  • /internal/security/me: this was introduced in Migrate the rest of the API endpoints to the New Platform plugin kibana#50695, initial available version is 7.6.0.
  • /api/security/v1/me: this API gives the same info, it is deprecated and is being replaced by the new API above; I believe it was introduced in https://github.com/elastic/x-pack/commit/003ef56664a74bbb31d23ada3f24895ff916502e, initial available version appears to be 5.0.0.

[pmuellr]

List Kibana spaces: This should be OK but it's not clear to me how having this information will assist in troubleshooting the linked issue. Can you clarify what the expectation here is?

Currently, the diagnostics get the alerting rules and connectors from the default space only. We'd like to have them for all spaces, so presumably the space names will end up showing up here. The diagnostics code will eventually be changed to get the list of spaces, and for each one, get all the rules and connectors from each space.

[jportner]

Currently, the diagnostics get the alerting rules and connectors from the default space only. We'd like to have them for all spaces, so presumably the space names will end up showing up here. The diagnostics code will eventually be changed to get the list of spaces, and for each one, get all the rules and connectors from each space.

Gotcha, that makes sense.

@stefnestor the List Kibana Spaces API was introduced in elastic/kibana#21408, initial available version is 6.5.0.
However, the include_authorized_purposes parameter wasn't added until 7.11.0. I would omit that from your test script entirely, it won't give you useful information.

[stefnestor]

Accepting JPortner changes

[stefnestor]

Thanks, both 🎉 ! Late circling back, but changes accepted & ready for Dev approval for SupportOps to then merge. 🙏🏼

[pickypg]

LGTM