[Security Solution] [Elastic AI Assistant] Adds support for plugin feature registration

[spong]

Summary

Resolves #172509

Adds ability to register feature capabilities through the assistant server so they no longer need to be plumbed through the ElasticAssistantProvider, which now also makes them available server side.

Adds new /internal/elastic_assistant/capabilities route and useCapabilities() UI hook for fetching capabilities.

OpenAPI Codegen

Implemented using the new OpenAPI codegen and bundle packages:

• Includes OpenAPI codegen script and CI action as detailed in: [Security Solution] Extract OpenAPI codegen to a package #166269
• Includes OpenAPI docs bundling script as detailed in: [Security Solution] OpenAPI docs bundler #171526

To run codegen/bundling locally, cd to x-pack/plugins/elastic_assistant/ and run any of the following commands:

yarn openapi:generate
yarn openapi:generate:debug
yarn openapi:bundle

Note

At the moment yarn openapi:bundle will output an empty bundled schema since get_capabilities_route is an internal route, this is to be expected. Also, if you don't see the file in your IDE, it's probably because target directories are ignored, so you may need to manually find/open the bundled schema at it's target location: /x-pack/plugins/elastic_assistant/target/openapi/elastic_assistant.bundled.schema.yaml

Registering Capabilities

To register a capability on plugin start, add the following in the consuming plugin's start():

plugins.elasticAssistant.registerFeatures(APP_UI_ID, {
  assistantModelEvaluation: config.experimentalFeatures.assistantModelEvaluation,
  assistantStreamingEnabled: config.experimentalFeatures.assistantStreamingEnabled,
});

Declaring Feature Capabilities

Feature capabilities are declared in x-pack/packages/kbn-elastic-assistant-common/impl/capabilities/index.ts:

/**
 * Interfaces for features available to the elastic assistant
 */
export type AssistantFeatures = { [K in keyof typeof assistantFeatures]: boolean };

export const assistantFeatures = Object.freeze({
  assistantModelEvaluation: false,
  assistantStreamingEnabled: false,
});

Using Capabilities Client Side

And can be fetched client side using the useCapabilities() hook ala:

// Fetch assistant capabilities
const { data: capabilities } = useCapabilities({ http, toasts });
const { assistantModelEvaluation: modelEvaluatorEnabled, assistantStreamingEnabled } = capabilities ?? assistantFeatures;

Using Capabilities Server Side

Or server side within a route (or elsewhere) via the assistantContext:

const assistantContext = await context.elasticAssistant;
const pluginName = getPluginNameFromRequest({ request, logger });
const registeredFeatures = assistantContext.getRegisteredFeatures(pluginName);
if (!registeredFeatures.assistantModelEvaluation) {
  return response.notFound();
}

Note

Note, just as with registering arbitrary tools, features are registered for a specific plugin, where the plugin name that corresponds to your application is defined in the x-kbn-context header of requests made from your application, which may be different than your plugin's registered APP_ID.

Perhaps this separation of concerns from one plugin to another isn't necessary, but it was easy to add matching the behavior of registering arbitrary tools. We can remove this granularity in favor of global features if desired.

Test Steps

• Verify /internal/elastic_assistant/capabilities route is called on security solution page load in dev tools, and that by default the Evaluation UI in setting does is not displayed and 404's if manually called.
• Set the below experimental feature flag in your kibana.dev.yml and observe the feature being enabled by inspecting the capabilities api response, and that the evaluation feature becomes available:

xpack.securitySolution.enableExperimental: [ 'assistantModelEvaluation']

• Run the yarn openapi:* codegen scripts above and ensure they execute as expected (code is generated/bundled)

Checklist

• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios

[elasticmachine]

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

[spong]

@elasticmachine merge upstream

[jbudz]

.buildkite

[spong]

@YulNaumenko, just a heads up that I went ahead and added local scripts & CI integration for the OpenAPI generator within the elastic_assistant plugin. I did a cursory review of #173487 beforehand to make sure I wasn't duplicating anything (and to try to keep conflicts to a minimum for you), but let me know if I'm missing anything here.

I also added a bundle script too, as detailed in #171526, to create a single OAS file to make things easier on the docs side. All this should just 'work' with your branch, but let me know if you see any issues.

[andrew-goldstein]

The yarn openapi:generate command may fail when run from any directory (e.g. x-pack/plugins/elastic_assistant) with with an error like

🪄   Generating new artifacts
Unhandled Promise rejection detected:

[Error: EACCES: permission denied, open '/Users/firstname.gen.ts'] {
  errno: -13,
  code: 'EACCES',
  syscall: 'open',
  path: '/Users/firstname.gen.ts'
}

if whoami returns something like firstname.lastname

The workaround for this issue is to (locally) change the implementation of the getGeneratedFilePath function in packages/kbn-openapi-generator/src/lib/get_generated_file_path.ts

from

export function getGeneratedFilePath(sourcePath: string) {
  return sourcePath.replace(/\..+$/, '.gen.ts');
}

to

export function getGeneratedFilePath(sourcePath: string) {
  return sourcePath.replace('.schema.yaml', '.gen.ts');
}

and then re-run yarn openapi:generate.

[spong]

Draft PR with fix: #174718

[andrew-goldstein]

The Security Solution happens to be using the Security Solution-Specific experimentalFeatures abstraction here, when registering the assistantModelEvaluation feature, because the experimentalFeatures abstraction has several benefits.

It's worth noting that a plugin is free to use any implementation of reading feature flags when registering a feature with the assistant. (There is no requirement to use something like the experimentalFeatures abstraction in other plugins when registering a feature with the assistant.)

[spong]

Bingo, well stated! And right now there is a minor feature-gap with the assistant plugin itself as it has no 'kibana.yml' configuration keys registered for setting these values, and so capabilities must be registered by the consuming plugin.

That said (and as we discussed offline), would love to have a streamlined way of managing configuration/capabilities. I have a few kibana platform docs to wade through to see what they're up to first before proposing anything.

[andrew-goldstein]

Thanks @spong for affording any plugin the ability to register features with the assistant! 🙏
✅ Desk tested locally
LGTM 🚀