Webhook action - add support for headers as secrets

[peterschretlen]

Describe the feature:

The webhook action supports user and password secrets which are used to create a Basic authentication header. But there is often other header information we'd like to encrypt:

• headers for other authentication schemes for example the Bearer scheme for token based authentication.
• support Proxy-Authorization header
• support custom headers that can carry sensitive information like keys that need to be encrypted.

While these can be set as headers today, they are not treated as secrets (not encrypted).

Describe a specific use case for the feature:

I may want to use a webhook to call an Elasticsearch API in a different cluster, using an API key.

according to the docs:

The API key returned by this API can then be used by sending a request with a Authorization header with a value having the prefix ApiKey followed by the credentials, where credentials is the base64 encoding of id and api_key joined by a colon.

Having secret headers would allow creating a lightweight external Elasticsearch connector using an API key.

[elasticmachine]

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

[pmuellr]

headers already exists in the "config":

kibana/x-pack/plugins/actions/server/builtin_action_types/webhook.ts

Lines 26 to 32 in 950ddf8

	const configSchemaProps = {
	url: schema.string(),
	method: schema.oneOf([schema.literal(WebhookMethods.POST), schema.literal(WebhookMethods.PUT)], {
	defaultValue: WebhookMethods.POST,
	}),
	headers: nullableType(HeadersSchema),
	};

While we can easily add a new headers to "secrets", I'm thinking perhaps we should just move headers from "config" to "secrets". There can't be anyone using this yet, can there be?

It seems like it could be possibly confusing to have it in both (eg, two "headers" editors in a create UI). We'd also need to document the priority.

[peterschretlen]

I'm thinking perhaps we should just move headers from "config" to "secrets". There can't be anyone using this yet, can there be?

Good point @pmuellr! Aside from a bit of rework I don't think there are any drawback to moving from config to secrets?

[gmmorris]

Aside from a bit of rework I don't think there are any drawback to moving from config to secrets?

There is the downside that headers would then be hidden from the user in the UX so they can't actually verify that the field they have set has been saved. It would make debugging a misbehaving connector very hard.

We should probably wait on doing this until we address this issue:#78704

[mikecote]

Moving from 7.x - Candidates to 8.x - Candidates (Backlog) after the latest 7.x planning session.