[SIEM][CASE] Refactor Connectors - Jira Connector

[cnasikas]

Summary

Changes on this PR:

• Refactor code to support multiple connectors.
• Executor actions (commands) for each connector.
• Jira Connector.
• Update README

Dev Docs

The API changed to support executor actions. The supported action are: pushToService, handshake, and getIncident. This PR implements only the pushToService action.

The following response fields have changed:

• incidentId changed to id.
• number changed to title.

Create an incident:

Create an incident to ServiceNow. When the incidentId attribute is not in actionParams the executor will create the incident.

Endpoint: api/action/<action_id>/_execute
Method: POST

Payload:

{
    "params": {
        "action": "pushToService",
        "actionParams": {
	    	"caseId": "d4387ac5-0899-4dc2-bbfa-0dd605c934aa",
	        "title": "A new incident",
	        "description": "A description",
	        "comments": [
	            {
	                "commentId": "b5b4c4d0-574e-11ea-9e2e-21b90f8a9631",
	                "version": "WzU3LDFd",
	                "comment": "A comment"
	            }
	        ]
        }
    }
}

Response

{
    "status": "ok",
    "actionId": "f631be57-0a59-4e28-8833-16fc3b309374",
    "data": {
        "id": "7d7aad9c072fc0100e48fbbf7c1ed0c2",
        "title": "INC0010044",
        "pushedDate": "2020-03-10T13:02:59.000Z",
        "comments": [
            {
                "commentId": "b5b4c4d0-574e-11ea-9e2e-21b90f8a9631",
                "pushedDate": "2020-03-10T13:03:00.000Z"
            }
        ]
    }
}

Update an incident:

Update an incident to ServiceNow. When the incidentId attribute is in actionParams the executor will update the incident.

Endpoint: api/action/<action_id>/_execute
Method: POST

Payload:

{
    "params": {
        "action": "pushToService",
	    "actionParmas": {
			"caseId": "d4387ac5-0899-4dc2-bbfa-0dd605c934aa",
	        "incidentId": "7d7aad9c072fc0100e48fbbf7c1ed0c2"
	        "title": "A new incident",
	        "description": "A description",
	        "comments": [
	            {
	                "commentId": "b5b4c4d0-574e-11ea-9e2e-21b90f8a9631",
	                "version": "WzU3LDFd",
	                "comment": "A comment"
	            }
	        ]
		}
    }
}

Response

{
    "status": "ok",
    "actionId": "f631be57-0a59-4e28-8833-16fc3b309374",
    "data": {
        "id": "7d7aad9c072fc0100e48fbbf7c1ed0c2",
        "title": "INC0010044",
        "pushedDate": "2020-03-10T13:02:59.000Z",
        "comments": [
            {
                "commentId": "b5b4c4d0-574e-11ea-9e2e-21b90f8a9631",
                "pushedDate": "2020-03-10T13:03:00.000Z"
            }
        ]
    }
}

Checklist

Delete any items that are not applicable to this PR.

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[elasticmachine]

Pinging @elastic/siem (Team:SIEM)

[XavierM]

[cnasikas]

@elasticmachine merge upstream

[cnasikas]

@elasticmachine merge upstream

[pmuellr]

I looked through the code that touches actions, looks good, except for some comments on schema.maybe() usage that should be changed.

Thanks for making the name changes I suggested in a previous review!

[pmuellr]

You should be using schema.nullable() here instead of schema.maybe(). Otherwise, if the field is set at some point, and then you'd like to "null it out", there's no way to do that, as the updates we make to the SO are partial updates, so the effect would be that the field is unchanged.

There are a couple of other references to schema.maybe() in here as well.

I'll note that it's unwieldy to use the TS types generated from schema.nullable() to generate "writable" data structures in code, as TS will require the fields to be set to undefined or null - you can't simply just not set the field. But I believe that's true for schema.maybe() as well, and in general, using the the TS types generated from schema to use with programmatically built data structures is ... can be a bit painful.

[cnasikas]

You are right about nullable. I do not know why we started with undefined. The UI sent null for non-used values. Thanks a lot for catching this.

[pmuellr]

I made a note about the use of schema.maybe() in another comment, but this one seems ... more interesting. I think technically you can just use fullName: schema.nullable(schema.string()), but am curious if you had to do it this way for some other reason. Even for cases like MappingActionType above, I've instead sometimes just set the schema to a string, and validated the fixed set of literals in a custom validator, to produce a better error message for validation.

Probably worthwhile noting that the validation error messages produced from schema.oneOf() are quite verbose, and can be a little confusing.

[cnasikas]

Not a good reason for that either. Probably I did it to match fullname: string | undefined | null. You are right, no need for that.

About schema.oneOf you are right. It's quite verbose and difficult to catch. I tried to use the validate function but there was a bug (#64906). I would follow your advice and create a custom validator to produce better error messages for our schema in another PR.

[pmuellr]

realized in my previous review I just "commented", should have "approved". But see #63450 (comment) regarding schema changes.

[cnasikas]

realized in my previous review I just "commented", should have "approved". But see #63450 (comment) regarding schema changes.

I saw your previous comments and made the appropriate changes. Thank you, I learned a lot!

[kibanamachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request
• Commit: 102826e
• Pipeline Steps (look for red circles / failed steps)
• Interpreting CI Failures

Failed CI Steps

• Execute xpack-accessibility
• Execute xpack-kibana-ciGroup10
• Execute xpack-kibana-ciGroup9
• Execute xpack-kibana-ciGroup8
• Execute xpack-kibana-ciGroup7
• Execute xpack-kibana-ciGroup6
• Execute xpack-kibana-ciGroup4
• Execute xpack-kibana-ciGroup3
• Execute xpack-kibana-ciGroup2
• Execute xpack-kibana-ciGroup1
• Execute kibana-accessibility
• Execute kibana-ciGroup12
• Execute kibana-ciGroup11
• Execute kibana-ciGroup10
• Execute kibana-ciGroup9
• Execute kibana-ciGroup8
• Execute kibana-ciGroup7
• Execute kibana-ciGroup6
• Execute kibana-ciGroup5
• Execute kibana-ciGroup4
• Execute kibana-ciGroup3
• Execute kibana-ciGroup2
• Execute kibana-ciGroup1
• Execute kibana-ciGroup1

History

• 💚 Build #44583 succeeded 102826e
• 💚 Build #44510 succeeded 42fbd47
• 💔 Build #44423 failed 269d164
• 💔 Build #44389 failed 3603141
• 💚 Build #44029 succeeded 8e6713af00c6dc567d5973a59434be5fa619dd16

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

[elasticmachine]

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