PUT /api/detection_engine/rules/prepackaged API endpoint error

[colin-stubbs]

Kibana version: 8.2.0

Elasticsearch version: 8.2.0

Server OS version: Not applicable, using Elastic Cloud.

Browser version: Not applicable

Browser OS version: Not applicable

Original install method (e.g. download page, yum, from source, etc.): Elastic Cloud

Describe the bug:

Using API endpoint PUT /api/detection_engine/rules/prepackaged returns an error and fails to deploy the "Endpoint Security" rule.

This appears to be related to the rule requiring the creation of the endpoint list as part of the rule, if it does not already exist.

    "exceptions_list": [
      {
        "id": "endpoint_list",
        "list_id": "endpoint_list",
        "namespace_type": "agnostic",
        "type": "endpoint"
      }
    ],

The error returned from that PUT request is simply a HTTP 400 with the following content returned,

{
    "message": "Error creating rule: could not create API key - Unsupported scheme \"ApiKey\" for granting API Key",
    "status_code": 400
}

When deploying prepackaged rules via the Kibana webUI this error DOES NOT happen, indicating something to do with the active user session allows creation/interaction with the endpoint_list object that is not permitted otherwise via direct API request.

NOTE: We're using Postman to interact with the API and automate deployment and update of detection rules. Postman is using ApiKey based authentication to interact with the API, so my conclusion is that this particular API endpoint accepts ApiKey based auth... but something else that it does internally does not like ApiKey as an acceptable authentication token.

After the "Endpoint Security" rule has been deployed via Kiban webUI the API can be called again without error, e.g. it'll start to return a normal HTTP 200 with content like,

{
    "rules_installed": 0,
    "rules_updated": 0,
    "timelines_installed": 0,
    "timelines_updated": 0
}

Steps to reproduce:

1. Fresh Elastic 8.2.0 deployment
2. Attempt to deploy prepackaged security rules via API request only
3. Experience error

Expected behavior:

We should simply be able to use PUT /api/detection_engine/rules/prepackaged to install or update all prepackaged rules.

Screenshots (if relevant): Not applicable.

Errors in browser console (if relevant): Not applicable.

Provide logs and/or server output (if relevant): No obvious logged errors.

Any additional context:

[colin-stubbs]

This includes any interaction with the "Endpoint Security" rule actually, e.g. even if simply using PATCH /api/detection_engine/rules in order to add actions to the rule AFTER it has already been deployed by a human in Kibana webUI, the API will respond with exactly the same error about not liking ApiKey based auth for this rule and only this rule. Of the 691 Elastic prebuilt rules it's only this one rule that does this... 690 of them never have an issue.

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[elasticmachine]

Pinging @elastic/security-detections-response (Team:Detections and Resp)

[banderror]

@colin-stubbs Thank you for opening this issue, appreciate the details! I have a few further questions to answer which might help us to localize the potential bug.

When deploying prepackaged rules via the Kibana webUI this error DOES NOT happen, indicating something to do with the active user session allows creation/interaction with the endpoint_list object that is not permitted otherwise via direct API request.

Are you sure that the requests you send to the API directly (from your scripts or Postman) are authorized on behalf of exactly the same user that can successfully install prebuilt rules from the UI?

In case of any doubt what user privileges are required to use Security rules, please refer to this page in the docs.

It might be helpful if you could share the privileges of the UI user and the API user so we could inspect and compare them.

NOTE: We're using Postman to interact with the API and automate deployment and update of detection rules. Postman is using ApiKey based authentication to interact with the API, so my conclusion is that this particular API endpoint accepts ApiKey based auth... but something else that it does internally does not like ApiKey as an acceptable authentication token.

Could you share your Postman request here so we could check the HTTP headers you use when calling this endpoint?

It looks like the endpoint might only support bearer and basic auth schemes (although the docs tell us to use the ApiKey scheme). This is where this error is thrown in the code:

kibana/x-pack/plugins/security/server/authentication/api_keys/api_keys.ts

Lines 343 to 368 in d30f367

	private getGrantParams(
	createParams: CreateAPIKeyParams,
	authorizationHeader: HTTPAuthorizationHeader
	): GrantAPIKeyParams {
	if (authorizationHeader.scheme.toLowerCase() === 'bearer') {
	return {
	api_key: createParams,
	grant_type: 'access_token',
	access_token: authorizationHeader.credentials,
	};
	}
	if (authorizationHeader.scheme.toLowerCase() === 'basic') {
	const basicCredentials = BasicHTTPAuthorizationHeaderCredentials.parseFromCredentials(
	authorizationHeader.credentials
	);
	return {
	api_key: createParams,
	grant_type: 'password',
	username: basicCredentials.username,
	password: basicCredentials.password,
	};
	}
	throw new Error(`Unsupported scheme "${authorizationHeader.scheme}" for granting API Key`);
	}

After the "Endpoint Security" rule has been deployed via Kiban webUI the API can be called again without error

This includes any interaction with the "Endpoint Security" rule actually, e.g. even if simply using PATCH /api/detection_engine/rules in order to add actions to the rule AFTER it has already been deployed by a human in Kibana webUI, the API will respond with exactly the same error about not liking ApiKey based auth for this rule and only this rule. Of the 691 Elastic prebuilt rules it's only this one rule that does this... 690 of them never have an issue.

This is really weird. Let's talk more in order to understand why this happens.

Thank you!

[banderror]

@colin-stubbs Please reopen if this is still an issue for you and you can provide additional info for troubleshooting.