[Change Proposal] When the deployment_mode agentless is enabled, invalid input configurations should be hidden from the users.

[norrietaylor]

Motivation

When integrations are hosted and managed using the agentless deployment_mode, some special security handling is invoked. From a security perspective, we treat the deployment as if it could run arbitrary malicious code and be controlled by the user. Its network is isolated, ingress is disallowed and only specific egress is allowed.

This means that many inputs won't be user-useable. These inputs include tcp, udp, winlog, http endpoint, and filestream.

Some integrations like crowdstrike.fdrr have datastreams that support multiple input types. If we use the agentless deployment mode for this integration S3 will be valid, but filestream will not.

Questions

• Should the configurations for these input types be hidden when deployment_mode agentless is enabled?
• Should there be an explicit option to hide invalid variables/configurations on agentless deployments?

[cmacknz]

invalid input configurations should be hidden from the users.

I think we want the same thing for outputs, for example we want to forbid the Logstash, Kafka, and initially the remote Elasticsearch outputs.

[cmacknz]

@norrietaylor what release would your team want this to be in?

[norrietaylor]

We can probably get around needing it for 8.17 by being selective about which integrations we enable for agentless.

This means 8.18 would probably be the ask, as it will have a long lifespan.

[norrietaylor]

Will we need a way to limit agentless integrations to a stack version?

For example, if we only want a set of a selective set of integrations to be available in agentless for 8.17 and then broaden that set for 8.18 and beyond?

[jen-huang]

Should there be an explicit option to hide invalid variables/configurations on agentless deployments?

I believe this is taken care of by #738, which added:

• Policy templates can indicate on what deployment modes they can be used.
• Variables can be hidden per deployment mode.

Should the configurations for these input types be hidden when deployment_mode agentless is enabled?

Sounds like yes. I believe the most straightforward way of achieving this is by using the work above. Package authors can write policy templates for agentless deployment modes and make sure to only include inputs that are supported by agentless.

We could maintain an allowlist of inputs allowed for agentless policy templates in elastic-package and add validation against it.

I think we want the same thing for outputs, for example we want to forbid the Logstash, Kafka, and initially the remote Elasticsearch outputs.

@cmacknz I think this part would be best handled in Fleet.

Will we need a way to limit agentless integrations to a stack version?

For example, if we only want a set of a selective set of integrations to be available in agentless for 8.17 and then broaden that set for 8.18 and beyond?

@norrietaylor This can be done today using the Kibana version constraint, but the caveat is that the default deployment mode of an integration will also have the same constraint. Is that fine?

[norrietaylor]

Should there be an explicit option to hide invalid variables/configurations on agentless deployments?

I believe this is taken care of by #738, which added:

Policy templates can indicate on what deployment modes they can be used.
Variables can be hidden per deployment mode.

I agree that, technically, this approach would work. @jen-huang @kpollich, do you know if there are any product or UX-driven requirements around how users find and install agentless integrations?

I am concerned that showing two tiles for the same integration may confuse our users. As long as this approach fits with whatever UX is planning I would be ok with it.

@norrietaylor This can be done today using the Kibana version constraint, but the caveat is that the default deployment mode of an integration will also have the same constraint. Is that fine?

I think this should work. 👍

[jen-huang]

do you know if there are any product or UX-driven requirements around how users find and install agentless integrations?

There are designs in progress, will ping you on the internal Slack thread.

[jen-huang]

After thinking about this some more, I agree that duplicating agentless policy templates would cause UX confusion due to multiple tiles (and we already have a "setup technology" selector within the policy editor) as well as undue burden for package authors, so let's handle this on the Kibana side instead.

I created the following issues:

• [Fleet] Restrict input types allowed for agentless integrations kibana#202091
• [Fleet] Restrict output types allowed for agentless integrations kibana#202090

I have added both of these to the parent meta issue (https://github.com/elastic/ingest-dev/issues/3013), and therefore will close this issue as there isn't any work on the package spec side.

FYI @kpollich