Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support 'enterprise' license type #48510

Closed
bytebilly opened this issue Oct 25, 2019 · 12 comments
Closed

Support 'enterprise' license type #48510

bytebilly opened this issue Oct 25, 2019 · 12 comments
Labels
>feature :Security/License License functionality for commercial features

Comments

@bytebilly
Copy link
Contributor

bytebilly commented Oct 25, 2019

⚠️ 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.

@bytebilly bytebilly added >feature :Security/License License functionality for commercial features labels Oct 25, 2019
@elasticmachine
Copy link
Collaborator

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

@bytebilly
Copy link
Contributor Author

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

@ph
Copy link
Contributor

ph commented Oct 25, 2019

@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
Copy link
Contributor Author

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
Copy link
Contributor

ph commented Oct 25, 2019

@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
Copy link
Contributor

ph commented Oct 25, 2019

@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
Copy link
Contributor

ph commented Oct 28, 2019

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

@bytebilly
Copy link
Contributor Author

@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
Copy link
Contributor Author

@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
Copy link
Contributor Author

@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?

@tvernum
Copy link
Contributor

tvernum commented Jan 8, 2020

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

Yes, that is because (from #49223)

Internally an enterprise license is treated as having a "platinum" operating mode.

Elasticsearch supports a large number of "types", including historical license types that are no longer issued. Internally these are mapped to a set of operating modes that control the behaviour of the license.
Enterprise licenses behave like platinum, hence this message.

It will be resolved at such a time as we split enterprise into a separate operating mode.

@tvernum
Copy link
Contributor

tvernum commented Jan 16, 2020

I raised #51081 to update the OperationMode, so I believe this issue can now be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>feature :Security/License License functionality for commercial features
Projects
None yet
Development

No branches or pull requests

4 participants