[Change Proposal] Allow for the configuration of the default deployment mode on a per-integration basis

[smriti0321]

Background
With the plan for CSPM Agentless mode GA in 8.18, the dropdown logic in Kibana will default to agentless. This leads to agentless as default mode if that deployment mode is available for a given integration (for example integrations like Okta and beyond which are going to adopt agentless mode too). This would be a global change for all integrations that support agentless deployment. However, this change might be too broad to implement effectively.

Proposed Solution
Instead of making a broad change, we propose shipping a new flag to the package-spec. This flag would allow integration maintainers to choose the default deployment_mode.

Details
Flag Location: package-spec manifest
Purpose: Allow maintainers to set the default deployment_mode for their integrations.
This would allow the package to define something like

deployment_modes
  agentless: 
    enabled: true
    is_default: true
  default: 
    enabled: true

Impact: This change would provide more granular control and flexibility for integration maintainers, ensuring that the default deployment mode is appropriate for each specific integration. Kibana can then render the dropdown with agentless as the default option based on this configuration.

[jlind23]

@jsoriano @mrodm could please one of you take a look at this in order to better understand how complex/feasible this is?
To me it looks like a simple package spec update but I might obviously be wrong 😓

[jsoriano]

Yes, this looks like a straightforward change in the spec.

Though I am not sure of understanding where this is needed. Once agent policies are created for agentless, cannot they contain only agentless policies?

[mrodm]

A part from the change in package-spec, should this new field be available to Kibana before installing the packages? Or can it be read from the package itself in Kibana?

If it is needed to be exposed to Kibana via EPR, it would be needed to update package-registry to include that new field too.
That would require a new package-registry release in order to take effect the changes. And not sure if it would be needed a re-index of the packages in the Package Registry storage.

[jlind23]

@smriti0321 could you please answer the questions above before we move forward on this?

[smriti0321]

@jsoriano I am not sure I follow the question. Looping in @oren-zohar to pitch in here. From product perspective the ask is to allow integration developer to choose if a specific integration supports agentless as default option or not.

Though I am not sure of understanding where this is needed. Once agent policies are created for agentless, cannot they contain only agentless policies?

@mrodm I will request someone from engineering to pitch in here. @oren-zohar

A part from the change in package-spec, should this new field be available to Kibana before installing the packages? Or can it be read from the package itself in Kibana? If it is needed to be exposed to Kibana via EPR, it would be needed to update package-registry to include that new field too. That would require a new package-registry release in order to take effect the changes. And not sure if it would be needed a re-index of the packages in the Package Registry storage.

[oren-zohar]

@jlind23 @smriti0321 @mrodm @jsoriano I'll try to clarify the requirement here a bit
The idea is that Agentless deployment mode should be available to any integration that wants to use it. Currently, this is handled via the deployment_modes flag.
If an integration developer wants to support agentless mode, they can enable it in the integration’s policy_template definition as follows:

policy_templates:
  - name: billing
    title: AWS Billing
    description: Collect billing metrics with Elastic Agent
    deployment_modes: 
      default:
        enabled: false 
      agentless:
        enabled: true 

This change adds the Setup technology dropdown to the integration’s installation page, allowing the user to select between Agent-based and Agentless. Currently, the default value in the dropdown is Agent-based, but we want the integration developer to be able to configure which option is selected by default.

Right now, the default selection for Setup technology (Agent-based vs Agentless) is Agent-based. We want the integration developer to be able to configure the desired default selection here.

Though I am not sure of understanding where this is needed. Once agent policies are created for agentless, cannot they contain only agentless policies?

This functionality is needed before the user has created any agent policies, as it determines the default selection shown on the integration installation page.

A part from the change in package-spec, should this new field be available to Kibana before installing the packages? Or can it be read from the package itself in Kibana?

If it is needed to be exposed to Kibana via EPR, it would be needed to update package-registry to include that new field too.
That would require a new package-registry release in order to take effect the changes. And not sure if it would be needed a re-index of the packages in the Package Registry storage.

I believe Kibana should be able to read the default selection from the package metadata, similar to how it reads the deployment_modes today. That way, Kibana can properly render the default option (Agent-based or Agentless) as soon as the user views the integration’s installation page.

[mrodm]

I believe Kibana should be able to read the default selection from the package metadata, similar to how it reads the deployment_modes today. That way, Kibana can properly render the default option (Agent-based or Agentless) as soon as the user views the integration’s installation page.

If it is required to be shown in the installation page, probably it would be needed to be exposed via API in Elastic Package Registry (EPR). WDYT @jsoriano ?

Taking a look to the issue where it was added support for deployment_modes in Kibana elastic/kibana#194885 , those fields were required to be exposed in EPR. But, not 100% sure if for this new field would be something different.

[jsoriano]

Yes, if this is needed at this point we will also need the change in package registry.

[jlind23]

So to summarize:

• Package spec change to support this new default field
• Package registry api update to retrieve this change
• Kibana change to use this field in order to build the UI properly

Right?
Then 1 and 2 can be covered by either Jaime and Mario with this issue. Who will be in charge of covering 3?