[alerts] http 500 response when creating an alert using an API key has the http authorization

[pmuellr]

A user tried to create an alert via curl, using an es api key as the authorization. They had previously used other alerting HTTP endpoints successfully with the api key, but the create failed.

The logs looked like this:

Internal Server Error
POST /api/alerts/alert 500 45ms - 9.0B
Error: Unsupported scheme "ApiKey" for granting API Key
  at APIKeys.getGrantParams      (x-pack/plugins/security/server/authentication/api_keys/api_keys.js:224:11)
  at APIKeys.grantAsInternalUser (x-pack/plugins/security/server/authentication/api_keys/api_keys.js:121:25)
  at AlertsClient.createAPIKey   (x-pack/plugins/alerts/server/alerts_client_factory.js:135:76)

I think this is the code:

kibana/x-pack/plugins/alerts/server/alerts_client_factory.ts

Lines 115 to 133 in bdba929

	async createAPIKey(name: string) {
	if (!securityPluginStart) {
	return { apiKeysEnabled: false };
	}
	// Create an API key using the new grant API - in this case the Kibana system user is creating the
	// API key for the user, instead of having the user create it themselves, which requires api_key
	// privileges
	const createAPIKeyResult = await securityPluginStart.authc.apiKeys.grantAsInternalUser(
	request,
	{ name, role_descriptors: {} }
	);
	if (!createAPIKeyResult) {
	return { apiKeysEnabled: false };
	}
	return {
	apiKeysEnabled: true,
	result: createAPIKeyResult,
	};
	},

Looks like the call await securityPluginStart.authc.apiKeys.grantAsInternalUser() will need to be wrapped in a try/catch. Or whatever code calls this.

Looking into the security code, this looks like a known restriction, and it rings a bell with me.

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

Lines 289 to 315 in bdba929

	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`);
	}
	}

[elasticmachine]

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

[pmuellr]

Beyond fixing the code to throw some kind of a 40x response with a nice message, we'll need to doc this somewhere in the alerting docs.

I'm not sure if actions are affected. Any other HTTP endpoints that use alerting could also hit this and probably need doc (and perhaps try/catch wrappers). Other alerting APIs are also probably affected, like update.

[kobelb]

Beyond fixing the code to throw some kind of a 40x response with a nice message, we'll need to doc this somewhere in the alerting docs.

👍 to documenting this as a known issue. However, we'll want to ensure that we fix the code to allow API Keys to create Alerts. With Cloud SSO, it's going to be extremely common for users to no longer have a username/password to authenticate with.

@elastic/kibana-security - are there changes we can make to securityPluginStart.authc.apiKeys.grantAsInternalUser so that it works with API Keys? Or will this require changes from the ES Security team? My memory is hazy on the details...

[mikecote]

@elastic/kibana-security - are there changes we can make to securityPluginStart.authc.apiKeys.grantAsInternalUser so that it works with API Keys? Or will this require changes from the ES Security team? My memory is hazy on the details...

There's two (similar?) Elasticsearch issues I recall requesting this: elastic/elasticsearch#59304 and elastic/elasticsearch#52244.

[legrego]

are there changes we can make to securityPluginStart.authc.apiKeys.grantAsInternalUser so that it works with API Keys? Or will this require changes from the ES Security team? My memory is hazy on the details...

@kobelb this requires work on the ES side -- API Keys are not able to self-replicate today. The issues that Mike linked directly above have more detail