[Actions] Extended ActionTypeRegistry with connector validation to validate config with secrets

[YulNaumenko]

Resolves #112459

Currently there was no ability to validate connector config with secrets values together, which causes to the issues in the API validation for .email action type:

• validate if hasAuth (config) is true the username/password (secrets) should be populated;
• validate if service (config) is exchange_server then clientSecret (secrets) should be populated;
  Added new validation method for connector, which allows to implement by the action type the ability to validate connector properties secrets with config.

[elasticmachine]

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

[pmuellr]

Even though this is how I was thinking of implementing it, having to duplicate the schema references for config and secrets in the connector validation seems like it may be fragile in the future. What happens if someone has different schema for the config and the config section in the connector schema?

Wondering if to make this a little clearer, we'd want to have the connector validator not be config-schema based, but a function that returns the same results as schema.validate() but takes the typed config and secrets objects.

The existing validation function in the PR would then be unchanged! And the definition of the connector validator in types.ts would be:

    connector?: (config: Config, secrets: Secrets) => string | null;

I could go either way though, not sure it's worth having a "different" shaped validation makes sense, since the way this is currently shaped seems more consistent that what I proposed ^^^. And:

• I think in practice we won't see too much of a need for this anyway
• referencing the existing schema for config and secrets is likely how it would be used when defining this new validator, exactly how it's done in this PR for email, so that eliminates / greatly reduces the possibility of them getting out of sync
• if they were wildly out of sync, you'd expect to find out with jest / functional tests
• since we have control over all the connectors right now, changing this to a slightly different shape (like I suggested) would be a simple thing we could do in the future - that is UNTIL we allow other plugins to define connectors!

[YulNaumenko]

Even though this is how I was thinking of implementing it, having to duplicate the schema references for config and secrets in the connector validation seems like it may be fragile in the future. What happens if someone has different schema for the config and the config section in the connector schema?

Wondering if to make this a little clearer, we'd want to have the connector validator not be config-schema based, but a function that returns the same results as schema.validate() but takes the typed config and secrets objects.

The existing validation function in the PR would then be unchanged! And the definition of the connector validator in types.ts would be:

    connector?: (config: Config, secrets: Secrets) => string | null;

I could go either way though, not sure it's worth having a "different" shaped validation makes sense, since the way this is currently shaped seems more consistent that what I proposed ^^^. And:

• I think in practice we won't see too much of a need for this anyway
• referencing the existing schema for config and secrets is likely how it would be used when defining this new validator, exactly how it's done in this PR for email, so that eliminates / greatly reduces the possibility of them getting out of sync
• if they were wildly out of sync, you'd expect to find out with jest / functional tests
• since we have control over all the connectors right now, changing this to a slightly different shape (like I suggested) would be a simple thing we could do in the future - that is UNTIL we allow other plugins to define connectors!

Thank you for a great thoughts @pmuellr! Yeah, I think you are right about the changes to the different shape of the connector validator.
My initial idea was to implement something which could replace/deprecate the existing separate validation in the future, but probably better to keep it as it is.

[chrisronline]

LGTM! Great work!

[pmuellr]

LGTM; made one note about some typing that we should probably fix up, if possible - and could do it later; also there's a test which doesn't seem like it's testing the connector validator, so I'm guessing it's some copy pasta.

[kibanamachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 672a0e5
• Storybooks Preview

Metrics [docs]

✅ unchanged

History

• 💔 Build #1889 failed 8cf9415
• 💔 Build #1662 failed 6684e70
• 💔 Build #1610 failed 186caf8
• 💔 Build #1571 failed 06f609c
• 💔 Build #1534 failed 7bd430c
• 💔 Build #1516 failed c009800

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @YulNaumenko

[kibanamachine]

Friendly reminder: Looks like this PR hasn’t been backported yet.
To create backports run node scripts/backport --pr 116079 or prevent reminders by adding the backport:skip label.

[kibanamachine]

Friendly reminder: Looks like this PR hasn’t been backported yet.
To create backports run node scripts/backport --pr 116079 or prevent reminders by adding the backport:skip label.