Enabling alerting rule ends up with 500 HTTP status code

[filowsky]

Kibana version:
7.12, 7.13

Describe the bug:
When trying to create alerting rule in v7.13 or alert in v7.12, via kibana API with flag "enbaled: true" or without this flag, server responds with HTTP status code 500.
When flag is set as "enbaled: false" alert is created correctly. But, when trying to enable request via this endpoint https://www.elastic.co/guide/en/kibana/7.13/enable-rule-api.html server responds with HTTP status code 500.

Steps to reproduce:
There are three paths to reproduce this bug.

1. First path, with omitted "enabled" flag which is described as "Optional" in documentation.
   curl -kv "https://<KIBANA_URL>/s/<SPACE>/api/alerting/rule" \ -X POST \ -H "Authorization: ApiKey <YOUR_API_KEY_HERE>" \ -H "kbn-xsrf: true" \ -H "Content-Type: application/json" \ -d ' { "params": { "criteria": [ { "aggType": "avg", "comparator": ">", "threshold": [ 1 ], "timeSize": 1, "timeUnit": "m", "metric": "some.metric" } ], "sourceId": "default", "filterQueryText": "some.query : \"query\"", "filterQuery": "{\"bool\":{\"should\":[{\"match_phrase\":{\"some.query\":\"query\"}}],\"minimum_should_match\":1}}" }, "consumer": "alerts", "rule_type_id": "metrics.alert.threshold", "schedule": { "interval": "1m" }, "actions": [], "tags": [], "notify_when": "onActionGroupChange", "name": "kibana-alert" }'
   Response for this request is "{"statusCode":500,"error":"Internal Server Error","message":"An internal server error occurred."}* Closing connection 0"

2. Second path is the same as the previous one but additionally we need to add "enbaled: true" to the request body.

3. Third path looks like the second one but with "enbaled: false". Alert is created successfully and when I try to enable it via
   curl -kv "https:/KIBANA_URL/</s/<SPACE>/api/alerting/rule/<ALERT_ID>/_enable" \ -X POST \ -H "Authorization: ApiKey <YOUR_API_KEY_HERE>" \ -H "kbn-xsrf: true" \ -H "Content-Type: application/json"
   it ends up with "{"statusCode":500,"error":"Internal Server Error","message":"An internal server error occurred."}* Closing connection 0"

All the above paths are also applicable up to version 7.12

Expected behavior:

• Alerting rule(v7.13)/alert(7.12) should be created correctly and enabled when flag "enabled" is set to "true" or is not defined (if default value for "enabled" flag is "true").
• Alerting rule(v7.13)/alert(7.12) should be enabled after "enable rule" was executed.
• Documentation should tell what is the default value for "enabled" flag when it is not defined in request.

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[ymao1]

@filowsky, thank you for taking the time to submit this. Creating an alerting rule via the API using API key authentication is currently not supported. In 7.14, we changed the 500 response you're seeing to a more descriptive 400 error: PR here and we've updated the API docs to include a warning that only token based authentication is supported: https://www.elastic.co/guide/en/kibana/7.14/create-rule-api.html.

Using token based authentication, you should be able to create a rule with enabled: true or, alternatively, create a rule with enabled: false and then enable it via the enable API.

[gmmorris]

Hi @filowsky
Thanks for submitting the bug report.

As we've addressed the incorrect behaviour (throwing a 500) in this PR, I'm going to close the issue.

As @ymao1 rightly pointed out we do not currently support API Key based auth on the rules rest APIs, and sadly can't do so until this complicated issue is addressed by the Elasticsearch team.
Once we're unblocked on this we fully intend on supporting the use of API key authentication, so watch this space ;)

Cheers