[ResponseOps][Rules] Validate actions parameters when creating or updating a rule

[cnasikas]

At the moment of writing, the create and update rule APIs do not validate the parameters of the actions. The reason is that the parameters can contain context variables that are known only at the execution time of the rule. For example, a parameter can be { title: "My title - {{rule.name}}" }. Assuming that the title has a limit of 50 characters if we validate on the creation of the rule the validation will pass but if on execution the {{rule.name}} is more than 50 characters the validation will fail. Without validation on the API level, automation tools like TF cannot fail in case of misconfiguration, for example, missing required fields. We should validate the parameters even if the action fails after execution. At least we could prevent misconfigurations and be closer to how the UI behaves now.

DoD

The create and update rule APIs validate the parameters of the actions without substituting the context variables.

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[pmuellr]

Hoping we can introspect on the config-schema provided (I think all connectors use config-schema), to tell us which params are actually required. So we could at least check those for null-ish. In theory we could also validate anything that does not contain any mustache template-ness ({{ ... }}), but that is likely harder, generically.

Another thought is we could have an addiitional validation schema just for use in rule create/update, which would presumably be a subset of the final validation. More elaborate validations than what config-schema provides would also be possible.

[cnasikas]

What are your concerns with validating the action parameters (schema.validate + running their custom validation) even if they contain context variables? For example, imagine I do an API call with title: 'some really long string + {{rule.name}}' where the title should be less than 50 characters. Despite having the context variable the string is already more than 50 chars and would be nice to throw a 400 error and avoid creating the rule. I am sure I am missing something :).

[pmuellr]

title: 'some really long string + {{rule.name}}'

If the variable expands to `` then the rendered version would be shorter thanthe template. But that's somewhat artificial, folks aren't likely to use variables that expand to the empty string.

I don't think, in general, we can run the existing validations on the the pre-rendered templates. Some, like you suggest, would work fine. Others won't.

Open to ideas here, currently thinking "second schema for action parameter templates" (vs action parameters rendered) might be the best approach, but obviously somewhat painful to duplicate some of this ...

[cnasikas]

We had a chat offline with @pmuellr and I understood the complexities around validating fields with mustache variables 🙂. We came up with the following approach:

1. Look out at our schemas and figure out what types we are using and what validations we have in place. This is the analysis step.
2. Try to validate on the framework level only the required fields. This would require a) iterating over the schema of each action when creating or updating the rule b) stripping out all validations except the one that checks for required fields and c) validating the values with only the required validation.

Challenges:

• Working with Joi schema structure.
• Recursion (objects/records/arrays). We could flatter the fields.
• Strip out the other validations.