Granular privilege for GET /_license

[yaauie]

Description

Currently, retrieving the license (GET /_license) is documented to require the monitor privilege.

When Elasticsearch-external tools like Logstash need to feature-gate licensed features, this requires our users to provide credentials that are larger in scope than would otherwise be necessary.

Would it be possible to introduce a more-granular privilege?

[elasticsearchmachine]

Pinging @elastic/es-security (Team:Security)

[jakelandis]

I agree the monitor privilege is a pretty wide privilege just to read the license state. It's not advertised but it is possible to create a custom role with just the that priv, which is :

{
  "cluster": [ "cluster:monitor/xpack/license/get" ]
}

We don't advertise that because the exact names are subject to change and hiding them behind the privilege such as monitor allows us to change the internal names as we see fit. However, in practice we rarely do. Given that Logstash is a 1st party integration with good testing and direct communication I am not that worried if Logstash were to use that name directly.

However, I think that since Logstash is a 1st party integration we may also want to consider introducing a service account specific for Logstash admin related functions. I am not too familiar with all that might be needed of that account and could be overkill if all you need is to read the license. However, it would be nice to keep first party integrations all working similarly. (note - the idea that the service account is only for admin functions and not for read/write indices)

I'm not strongly against more granular (abstracted) privilege to read the license but we need to be careful to avoid an explosion of privileges.

[yaauie]

🤔 as it stands, each licensed Logstash feature is feature-gated by checking for the license using the Elasticsearch connection parameters that will subsequently be used to interact with Elasticsearch, with no abstraction to allow different credentials.

This means that guidance for Logstash to use a custom role is effectively telling our users that in order to use any Elastic-licensed feature from Logstash, they will need a custom role that includes this unadvertised and potentially-fragile custom privilege.

As it stands, we have 2 Elastic-licensed features, with at least one more on the way:

• Logstash Monitoring is powered by a logstash_system user, whose reserved role has the appropriate permissions to ship monitoring data to Elasticsearch, but also includes the monitor privilege because it is necessary to check the license.
• Central Management (for Pipelines) docs guide users to use the reserved logstash_admin role (which has manage_logstash_pipelines), plus a custom logstash_writer role (which has guidance to include monitor so that we can check the license).

The solution may be eventually to add first-class license checking to Logstash, so that features that wish to use licensed features can check a Logsash-local API that in turn uses a minimally-privileged credentials to perform the check (possibly piggybacking on the logstash_system), but even so we would appreciate stability guarantees of a minimally-privileged role or a stable privilege whose definition was owned by Elasticsearch.