License checks for actions plugin

[mikecote]

Resolves #54946

In this PR, we're making action types license aware and adding the proper behaviours to the APIs.

This branch is a feature branch that sub PRs are merging into until the feature is complete.

The following PRs merged into this feature branch

Define minimum license required for each action type (#58668)

In this PR, I'm implementing step 1, 2 and 3 of my license check implementation proposal: #54946 (comment).

I'm adding a new minimumLicenseRequired attribute to each action type definition. Built-in action types can set a Basic+ license while non-built-in action types can only set a gold+ license.

Make actions config mock and license state mock use factory pattern and jest mocks (#59370)

In this PR, I'm changing the mocks for license state and actions config to allow my follow up PR to have unit tests that mock different responses and implementations from these classes.

Add license checks to action HTTP APIs (#59153)

In this PR, I'm implementing step 4, 9 and 14 of my license check implementation proposal: #54946 (comment). It was discussed further that response status of 403 would make more sense which is included in this PR.

I did notice the execute API always returns status of 200 but will contain the error information within the response. By design, the ensureActionTypeEnabled validation gets wrapped in a try catch and then returns the error in a JSON structure. I'm thinking of staying consistent instead of adding a special scenario. Would be curious of other's think?
EDIT: Execute API now returns 403 errors for license checks.

A few extra changes with this PR:

• The update action API won't allow updates for disabled action types
• I renamed the license_api_access.ts file to verify_api_access.ts in order to match what it exports
• The license check on execution will also apply for alerts but only after a task is scheduled and attempting to run. This will be improved with step 5 and 7 of Action registration / framework level license check #54946 (comment) to keep this PR small.

You will notice there isn't any functional tests. It would require creating different configurations for each license (basic, gold, etc) and adding CI time of > 5-10 minutes per configuration. I have focused heavily on unit tests for these but would be curious to know what others think?
EDIT: Functional tests are now in place.

Below are the APIs and their new responses that will return in such scenario:

POST /api/action

Status Code: 403 Forbidden

{
   "statusCode":403,
   "error":"Forbidden",
   "message":"Action type .slack is disabled because your basic license does not support it. Please upgrade your license."
}

PUT /api/action/{id}

Status Code: 403 Forbidden

{
   "statusCode":403,
   "error":"Forbidden",
   "message":"Action type .slack is disabled because your basic license does not support it. Please upgrade your license."
}

POST /api/action/{id}/_execute

Status Code: 403 Forbidden

{
    "statusCode": 403,
    "error": "Forbidden",
    "message": "Action type .server-log is disabled because your basic license does not support it. Please upgrade your license."
}

Add license checks within alerting / actions framework (#59699)

In this PR, I'm adding license checks within the alerting framework for the areas touched by non-HTTP API calls.

• Calling the action plugin execute function (exposed by start contract) will now throw an error if the action type is disabled via config OR license
• The action task runner will stop retrying failures caused by action type disabled via config OR license
• Alerts will skip scheduling actions for action types that are disabled via config OR license

Disable action types in UI when license doesn't support it (#59819)

In this PR, I'm adding UI indicators whenever a connector is disabled via config or via license (see below for screenshots). Users can only delete existing connectors.

[elasticmachine]

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

[gmmorris]

Haven't reviewed the whole thing yet, but just leaving this note in the context of our previous conversation

[gmmorris]

In the context of our conversation about handling the Api Keys error differently, perhaps we could do this more generically using a duck-typing approach.

Have a Type like:

interface ErrorThatHandlesItsOwnResponse {
  sendResponse(res: KibanaResponse);
}

function isErrorThatHandlesItsOwnResponse(e: Error) : e is ErrorThatHandlesItsOwnResponse {
  return typeof (e as ErrorThatHandlesItsOwnResponse)['sendResponse'] === 'function';
}

and then in our Routes we could do:

if (isErrorThatHandlesItsOwnResponse(e)) {
  return e.sendResponse(res);
}

[pmuellr]

Ya, I immediately thought of some Boom-like approaches here. Suggest we use the "remove Boom" issue #49822 as the place to look into something like this. Wanna add a comment there if you agree, @gmmorris ?

[mikecote]

@pmuellr @gmmorris let me know if what I added looks good: b3f1282

[gmmorris]

Yeah, that looks good!

One little thing we could do is wrap all the handlers in a single error handling function that calls the handler in a try catch and that way the special casing would only appear in one place:

try {
 ... call handler
      } catch (e) {
        if (isErrorThatHandlesItsOwnResponse(e)) {
          return e.sendResponse(res);
        }
        throw e;
      }

Like the Boom errors hadling.

But it's no biggie :)

[mikecote]

@elasticmachine merge upstream

[elasticmachine]

merge conflict between base and head

[pmuellr]

LGTM, left some nit comments

Kinda sad, will now have to run with a trial license to use slack/etc actions :-( hehe

[pmuellr]

nit: is the as any required here?

[mikecote]

This test is to ensure the license is a valid LicenseType. A scenario where TS might not catch this would be a call from a JS file that passes a string containing an invalid license. I had to use the any to simulate that and make TS happy.

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: b3f1282

History

• 💚 Build #34624 succeeded 0cbeaf0
• 💔 Build #34542 failed 06a73ce
• 💚 Build #33650 succeeded 12dfb25
• 💛 Build #33455 was flaky 34fa1af
• 💚 Build #33054 succeeded dfaae1d

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

[alexfrancoeur]

Checked out this PR earlier today and just wanted to say that it's looking amazing. Great work @mikecote!

[YulNaumenko]

LGTM