Log error or disable alerting plugin when security is enabled but not SSL

[mikecote]

Without a warning, users would get errors at alert creation time that API keys isn't supported / working. This is due to a requirement of SSL for the communication between Elasticsearch and Kibana. We should have some early indication when users are running alerting in this grey area (security enabled / SSL disabled).

[elasticmachine]

Pinging @elastic/kibana-stack-services (Team:Stack Services)

[peterschretlen]

Here's what the error looks like today in the logs. It's pretty clear that the errors are due to API keys not being enabled, but would be nice to indicate that this happens because of running security without TLS:

server    log   [10:17:00.078] [error][http] { Error: [illegal_state_exception] api keys are not enabled
  status: 500,
  displayName: 'InternalServerError',
  message: '[illegal_state_exception] api keys are not enabled',
  path: '/_security/api_key',
  query: {},
  body:
   { error:
      { root_cause: [Array],
        type: 'illegal_state_exception',
        reason: 'api keys are not enabled' },
     status: 500 },
  statusCode: 500,
  response:
   '{"error":{"root_cause":[{"type":"illegal_state_exception","reason":"api keys are not enabled"}],"type":"illegal_state_exception","reason":"api keys are not enabled"},"status":500}',
  toString: [Function],
  toJSON: [Function] }

[pmuellr]

I'm not sure this is available as a function rather than an http endpoint, butt we could self-call Kibana with this, as soon as the http server is available:

kibana/x-pack/plugins/security/server/routes/api_keys/privileges.ts

Lines 12 to 16 in 7e25301

	router.get(
	{
	path: '/internal/security/api_key/privileges',
	validate: false,
	},

Log the result in the server, if api keys aren't enabled. We could check it in subsequent API calls that we know will involve api key access, throw a more explicit error from there.

Is the only reason api keys would be disabled because of the security/!https scenario? Would it make sense to have ES tell us why it's disabled, eg tacked into the info that might be returned via this potential enhancement. Feels like a Too Much Info issue (security-wise). Some doc on this subject would be useful. But feels like we should only be responding in HTTP requests about the api keys not being enabled, not WHY they aren't enabled.

We should probably provide a tip in the logged message ^^^ though. An additional log message like "a common cause of api keys being disabled is using elasticsearch security but not using https"

[gmmorris]

Speaking with @legrego it seems the Security team do not want us to use the API mentioned by @pmuellr as it is an internal one.
Integrating with it has also revealed that it actually throws when security is disabled, so using it would force us to either up a server side API on our end for it or expose a runtime error to users - their of which is ideal.

Fortunately Security have an issue to address the lack of an API to check this, but it has not yet been prioritised: #59576