Open norrietaylor opened 2 months ago
cmacknz
commented
1 month ago 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
commented
1 month ago @norrietaylor what release would your team want this to be in?
norrietaylor
commented
1 month ago 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
commented
1 month ago 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
commented
2 days ago Should there be an explicit option to hide invalid variables/configurations on agentless deployments?
I believe this is taken care of by https://github.com/elastic/package-spec/pull/738, which added:
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
commented
9 hours ago Should there be an explicit option to hide invalid variables/configurations on agentless deployments?
I believe this is taken care of by https://github.com/elastic/package-spec/pull/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. 👍
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