[Security in Core] Move security plugin's config to core

[kc13greiner]

As part of the ongoing work to make security a core service, the config should be moved from xpack.security.* to core.security.*

This work will entail:

• moving the schema registration
• adding config deprecation
• exposing the config type from core for the security plugin to be able to use
  ... To be continued!

[elasticmachine]

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

[elasticmachine]

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

[pgayvallet]

Note that the security plugin will still need to access its config too (for the parts were the logic is delegated from the plugin to core), so basically we need to find a way to have the security config being accessible from both Core and the security plugin.

This could be achieve by various hacky ways:

• Having a custom "deprecation" to duplicate xpack.security.* to core.security.*
• Having a rename deprecation to move xpack.security.* to core.security.* and changing the security plugin's configPath to core.security
• could we find something better?

[azasypkin]

could we find something better?

Not necessarily better, but as an additional option - since the configuration is known before setup, Core can potentially somehow provide only necessary configuration bits to the security plugin as part of the "registerSecurityDelegate" flow as well.

Having a rename deprecation to move xpack.security.* to core.security.* and changing the security plugin's configPath to core.security

Would it be feasible to apply renaming only to specific segments of the xpack.security.* configuration so that we can do this migration gradually? If so, this approach might be the way to go since we'll need to suport the old security configuration for quite some time and phase it out carefully.

[pgayvallet]

Would it be feasible to apply renaming only to specific segments of the xpack.security.* configuration so that we can do this migration gradually?

Yeah, we absolutely can. the only thing with this approach (having only some props moved, so some accessible only by Core and some accessible only by the security plugin) is that we can't have props that needs to be accessed by both. And I wonder if that's not already the case for the FIPS PR?

[legrego]

As part of thehttps://github.com//issues/174578, the config should be moved from xpack.security.* to core.security.*

I have concerns with this premise. Our goal of moving security into core is to provide a better DX for us and other Kibana Contributors. Moving yml configuration impacts our administrators, and the benefit of this is not clear to me. If anything, this may add to their confusion, as we have strived for consistency where possible between Kibana's security config and ES's security config. ES, as far as I know, has no plans to move away from the xpack.security.* config space.

[azasypkin]

Moving yml configuration impacts our administrators, and the benefit of this is not clear to me. If anything, this may add to their confusion, as we have strived for consistency where possible between Kibana's security config and ES's security config.

That's a good point, thanks! I think it's worth having a broader discussion though. If it turns out that it's just xpack.security.* that strives to stay consistent with Elasticsearch, then the value our users/admins get might be very limited in the grand scheme of things, since the prefix itself is probably the only thing that looks similar to the ES config.

That being said, core.security.* is not necessarily better (even though I feel like x-pack is a thing of the past when it comes to how we present "security" functionality to our users today) and it'd make sense to outline pros and cons, but consistency with ES config might not be as strong of a reason to constrain ourselves as it seems, at least for a new functionality and functionality that doesn't map 1:1.

[TinaHeiligers]

@azasypkin we meed to pick up moving security plugin's config to core discussion soon. Phase 2 is finished, we're in Phase 3.