[Security in Core] Core licensing service

[TinaHeiligers]

Part of #186574
The security plugin depends on the licensing service.
Once security implementations move to Core, this dependency won't be possible.

Moving licensing to Core would solve this, however, security is under the proprietary license, while Core is under the dual license.

Scope:

1. figure out what to do about licensing and agree on a plan (Phase 2)
2. implement the plan (Phase 3)

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[elasticmachine]

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

[pgayvallet]

Pinging the security team for visibility

[pgayvallet]

I will try to summarize, please correct me if anything is wrong or incomplete:

So, the primary purpose of moving the licensing APIs to Core is that it's a prerequisite to move parts of the security plugin's implementation into Core.

ATM, for the parts of the security APIs we're exposing from Core, we're using a registration pattern, so that the security plugin registers its implementation during setup, allowing Core to re-expose it to consumers during start (and only during start, we can't -by design- expose them during setup with that approach).

I however doubt that we will be able to follow the same patterns for the licensing plugin / API, especially given security depends on it. Having the same delegation / registration at setup, constraining us to only be able to internally use and re-expose them during start, will likely become problematic (especially if we try applying the same patterns for other components/features we'll be trying to integrate into Core).

So the more I think about it, the more I believe we will have no other choice than effectively moving the licensing plugin's implementation into Core (or at least utilizing it directly, it could also be done by moving the implementation in some package that Core would import).

The question emerging from there is simply the... licensing of licensing (funny, right?)

Atm licensing is an x-pack plugin. And atm, 100% of Core's code is under our dual licensing (aka the old "OSS"). If we want to move the licensing implementation into Core, I think I only see two options:

• Switching the code of the licensing implementation from single to dual licensing (xpack->"oss")
• having the "Core licensing implementation" package being single-licensed (xpack)
  • which, FWIW, introduces a precedent, as atm, 100% of Core is "OSS"

And I'm not sure who would to able to take the decision on either of those options. @lukeelmers do you have any idea?

[lukeelmers]

And I'm not sure who would to able to take the decision on either of those options. @lukeelmers do you have any idea?

Part of this is a legal/product question that I'm also wondering about in relation to our sustainable architecture initiative -- I will dig into this further and see if I can get some clarity on the consequences of moving some single-licensed code to being dual-licensed.

[lukeelmers]

@pgayvallet @TinaHeiligers Okay, after doing some digging, I can confirm that any code which requires non-free (Gold+) licenses must remain single-licensed under ELv2. We can discuss more about the "why" internally, but I think this means that given the current structure of the repo, we'd need to keep the licensing plugin under x-pack.

That said, if we were to revisit the structure of the repository as we have been discussing and handle our license differentiation without x-pack, it may be possible to still have this live as a part of core in the long-run. (e.g. if we did something like src/platform/core/ELv2 or whatever we'd call it).

[pgayvallet]

it may be possible to still have this live as a part of core in the long-run. (e.g. if we did something like src/platform/core/ELv2 or whatever we'd call it).

Yeah, this is our most viable and realistic option now (we will likely need it for security too)

[TinaHeiligers]

we will likely need it for security too

@pgayvallet for all of security?

If so, we'll need to figure out what to do with packages/core/security if we're going to move the implementation to the package as originally planned.

[pgayvallet]

for all of security?

For anything implementation-related (so any concrete code) that currently lives in the security plugin, given Luke's answer.

[TinaHeiligers]

I propose closing this given the reason in #187296 (comment).

We can revisit it at a later stage.

[TinaHeiligers]

Reopening to discuss if we could expose the apis from the licensing lifetime contracts is possible and if that is enough for now It would be similar to how we expose authc and audit logging from core.security, and the User Profile from core.userProfile

@SiddharthMantri Let me know if you want to chat more about the details.

[TinaHeiligers]

We discussed if there's any benefit for plugin developers in exposing the licensing APIs from core and there isn't.
Closing this issue. We can reopen at a later stage.