Support 'enterprise' license type

[bytebilly]

⚠️ NOTE: This comment is kept up to date with the latest decisions and plans ⚠️

You can still read through the full list of comments to get a better understanding of the topic history

Parent issue: https://github.com/elastic/dev/issues/1278

Description

We want to introduce support for a new enterprise license type in Elasticsearch.
This is not related to the enterprise license used by ECE.

The goal of this issue is to make Elasticsearch support the new license format in the same way of other existing licenses (like platinum or gold), and accept it via the Update license API.

Once this new license type is working, we can start shipping new features (like Endpoint security) in this new tier. Its features will be a superset of what is available in platinum.

Proposal

This is the new format for the Stack enterprise license.
Nothing will change for other Stack licenses, like platinum or gold.

• the type field gets a new value, enterprise
• a new field named max_resource_units is introduced, with a numeric value
• the max_nodes field that is present in other Stack licenses is not part of this license type
• the signature field covers the max_resource_units value

{ 
  "license": { 
    "uid": "bf610b02-470e-d453-0b75-d2f7dfead89f",
    "type": "enterprise",
    "issue_date_in_millis": 1576000000000,
    "start_date_in_millis": 1576000000000,
    "expiry_date_in_millis": 1590000000000,
    "max_resource_units": 100,
    "issued_to": "Elastic - INTERNAL",
    "issuer": "Fabio Busatto",
    "signature": "AAAA...xyz"
  }
}

In 7.x, the Get license API will return a backward compatible platinum license even if an enterprise license is installed, unless accept_enterprise=true is passed to the request. This option will change the behavior and the API will return the enterprise license instead.

In 8.0, the Get license API will return the enterprise license by default, and the accept_enterprise option will be deprecated.

[elasticmachine]

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

[bytebilly]

@tvernum could you please take a look and add relevant technical details if needed? Thanks!

[ph]

@bytebilly There a thing we need to make sure is Beats has a static list of supported license type and because of that if you add a new license type beats will report an error with an unknown type. So any older beats will not be able to send data to the cluster.

To get around that we should adjust the returned response either by:

• Check the User-agent version
• Add a new parameter query string to specify the version of the client.
• Or add a specific query string like allow_enterprise like @clintongormley proposed.

Checking the client version is propably the cleanest way / less hacky?

Note: I believe its the same behavior in logstash @jsvd can confirm this.

[bytebilly]

Thanks for the feedback @ph.

We are still discussing how to handle old versions and backward compatibility.

One additional option could be to start sending the new enterprise value from version 8.0 (it's unlikely to happen before anyway), and to require all agents (Beats and Logstash) to be at least version 7.7 or whatever is the earliest release we can ship the updated list (maybe 7.6?).

What do you think about that?

[ph]

@bytebilly Adding support in 8.0, 7.7, 7.6 is just adding a new constant in beats.

and to require all agents (Beats and Logstash) to be at least version 7.7 or whatever is the earliest release we can ship the updated list (maybe 7.6?).

I don't really like this scenario and I believe we need to have a backward compatibility solution for that, even if we recommend version to match in our stack users are still running older versions and taking their times to upgrade. I think its better if we can land the backward compatibility at the same time.

Also, considering that features in beats x-pack only require a basic license for the moment, so making a change that could potentially break users' installation seems a bit too much.

@clintongormley @urso what do you think?

[ph]

@bytebilly we have the PR open on our side for only adding the type elastic/beats#14249 We can merge it to 7.5 and up.

[ph]

We merge the new type in 7.5, elastic/beats#14282 so we are ready on our side for any changes.

[bytebilly]

@tvernum I updated the first comment to reflect the new approach that we agreed on (having an independent Stack license).

I also added a few open questions that still need to be defined.

[bytebilly]

@tvernum I was finally able to get agreement around having the max_resource_units for enterprise licenses.

In addition to what is already implemented by previous PR, I think we would need to change the following when dealing with an enterprise license:

• Update license API
  • accept the max_resource_units field
• Get license API (7.x)
  • by default, return max_nodes with a bogus value, and don't return max_resource_units
  • if accept_enterprise=true, return max_resource_units, and don't return max_nodes
• Get license API (8.0)
  • by default, return max_resource_units, and don't return max_nodes

This will provide a fully backward compatible license by default in 7.x, and the new license in 8.0 or in 7.x with the accept_enterprise=true set.

What do you think?

[bytebilly]

@tvernum I noted that in Elasticsearch logs platinum is used even if the enterprise license is loaded.

{ ..., "message": "license [46f59c8c-7f27-436a-858e-6b0182ee9c12] mode [platinum] - valid", ... }
{ ..., "message": "Active license is now [PLATINUM]; Security is enabled", ... }

This happens in both 7-6-0-SNAPSHOT and 8-0-0-SNAPSHOT releases.
Is there an easy way to show the real license instead?

Otherwise we could decouple in a separate issue and address it independently, with a different timeline. What do you think?