Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
norrietaylor opened this issue Sep 23, 2024 · 4 comments
Assignees
Labels
discuss Issue needs discussion Team:Cloud Security Team:Fleet Label for the Fleet team Team:Service-Integrations Label for the Service Integrations team

Comments

@norrietaylor
Copy link
Member

norrietaylor commented Sep 23, 2024

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?
@norrietaylor norrietaylor added discuss Issue needs discussion Team:Cloud Security Team:Service-Integrations Label for the Service Integrations team labels Sep 23, 2024
@cmacknz cmacknz added the Team:Fleet Label for the Fleet team label Sep 23, 2024
@cmacknz
Copy link
Member

cmacknz commented Oct 8, 2024

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
Copy link
Member

cmacknz commented Oct 8, 2024

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

@norrietaylor
Copy link
Member Author

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
Copy link
Member Author

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss Issue needs discussion Team:Cloud Security Team:Fleet Label for the Fleet team Team:Service-Integrations Label for the Service Integrations team
Projects
None yet
Development

No branches or pull requests

3 participants